Base64 编码与解码

什么是 Base64，什么时候用

Base64 用 64 个可打印 ASCII 字符（A–Z、a–z、0–9、+ 和 /，= 作填充）来表示任意二进制数据。每 3 个字节的输入变成 4 个字符的输出，所以编码后的数据比原始数据大约大 33%。它存在的原因是很多通道只为文本设计：邮件附件（MIME）、JSON 和 XML 负载、HTTP Basic 认证头、JWT 令牌，以及把图片直接嵌进 HTML 或 CSS 的 data URL。Base64 是编码而不是加密——任何人都能解码，绝不要用它来隐藏秘密。

URL-safe 变体（RFC 4648 §5）把 + 换成 -、/ 换成 _，通常还去掉 = 填充，这样结果可以直接放进 URL、文件名和 Cookie 而无需转义。JWT 用的就是这种形式。本页的解码器两种变体都接受，并容忍缺失的填充，所以可以直接粘贴 JWT 的某一段。

使用方法

输入或粘贴文本，编码随输入自动完成。文本按 UTF-8 处理，所以中文、emoji 及任何 Unicode 字符都能正确往返——直接用 btoa() 的简陋实现常在这里出错。勾选 URL-safe 得到 -/_ 字母表且无填充。点「文件…」选择任意文件：图片、PDF、字体或压缩包都在本地读取并编码；对于图片，输出是完整的 data URL，可以直接粘贴到 <img src> 或 CSS 背景里。

解码时切换到「解码」并粘贴 Base64（完整的 data URL 也可以）。如果结果是合法的 UTF-8 文本，会显示在输出框；如果是二进制，工具会识别常见格式（PNG、JPEG、GIF、WebP、PDF、ZIP），图片直接预览，并可下载解码后的文件。「交换」把输出放回输入，一键验证往返是否正确。

隐私与限制

文件不会离开你的电脑。它们通过浏览器的 File API 读取、在内存中编码并显示给你，不上传任何内容。因为全部在客户端运行，实际限制就是设备内存：几十 MB 的文件没有问题，只是输出框滚动会变慢。超大文件建议直接下载结果而不是复制。

背景：一个只有文本的世界

Base64 诞生于早期电子邮件的限制。SMTP 是为 7 位 ASCII 文本设计的，附上一个二进制文件意味着先把它翻译成可打印字符；1980 年代的 uuencode 就是干这个的，而 MIME 标准（RFC 2045，1996）定义了沿用至今的 Base64 字母表。后来 RFC 4648（2006）把各变体收拢到一起：标准 Base64、URL 与文件名安全变体，以及 Base32/Base16。3 字节变 4 字符的比率，就是编码后数据恰好是原始大小的 4/3 再加填充的原因——这个代价在拨号上网时代很要紧，在把图片内联进 CSS 时依然要紧。

应用领域

邮件附件的底层仍然是 Base64。data URL 把小图片和字体直接嵌进 HTML 与 CSS，省掉一次请求——嵌入前先压缩图片，因为 Base64 会在原大小上再增加 33%。HTTP Basic 认证把 username:password 用 Base64 发送（不是加密——务必走 HTTPS）。JWT 令牌是三段用点连接的 URL-safe Base64，头部和负载解码出来是 JSON。Kubernetes Secret、云平台 IAM 策略、携带 Base64 值的百分号编码 URL、Subresource Integrity 属性里的 SHA-256 摘要、SAML 断言、PEM 证书（BEGIN 与 END 行之间的块）以及 JSON API 里的二进制字段全都用它，因为这些系统只能承载文本。当你遇到一个以 = 结尾、或只含字母数字和 + / 的长字符串，它几乎肯定是 Base64，粘到这里是弄清它内容最快的方式。

常见问题