如果你打开浏览器的开发者工具，随便找一个网站的网络请求，几乎可以肯定你会在某个地方看到一长串 Base64 字符串——Authorization header 里的 Bearer token、CSS 里的 data URL、或是 API 返回的图片字段。Base64 无处不在，但很多开发者对它的认识停留在「把东西变成乱码」，这个理解其实差了一截。
一、Base64 是什么？先从「为什么需要它」说起
很多早期的通信协议（SMTP、HTTP/1.1）在设计时只考虑了纯文本（ASCII 字符）的传输。当你要传送图片、PDF 等二进制数据时，这些协议无法正确处理。Base64 的解决方式：把每 3 个 byte（24 bits）重新分组成 4 个 6-bit 数字，用 64 个字符的字母表表示，让任何二进制数据都可以用纯文本字符表达。
| 特性 | 说明 |
|---|---|
| 字符集 | A–Z（26）、a–z（26）、0–9（10）、+、/，共 64 个字符 |
| 填充字符 | =，用来对齐 3 的倍数 |
| 大小膨胀 | 原始数据增加约 33% |
直接试试看：Base64 编解码工具可以把任意文本或数据编码成 Base64，或把 Base64 字符串还原成原始内容。
二、Email 附件里的 Base64（MIME）
Email 使用的 SMTP 协议原本只支持 7-bit ASCII 文本。要传送附件需要 MIME 标准，而 MIME 附件通常就是用 Base64 编码的。「查看原始邮件」时看到的那一长串像乱码的文字，就是被 Base64 编码过的文件内容。
三、JWT Token：登录系统里最常见的 Base64
JWT 的格式是三段 Base64url 用 . 分隔。前两段解码后分别是 JSON 格式的 header 和 payload：
header: {"alg":"HS256","typ":"JWT"}
payload: {"sub":"user123","exp":1748000000}重要：JWT 的前两段没有加密，任何人都可以解码阅读。只有第三段签名用来验证内容是否被篡改。JWT 里不应该放密码或敏感数据。
解码 JWT：把 JWT 的第一或第二段贴入Base64 解码工具，可以直接看到 JSON 内容。解码后贴入JSON 格式化工具可以更清晰地阅读结构。
四、Data URL：HTML/CSS 里内嵌的图片
Data URL 可以把整个文件直接内嵌在 HTML 或 CSS 里，不需要额外的 HTTP 请求：
<img src="data:image/png;base64,iVBORw0KGgo...">常见于 Email 模板、小图标优化、离线应用等场景。
五、Base64 常见误解
- Base64 不是加密：它是编码，任何人都可以立刻解码，不需要密钥
- Base64 不压缩数据：反而增加约 33%
- 末尾的
=是对齐填充，不是加密符号 - URL 里用 Base64url 变体：用
-和_代替+和/
URL 里的编码处理：URL 编解码工具可以帮你处理 URL 里的特殊字符转换。
总结
- Base64 把二进制数据转成 64 个纯文本字符，让它可以在只支持文本的协议里传输
- Email 附件（MIME）、JWT Token、Data URL、Basic Auth 都是 Base64 最常见的应用
- JWT 的 header 和 payload 只是 Base64url 编码，没有加密——任何人都可以解码
- Base64 不是加密，数据大小反而增加 33%