Base64 编码与解码

把文本编码成 Base64、把 Base64 解回纯文本，Unicode 在浏览器里也能安全往返。

input.txt
output.txt
把文本编码为 Base64，或把 Base64 解码回文本。

编码或解码 Base64 文本

Base64 把字节转成可打印的 ASCII 字符。当一个只认文本的格式或协议需要携带不便直接放入的数据时，它就派上用场了。粘贴纯文本点 Encode，或者粘贴标准 Base64 点 Decode。转换在你的浏览器里完成，工具按 UTF-8 处理文本，所以人名、非拉丁文字和 emoji 都能原样往返。

举个例子，Hello, 世界 编码后会得到一串便于传输的字符串。把它解码回来，拿到的就是原文 —— 不是什么"受保护的版本"。

Base64 解决的是兼容性，不是安全性

任何 Base64 值都能被解开，不需要密码，也不需要密钥。请不要用 Base64 来混淆 API key、加密密码或保护个人数据。HTTP Basic 认证把用户名和密码做成 Base64，正因为如此它必须走 HTTPS —— 这层编码本身不提供任何机密性。

常见的正当用途包括：

  • 把小体积的二进制资源嵌进 data URI；
  • 在 MIME 邮件里携带附件；
  • 在 JSON 或 XML 字段里表示字节；
  • 查看 JWT 里编码过的头部或载荷。

这个页面是为转换文本设计的，不适合处理任意上传的文件。如果你要处理的是原始文件字节，请用支持文件的编码器，免得浏览器先把这些字节当文本去理解。

标准 Base64 和 Base64url 用的是两套字母表

标准 Base64 使用 + 和 /，结尾常带 = 补齐。Base64url 把这两个字符换成 - 和 _，JWT 通常还会省掉补齐 —— 这样就避开了在 URL 和文件名里有特殊含义的字符。

本页的解码器按标准 Base64 处理。JWT 请用 JWT 解码器，它认得 token 各段的 Base64url 编码，也守住了"解码"和"验签"之间那个重要区别。

解出来的文本要结合上下文看

解码成功只能说明这段输入可以被当作 Base64 和 UTF-8 文本来理解。它证明不了这个值从哪来、有没有被改过，也证明不了拿去渲染是否安全。如果解码结果要变成 HTML、shell 参数、数据库查询或其他可执行的上下文，请按目标场景的转义和校验规则处理。

FAQ

为什么有些 Base64 结尾是 =？

当字节长度不是 3 的倍数时，补齐字符会把最后那个四字符块填满。有些协议保留它，而 JWT 这类 Base64url 用法通常会省略。

Base64 算加密吗？

不算。它是可逆的编码，没有任何密钥。真要保证机密性，请用成熟的加密方案。

Base64 和 Base64url 有什么区别？

Base64url 把 + 换成 -、/ 换成 _，并且通常去掉 = 补齐。数据仍然只是被编码，而不是被加密。