Base64 在线编码解码

关于 Base64 在线编码解码

Base64 编解码工具把 UTF-8 文本转成标准 Base64 或 URL 安全的 Base64URL 变体，也能把两种形式解回文本。输入框会实时校验，明显不可能是 Base64 的内容在你点击转换之前就会被标出来。

Base64 的存在意义是让字节穿过只接受可打印字符的通道：邮件头、HTTP 头、JSON 字符串字段、URL。它是一种表示方式而不是保护手段，两套常用字母表的差别也只有两个字符外加填充规则。实践中几乎所有 Base64 问题，要么栽在这两个差异上，要么栽在「到底编码的是哪串字节」上——Base64 编码的是字节，而文本只有在选定编码之后才变成字节。

如何使用这个开发者工具

选择「编码」把文本转成 Base64，或选择「解码」做反向转换。
当结果要塞进 URL、文件名或 JWT 分段时，勾选 Base64URL。该选项只对编码方向生效。
粘贴内容并留意状态提示：解码模式下，它会在你动手之前告诉你这串输入是不是合法的 Base64。
执行转换并核对结果；短值建议逐字符比对。
把输出复制到目标字段，同时记住接收方对填充符有它自己的要求。

实例：让 URL 出问题的那两个字符

一句带 emoji 的短文本，编码结果里同时出现了两套字母表分歧的两个字符，一次转换就能看清区别。

输入文本

Build 🚀 now?

输出

标准 Base64 ：QnVpbGQg8J+agCBub3c/
Base64URL   ：QnVpbGQg8J-agCBub3c_

这段文本 UTF-8 下是 15 字节（emoji 占 4 字节），15 能被 3 整除，所以没有填充符。标准形式里同时出现了 + 和 /，这两个字符在 URL 中都会变味：表单解码器会把 + 当成空格，而 / 会结束一个路径段。Base64URL 把它们换成了 - 和 _。

Base64 与 Base64URL 对照

两套字母表都定义在 RFC 4648 中，第 4 节与第 5 节的差别只在最后两个符号和填充处理上。

细节	标准 Base64（RFC 4648 §4）	Base64URL（RFC 4648 §5）
数值 62	+	-
数值 63	/	_
填充	用 = 补齐到 4 的倍数	通常省略
能否直接放进 URL 路径或查询串	不能	可以
典型使用者	HTTP Basic 认证、MIME、Data URL、Kubernetes Secret	JWT 分段、JWK 字段、WebAuthn、文件名
换行	MIME 允许每 76 字符换行	不使用

常见问题排查

别的工具能解的值，在这里解码失败。

成因这里的解码使用严格 UTF-8 解码器。如果原始字节根本不是 UTF-8 文本——比如 gzip 流、protobuf 消息或 Latin-1 文本——字节序列就不是合法 UTF-8，工具会直接报错，而不是吐出一堆乱码。

解决办法 先想清楚这些字节到底是什么。压缩载荷交给 Gzip 工具，图片交给 Base64 图片工具，老式单字节文本则需要认识对应代码页的解码器。

在这里能正常往返的令牌，服务端却不认。

成因两套字母表不能混用。JWT 分段和 JWK 字段必须是不带填充的 Base64URL，而 HTTP Basic 凭据必须是带填充的标准 Base64。

解决办法 按消费方来选变体：进 URL 或 JWT 的一律勾选 Base64URL，Authorization 头和 MIME 则保持不勾。

值传到服务端后，原来的 + 变成了空格。

成因标准 Base64 里含有 +，而 application/x-www-form-urlencoded 会把 + 解码成空格。任何经表单提交或放进查询串的载荷都会丢掉这些字符。

解决办法 改用 Base64URL；或者在放进查询串之前，先用 URL 编码工具做百分号编码。

看起来干干净净的 Base64，却被判为无效。

成因空白会被清除、缺失的填充会被补齐，所以这两者都不是原因。剩下的可能只有两种：混入了字母表之外的字符，或者长度除以 4 余 1——任何 Base64 串都不可能是这个长度。

解决办法 找找复制进来的省略号、不间断空格、中文引号或邮件引用标记。重新从原始输出复制，别从渲染后的页面复制。

适合用这个工具的场景

手工调 API 时，构造或读取 HTTP Basic 的 Authorization 头。
查看从 Kubernetes Secret、.env 文件或以 Base64 存文本的配置字段里取出的值。
生成粘进查询串也不会坏掉的 URL 安全标识符或 state 参数。
确认某个服务是把非 ASCII 文本按 UTF-8 编码的，而不是按某种老代码页。

应该换用别的工具的场景

隐藏任何东西。Base64 是无密钥的公开变换；需要保密请用真正的加密和密钥管理。
阅读完整的 JWT。JWT 解码工具会拆出三段并把时间声明渲染成可读时间。
处理二进制载荷。图片请用 Base64 图片工具，压缩数据请用 Gzip 工具，它们会保留原始字节，而不是硬塞给文本解码器。

隐私与数据处理

编码使用浏览器自带的 TextEncoder 与 btoa，在当前标签页内完成；解码走的是严格 UTF-8 解码器，遇到非法序列会直接报错而不是猜测。内容不上传，关闭标签页即不再保留。Base64 可以被任何人瞬间还原，所以你粘进来的令牌可读性和之前完全一样——真正的风险在值本身，而不在工具。

常见问题

Base64 和 Base64URL 到底差在哪？

差两个字符和填充约定。标准 Base64 用 + 和 /，Base64URL 用 - 和 _，并且通常去掉结尾的 = 号。其余部分（包括字母表顺序）完全一致。

填充符是必须的吗？

标准解码器要求长度是 4 的倍数，所以除非消费方是会自行推算长度的 Base64URL 解码器，否则请保留 = 号。本工具解码时会自动补齐填充，因此不带填充的输入同样能解。

Base64 算加密吗？

不算。它没有密钥，变换规则公开，任何人一秒就能还原。把密码或 API Key 编码一下，对「谁能读到」毫无改变。

为什么带重音符号的文本到别处就乱了？

Base64 编码的是字节，而字节取决于字符编码。本工具一律使用 UTF-8。如果对方按 Latin-1 或 GBK 解释，同一串载荷就会解出不同的字符。

Base64 会让数据大多少？

每 3 字节变 4 个字符，约增大 33%，再加最多 2 个填充符。若按 MIME 风格每 76 字符换行，还会再多一点。

能编码 emoji 和中文吗？

可以，它们按 UTF-8 字节编码。所以一个 emoji 会带来 4 字节、一个汉字 3 字节，然后再按 4:3 膨胀。

Base64 文本

输入

结果