关于此工具
这款免费的 Base64 编码器 / 解码器可以把文本转换成 Base64，也能转换回来。它兼容 UTF-8，因此表情符号、带音标的字母、中文、日文、韩文、阿拉伯文和西里尔文都能原样往返——这一点，出奇多的 Base64 工具都做不到。
全部在您的浏览器中运行。您粘贴的任何内容都不会被上传、记录或被任何人看到。这在这里比在大多数工具上更重要：人们整天把 API 密钥、令牌和配置片段粘贴进 Base64 转换器。
Base64 到底是什么
Base64 不是加密，也不是压缩。它是一种用仅仅 64 个字符重写*任意*数据的方法，这些字符几乎可以安全地送到任何地方：A–Z、a–z、0–9、+ 和 /，末尾用 = 作填充。
它存在的原因是历史性的，而且至今有效。许多系统是为传输文本而建的，不是为任意字节——邮件正文、JSON 字符串、XML 属性、HTTP 头、URL、环境变量。给这些系统一个像 0x00 或 0x1B 这样的原始字节，途中总有什么会把它弄坏、删掉，或者干脆拒收整条消息。Base64 把这些字节变成谁都不会反对的普通字母和数字，从而绕开了整个问题。
原理很简单：Base64 每次取3 个字节（24 位），把它们重写成4 个字符（每个 6 位）。这个比例就是 Base64 输出总是比输入大约大 33% 的原因。当数据不能被 3 整除时，最后一组会用一两个 = 补齐。
Base64 不是秘密
这一点值得直说，因为它确实造成过安全事故。
任何人都能解码 Base64。没有密钥，没有密码，没有秘密。这个页面转眼就能解码，任何开发者、任何日志扫描工具、任何发现它的攻击者同样可以。cGFzc3dvcmQxMjM= 不是隐藏的密码——它就是 password123 这个词披着一层极薄的伪装。
所以：Base64 适合传输。它从来不是、也不是保护任何东西的手段。如果某样东西必须保持不可读，您需要的是真正的加密。一个值*看起来*被打乱了，并不等于它*受到了*保护。
反过来这也很有用：如果您在日志文件、配置或 URL 中看到一长串以 = 结尾的字母和数字，那多半就是 Base64——您可以直接读出来。
您会在哪里遇到它
- data URL — data:image/png;base64,iVBORw0KGgo… 把图片直接嵌进 HTML 或 CSS，不需要单独的文件
- HTTP Basic 认证 — Authorization 头就是 用户名:密码 的 Base64，这正是不带 HTTPS 的 Basic 认证不安全的原因
- JSON Web Token — 一个 JWT 是用点连接的三段 Base64url，前两段就是可以直接读的 JSON
- 邮件附件 — 几十年来 MIME 一直用 Base64 把二进制文件送过只能传文本的邮件系统
- 配置与密钥文件 — Kubernetes 的 Secret、.env 文件和 CI 变量常常用 Base64 存放取值，同样是为了传输而非安全
- API — 任何需要在 JSON 字符串中携带二进制数据的字段
UTF-8，以及为什么有些工具会出错
Base64 编码的是字节，不是字符。所以在编码任何东西之前，必须先把文本转成字节——而工具正是在这一步悄悄出错。
经典的错误是对包含纯 ASCII 之外内容的文本使用逐字符一字节的转换。把 café、中文 或一个表情符号粘进这样写成的工具，您会得到一个错误，或者更糟：悄悄损坏的输出，解码回来是乱码。
这款工具会先把您的文本转成 UTF-8，也就是网页实际使用的编码。é、→、🎉 和 한국어 都会按您输入的样子编码，并原样解码回来。
标准 Base64 与 Base64url
存在两种变体，把它们弄混是出现「不是有效的 Base64」错误的常见原因。
标准 Base64 用 + 和 / 作为最后两个字符。这是本工具生成的形式，也是几乎所有系统期待的形式。
Base64url 把它们换成 - 和 _，并且通常去掉 = 填充。它存在是因为 + 和 / 在 URL 和文件路径中另有含义，否则就需要转义。JWT 使用 Base64url，许多把编码值放进路径或查询字符串的 API 也一样。
如果一串满是 - 和 _ 的字符串解码失败，原因就在这里。把它们换回 + 和 / 通常就能解决。
使用方法
- 把文本（或 Base64）粘贴到输入框
- 用按钮编码或解码
- 交换，把结果送回输入框，反向再来一次
- 复制结果
值得注意
- Base64 输出比输入大约大 33%。 一张 3 MB 的图片做成 data URL 大约是 4 MB——嵌入大文件之前值得记住。
- 空白通常无害。 许多系统把 Base64 按每行 76 个字符折行；解码器一般会忽略这些换行。
- = 只出现在末尾，绝不会在中间。一个或两个，不会有三个。
- 算上填充后长度总是 4 的倍数。 如果不是，说明有内容被截断了。
- 把任意二进制解码回文本会像乱码。 解码一个 PNG 得到的是字节而不是文字——这是正确的，不是失败。
常见问题
Base64 是加密吗？
不是，而这正是最重要的一点。Base64 没有密钥也没有秘密。任何看到这串字符的人都能一步把它解码，包括这个页面。它是一种用于安全传输的编码，不是保护手段。绝不要用它来隐藏密码、令牌或任何重要的东西。
为什么我的 Base64 以一个或两个等号结尾？
那是填充。Base64 按 3 个字节一组工作，每组变成 4 个字符。当数据不能被 3 整除时，最后一组不足，就用 = 补齐，使总长度保持为 4 的倍数。剩一个字节得到 ==，剩两个字节得到 =，正好整除则没有填充。
为什么我的 Base64 字符串比原文长？
因为每 3 个字节变成 4 个字符，所以输出总是比输入大约大 33%，再加上最多两个填充字符。这无法避免，是让任意数据能安全放进文本字段所付的代价。如果在意大小，请在编码之前压缩数据，而不是之后。
我可以把图片或 PDF 编码成 Base64 吗？
可以，这是常见用法——data URL 正是这样把图片嵌进 HTML 和 CSS 的。不过这款工具处理的是您粘贴的文本，因此适合令牌、JSON、配置取值和已有的 Base64 字符串。嵌入较大内容前请记住体积会增加 33%。
为什么解码时提示「不是有效的 Base64」？
常见原因是字符串被截断、粘贴时带进了多余字符，或者它其实是 Base64url。Base64url 在标准 Base64 使用 + 和 / 的位置改用 - 和 _，而且往往去掉了填充，所以直接粘贴的 JWT 片段可能无法解码。把 - 换成 +、_ 换成 / 再试一次。
我的文本会被发送到服务器吗？
不会。整个转换都在您的浏览器里用内置功能完成。没有任何内容被上传或保存，所以断网之后工具依然可用。考虑到人们多么频繁地把凭据粘贴进 Base64 工具，这正是关键所在。
相关工具
- URL 编码器 / 解码器 — 在 URL 和查询字符串中不断遇到的另一种编码
- JWT 解码器 — 替您读取令牌的 Base64url 片段，无需手动替换
- 哈希生成器 — MD5、SHA-1 和 SHA-256，与 Base64 不同，它们是单向的
- 图片转 Base64 — 把真正的图片文件变成 data URL
