为什么 Base64 会让图片体积增加 33%？一文读懂编码原理
深入解析 Base64 编码原理，为什么它会导致文件体积膨胀？在 Web 开发中何时应该使用 Base64，何时应该避免？
记得刚入行时，我特别喜欢把小图标转成 Base64 塞进 CSS 里，觉得这样能减少 HTTP 请求，显得技术很"极客"。直到有一次，我把一张 2MB 的高清背景图也转成了 Base64，结果生成的 CSS 文件直接把浏览器卡死了，页面加载慢得像蜗牛。那次经历让我深刻意识到：Base64 是一把双刃剑，用好了是神器，用不好就是性能杀手。
最坑爹的是有些后端接口限制 payload 大小，比如限制 2MB。产品经理说"不就传张图吗，怎么会超"，结果前端转 Base64 后体积直接暴涨到 2.6MB，请求直接被拦截。每次都要跟非技术人员解释"为什么 2MB 的图片转成字符串就变大了"，真的心累。
1. 什么是 Base64？
Base64 是一种基于 64 个可打印字符来表示二进制数据的表示方法。这 64 个字符包括 `A-Z`、`a-z`、`0-9` 以及 `+` 和 `/`。它的核心目的不是为了"加密"（Base64 没有任何安全性可言），而是为了让二进制数据（如图片、音频）能够安全地在只支持文本传输的协议（如早期的电子邮件、HTML、CSS）中传输。
2. 为什么体积会增加 33%？
这个增量来自 Base64 的编码规则。计算机中 1 个字节（Byte）等于 8 位（bit）。而 Base64 的字符集只有 64 个字符，$2^6 = 64$，所以一个 Base64 字符只能携带 6 位信息。
这就意味着，原本 3 个字节的数据（$3 \times 8 = 24$ 位），需要用 4 个 Base64 字符（$4 \times 6 = 24$ 位）来表示。
3 Bytes (原始数据) 4 Bytes (Base64 编码)
体积增长比率：(4 - 3) / 3 ≈ 33.3%
这还没算上可能存在的填充字符（=）和换行符。所以，粗略估算，任何文件转成 Base64 后，体积都会膨胀三分之一。
3. 何时该用，何时不该用？
推荐场景
- • 极小的图标：如 2KB 以内的 Icon，转为 Base64 内联在 CSS 中，可以减少一次 HTTP 请求，提升页面加载速度。
- • 关键渲染路径资源：为了避免页面闪烁，某些关键的小图可以内联。
- • Canvas 导出：Canvas 的 `toDataURL()` 方法默认输出 Base64，方便进行后续处理。
避免场景
- • 大图/照片：体积膨胀会导致 CSS/HTML 文件过大，阻塞关键渲染路径。
- • 需要缓存的资源：Base64 嵌入 HTML 后，无法享受浏览器的独立文件缓存机制。HTML 更新，图片也就跟着重新下载。
- • 移动端页面：Base64 解码需要消耗 CPU，大量使用可能导致页面卡顿。
需要进行转换？
如果你需要快速将图片转为 Base64，或者将 Base64 还原为文件，可以使用 OneKit 的 Base64 编解码工具。它支持文本和文件的双向转换，且所有操作均在浏览器本地完成，不会上传你的数据，安全又快捷。