Base64 把每三个输入字节变成四个文本字符。在 ASCII 兼容存储中，这就是 4:3，约增加 33.33%。
33% 是渐近值，不是所有输入的精确比例。小输入会因 padding 膨胀更多，Data URL 前缀、MIME 换行、JSON 语法和传输压缩也会改变完整大小。
为什么 24 bit 变成四个字符
三个字节包含 24 bit，Base64 把它们切成四组 6 bit，每组从 64 个字符中选择一个。它不压缩，只为纯文本通道重新分组。
长度能被三整除时，输出长度 = 输入长度 / 3 × 4；3 MB 负载在前缀和容器语法之前约变成 4 MB。
3 字节 = 24 bit
24 / 6 = 4 个 Base64 符号
4 / 3 = 1.3333...精确公式与 padding
n 字节输入的标准长度是 4 × ceil(n / 3)。剩一个字节时产生两个数据符号和两个等号；剩两个字节时产生三个数据符号和一个等号。
1 字节变 4 字符是 300% 开销，2 字节变 4 字符是 100%；输入增大后趋近 33.33%。
| 输入字节 | 输出字符 | 增加 |
|---|---|---|
| 1 | 4 | 300% |
| 2 | 4 | 100% |
| 3 | 4 | 33.33% |
| 6 | 8 | 33.33% |
| 1,000 | 1,336 | 33.6% |
去掉 padding 作用很小
Base64URL 和部分协议在其他地方已知长度时会省略等号，最多节省两个字符，无法消除 4:3 膨胀。
Padding 是块补齐信息，不是加密或隐藏内容，解码器通常能按长度补回。
前缀与容器继续增加大小
Data URL 增加 data:image/png;base64, 前缀，JSON 增加引号与转义，MIME 可能加入 CRLF 换行。应测量完整表示。
运行时字符串内存由引擎实现决定，字符数不一定等于精确堆内存字节。
gzip 会改变什么
通用压缩能利用 Base64 模式，因此线上压缩后的差距可能低于 33%；必须在相同条件下比较压缩二进制和压缩 Base64。
JPG、PNG、ZIP、PDF 和视频等已压缩数据冗余很少；即使网络差距缩小，存储、解析、内存和 CPU 开销仍在。
什么时候应避免 Base64
接口允许时使用二进制请求体、multipart 或 Blob URL。Base64 更适合纯文本协议中的小值，或 API 明确要求的场景。
- 不要把 Base64 当压缩。
- 不要把它当加密。
- 限制解码后大小，不只限制字符串。
- 大型本地预览使用 Blob URL。
总结
33% 来自每三个输入字节需要四个文本字节。精确带 padding 长度用 4 × ceil(n / 3)，前缀和容器语法另行计算。