Base64 编码后变大多少
Base64 用 4 个字符表示 3 个字节，所以体积固定增加约 1/3。精确的字符串长度是 4 × ⌈字节数 ÷ 3⌉——每 3 个字节变成 4 个字符，最后一组不足的用填充符补齐。
- 字符数 = 4 × ⌈字节数 ÷ 3⌉
- 1 MB 的二进制 → 约 1.37 MB 的字符串
- Base64 字符都是 ASCII，UTF-8 下 1 字节/字符
- 放进 URL 还要再算百分号编码的膨胀
粘贴即自动处理，不用点按钮（Ctrl+Enter 立刻转换 / Esc 清空）
拖文件进来，或 ——截图直接 Ctrl+V 也行
任意类型 · 100 MB 封顶
粘贴、拖拽、Ctrl+V 截图都行
精确公式与三个例子
长度 = 4 × ⌈n / 3⌉，n 是原始字节数：每 3 字节一组，最后一组不足 3 字节用 = 补齐。
| 原始大小 | Base64 字符数 | 膨胀 |
|---|---|---|
| 1 KB（1024 B） | 1368 | 133.6% |
| 1 MB（1048576 B） | 1398104 | 133.3% |
| 10 MB | 13981016 | 133.3% |
为什么感觉不止 33%
- 换行：MIME/PEM 每 76 字符换行，多出约 1.3%
- JSON 转义：字符串进 JSON 时若带换行或特殊字符，会再涨一点
- 内存里的表示：Base64 字符都是 ASCII，UTF-8 下 1 字节/字符，这一项不额外膨胀；但如果语言内部按 UTF-16 存字符串，内存占用直接翻倍
- URL 编码：把
+/=放进 URL，每个都会变成 3 个字符
什么时候该在意这个数字
接口 body 有上限（常见 1–10 MB）、日志按行截断、数据库字段长度固定——这三种场景下，那 33% 往往就是压垮请求的最后一根稻草。解法不是「压缩字符串」（Base64 几乎不可压），而是别把二进制塞进 JSON：改用对象存储加链接。
常见问题
为什么有时候是 4/3 倍，有时候更多？
4/3 是理论下限。加上填充符、换行、JSON 转义和 URL 编码，实际传输体积会略高；内存里按 UTF-16 存则是字符数的 2 倍。
能压缩 Base64 字符串吗？
对已编码的字符串做通用压缩收益很低：Base64 是 6 位一组的均匀分布，几乎不可压。要省体积，应该在编码前压缩原始数据，或者干脆不编码。
Base64URL 会更小吗？
不会。它只是换了两个字符并去掉填充，字符数基本一样（少 0–2 个），换来的是能放进 URL，不是更小。