Base64 编码解码器

内容	字节数	Base64 字符数	填充	示例
1 个 ASCII 字符（「A」）	1	4	「==」	QQ==
2 个字符（「AB」）	2	4	「=」	QUI=
3 个字符（「ABC」）	3	4	无	QUJD
「Hello」（UTF-8）	5	8	「=」	SGVsbG8=
「Bonjour le monde !」（UTF-8）	18	24	无	Qm9uam91ciBsZSBtb25kZSAh
「é」（UTF-8）	2	4	无	w6k=
「日」（UTF-8）	3	4	无	5piv
空字节（0x00）	1	4	「==」	AA==

Base64 里的「编码」和「解码」是什么意思？

Base64 编码 （「encode base64」）把字节——通常是 UTF-8 编码文本的字节——转换成由 64 个允许字符组成的字符串：26 个大写字母、26 个小写字母、10 个数字，以及 + 和 /. Base64 解码 （「decode base64」）做的正是相反的操作：字符串每 4 个字符一组读取，每个字符对应 6 位，24 位合起来得到 3 个字节。人们搜索「encode and decode base64」时，找的就是这种来回转换。

Base64 既不是压缩也不是加密：文本会变长约三分之一，任何人都能一秒钟读懂。它的意义在于把字节送进只接受安全 ASCII 字符的通道——URL、HTTP 请求头、配置文件、JSON、内联 SVG、电子邮件、文本型数据库。

如何把文本编码成 Base64

第 1 步：先按所选字符集把文本编码成字节——默认是 UTF-8，处理旧系统时 Latin-1、Windows-1252、ASCII 或 UTF-16 依然有用。第 2 步：每 3 个字节一起读取，也就是 24 位。第 3 步：这 24 位被切成 4 个 6 位块，每个块替换成字母表中对应位置的字符。第 4 步：如果最后一组不完整，就用零位补齐，并以一个或两个 = （即填充）。

分步示例：「 AB 」的十进制值依次是 65 和 66，也就是 01000001 01000010。补足到三个字节后： 01000001 01000010 00000000。四个 6 位分组是 010000 010100 001000 000000 → 位置 16、20、8、0 → QUI=。在编码器里输入「AB」，松开按键之前结果就已经出现了。

如何把 Base64 解码成文本

解码时先去掉换行和可能的空格，再按每 4 个字符一组读取字符串。每个字符换成 6 位数值，四个值拼成 24 位，随后把这 24 位切成 3 个字节。末尾的 = 表示最后一组真正包含多少个字节：一个 = 表示 2 个字节，两个 = 则表示 1 个字节。

如果字符串中出现 - 或 _，说明这是 URL-safe 变体：工具会在解码前自动把它们转换成 + 和 / 再进行解码。如果缺少填充，「修正填充」按钮会把它补上。遇到字母表之外的字符、位置不对的制表符或长度不是 4 的倍数时，会显示具体原因，而不是简单一句「无效」。

URL-safe 变体（RFC 4648 §5）

标准 Base64 使用 + 和 /，这两个字符在 URL 中会出问题： + 会被大多数服务器当作空格，而 / 则可能被当成路径分隔符。URL-safe 变体改用 - 和 _，无需任何转义。它是以下场景的必需项： JWT （令牌的三个段都不带填充）、 cookie、 标识符 以及 URL 参数。

填充符「=」是干什么的

Base64 按 4 个字符一组处理，但文件大小几乎从不是 3 的倍数。填充负责把长度补回来：剩 1 个字节时补 ==，剩 2 个字节时补 =。有些系统会去掉它（部分 API、Base64URL），有些则要求必须有（PHP、老式解码器）。编码器的「不带填充」选项和解码器的「修正填充」按钮兼顾了这两种情况。

字符编码：UTF-8、Latin-1、UTF-16

Base64 不认识字符，只认识字节。因此关键问题是：文本 在做 Base64 之前用什么编码？在 UTF-8 中，「é」占 2 个字节，「日」占 3 个；在 Latin-1 中，「é」只需 1 个字节，「日」却无法表示。把 Latin-1 编码的字符串按 UTF-8 解码，就会出现乱码（mojibake）。如果你用在线工具转换后结果无法理解，几乎总是原始编码不一致造成的——这正是这里提供六种选项的原因。

文件、data URI 与 Base64 图片

一个 data URI 的形式是 data:<MIME 类型>;base64,<数据>。它可以把图片直接嵌入 CSS、HTML 或 JSON： background-image:url(data:image/png;base64,iVBOR…)。要解码，就把整段字符串粘贴到「文件 ⇄ Base64」标签页：工具会提取 MIME 类型、给出建议文件名，然后重新生成文件供下载。注意体积：Base64 会增加约 33 %，而且 data URI 永远不会被单独缓存。

Base64、URL 编码，以及为什么不要把两者混为一谈

所谓 percent-encoding （%20, %C3%A9）会把每个不允许的字节替换成百分号形式：它比 Base64 长两到三倍，但肉眼仍能看出原文。Base64 生成的字符串紧凑、规整，适合二进制块，却无法直接阅读。「URL & data URI」标签页把两种转换并排放在一起，避免本该转义的 URL 被编成 Base64——或者反过来。

日常格式中的 Base64

Base64 无处不在：一个 JWT的三个段、 src 属性（内联 SVG 图片的）、 cert 字段（PDF 的）、 attachments MIME 附件（RFC 2045 邮件的）、 Authorization: Basic 请求头（用户名:密码）、文件 .pem 及 SSH 密钥、 .docx 和 .xlsx （ZIP）的内容、客户端存储中的头像，以及 data- 属性（自动化测试用）。掌握快速编码与解码，就不用为一个字符串专门打开终端。

Base64 不是什么

Base64 不加密任何东西：编码后的字符串一行代码就能还原。绝不要用它来保护密码、API 密钥或个人数据。它也不是压缩：始终要预留 33 % 的体积增量。另外，PNG、ZIP 这类本身已经很紧凑的二进制，超过几兆字节后就不再适合 Base64，内存开销会吃不消。

性能与最佳实践

在浏览器中， TextEncoder 和 TextDecoder 每秒能处理几兆字节；Base64 算法本身是线性的，没有递归，也不逐字符分配内存。超过 5 MB 的文件可能拖慢界面：更大的批量建议改用 Web Worker 或服务端处理。务必把原始编码与字符串一起记录，并在把结果存入数据库之前先做一次往返测试（编码再解码）。

推荐人群

前后端开发者（令牌、data URI、HTTP 头）、集成与技术写作者（内联 SVG、背景图）、系统管理员与 DevOps（证书、密钥、转储）、测试与渗透测试人员（Authorization Basic、参数模糊测试）、学生（理解字节、ASCII 与 UTF-8），以及任何需要 在线 Base64 编码解码器 的人：快速、完整、私密。

100 % 本地的 Base64 编码解码器：数据永不离开您的电脑

与常见的在线 Base64 编码器不同，这里不传输任何字符串：编码、解码和文件转换全部在浏览器中完成。因此，即使在飞行模式或公共网络下，也能放心处理密码、令牌、证书或内部代码片段。历史记录与上次输入都保存在本地（localStorage），始终留在您的设备上。

许可证 Volade Premium 提供可选的加密云端同步，独立于工具本身——其余功能依然免费、无限制，无需注册。