跳到正文
DevTools / Base64 编码解码

Base64 编码解码

Base64 把任意字节转换成 64 个可打印字符，从而能安全穿过电子邮件正文、HTTP 请求头、XML 文档、JSON 字符串以及只接受文本的数据库列。本工具支持双向转换、标准与 URL 安全两套字母表，正确处理多字节 UTF-8 而非把非拉丁文字弄乱，并能把编码后的图片当作真正的 data URL 预览，让你直接看到浏览器会渲染出什么。

完全在浏览器本地运行——不会上传任何内容。

0 字符

结果
暂无内容

图片转 Base64

或将文件拖到此处

工作原理

编码本质上只是重新分组比特。Base64 每次读取三个字节（24 位），把这 24 位重新切成四个 6 位组，每组映射到 64 个字符之一——A-Z、a-z、0-9，再加 + 和 /——于是每三个输入字节产生四个输出字符。当输入长度不是三的倍数时，末尾用 = 补齐，这就是 Base64 字符串经常以一到两个等号结尾的原因。

3 比 4 的关系意味着 Base64 会让数据膨胀约 33%：3 字节变 4 字符，3 KB 变 4 KB。这个代价是刻意付出的。输出保证不含控制字符、引号、反斜杠，也不含大于 127 的字节，因此可以直接嵌入 JSON 字符串、SQL 字面量或 HTTP 请求头，完全不需要额外转义。

还必须存在第二套字母表，因为标准字母表对 URL 和文件名并不友好：+ 在查询字符串中会被解释为空格，/ 是路径分隔符。URL 安全 Base64（RFC 4648 第 5 节）把这两个字符换成 - 和 _，通常还去掉末尾的填充。两套字母表编码的字节完全相同，差别仅在于字母表的最后两个字符。混淆它们正是签名验签失败最常见的原因。

解码是逆过程：每个字符映射回一个 6 位值，四个值拼接成 24 位，再拆回三个字节。许多解码器会静默忽略非法字符而不报错，这是真正的隐患——从日志里截断复制的一小段 token 也会“成功”解码成看似合理的乱码。本工具会先按所选字母表校验输入，并报告出错字符的位置。

常见应用场景

  • 把小尺寸图标以 data URL 形式内联进 CSS 或 HTML，省掉一次 HTTP 请求。
  • 查看从浏览器网络面板里复制出的 data: URL，还原出它所包含的文件。
  • 在没有专门 JWT 工具的环境里解码 JWT 的载荷段。
  • 为无法承载原始字节的 SOAP 或 XML 接口准备二进制附件。
  • 把证书或密钥文件转换成为配置文件、环境变量所要求的 Base64 形式。
  • 通过确认发送方使用 URL 安全 Base64 而校验方期待标准字母表，定位签名失败的原因。

最后更新: 2026-10-14

常见问题解答

Base64 是加密吗？

不是，把它当作加密是实实在在的安全缺陷。Base64 是没有密钥的可逆编码，任何截获字符串的人一步就能还原。它能防住站在你身后用眼睛偷看的人，防不住机器。如果需要保密，应当先加密——例如使用 AES-GCM——再把密文做 Base64，以便安全传输。

为什么解码出来的中文是乱码？

几乎总是字符集问题。中文、日文、阿拉伯文或 emoji 在 UTF-8 中占 2 到 4 个字节，若解码器假定一字符一字节，就会从序列中间切断。本工具按 UTF-8 解码且不做替换字符回退，因此带重音的拉丁文与中日韩文字都能精确往返。如果输出依然是乱码，那原文很可能用的是 GBK、Latin-1 之类的历史单字节编码。

标准 Base64 与 URL 安全 Base64 有什么区别？

只有两个字符和填充的差别。标准 Base64 使用 + 和 /；URL 安全版本使用 - 和 _，这样结果可以直接放进查询字符串或文件名而不必再做百分号编码。部分实现还会去掉末尾的 = 填充。由于编码的字节完全一致，当遇到验签失败时，第一件该检查的事就是双方各自使用了哪套字母表。

Base64 会让数据变大多少？

压缩前大约 33%，因为每三个字节变成四个字符。填充会把短输入向上取整到 4 的倍数，所以一个字节的输入要付出 300% 的代价。Base64 本身不压缩，但它对网络上的 gzip 和 Brotli 很友好：64 个字符的字母表仍留有大量统计冗余，承载 Base64 文本的 HTTP 响应通常能再缩小 70% 到 80%。

相关工具