为什么 Base64 会让文件变大？

本文说明 Base64 输出为何比原始字节更大。这不是安全指南。若需要区分编码与加密，请看 Base64不是加密：它实际在做什么。

为什么 Base64 需要更多空间？

3 个字节是 24 位。Base64 把这 24 位切成 4 组、每组 6 位。每组对应一个 Base64 字符，于是 3 个输入字节变成 4 个输出字符。按每个 ASCII 字符 1 字节存储，就是 4 / 3 ≈ 1.333——大约增加 33.3%。

• 3 字节（24 位）
• ↓
• 分成 4 组、每组 6 位
• 每组 → 一个 Base64 字符
• ↓
• 4 个字符（文本时常占 4 字节）

一个可核对的简单例子

这些编码与标准带填充的 Base64 一致。

Man

Man

Base64

TWFu

Man 是 3 个 UTF-8/ASCII 字节。TWFu 是 4 个字符：3 → 4。

Hello

Hello

Base64

SGVsbG8=

Hello 是 5 个字节。SGVsbG8= 是 8 个字符，含一个 =。小数据上，填充会让百分比看起来大于 33%。

怎样计算 Base64 体积？

对于标准带填充的 Base64，encodedLength = 4 × ceil(originalBytes / 3)。

原始字节	Base64 字符数
1	4
2	4
3	4
4	8
5	8
6	8

1 或 2 个字节仍会得到 4 个字符。请用公式，不要用固定的 33%。

“=” 填充表示什么？

= 标记表示最后一组 3 字节没有填满。1 个输入字节用两个 =；2 个字节用一个；3 个字节不用。填充不是加密，也不是安全特性。

Base64URL 更省空间吗？

Base64URL 把 + 改成 -、把 / 改成 _，并且 Base64 编码解码 在编码时去掉末尾的 =。字符串可能因此少掉那些 =。3 字节 → 4 字符的结构不变，所以 Base64URL 并不是更省空间的二进制格式。

为什么很小的输入会增大超过 33%？

1 字节 → 4 字符，长度增加 300%。2 字节 → 4 是 100%。3 字节 → 4 约 33.3%。随着 n 变大，填充的影响变小，开销接近约 33%。Base64 并不总是刚好大 33%。

为什么 Base64 Data URL 还要更大？

Data URL 会在载荷前加上 data:image/png;base64, 这类前缀。很小的文件上，前缀可能占满百分比。Base64 编码解码 可以输出原始 Base64 或 Data URL；Data URL 使用标准字母表。

Base64 和二进制，谁更小？

原始二进制在传输和存储上更省空间。Base64 更大，但在 JSON、邮件和其他纯文本路径里是文本安全的。这是二进制到文本的编码，不是压缩。

Base64 会压缩文件吗？

不会。Base64 不是压缩格式。编码后的文本通常比原始字节更大。若再对那段文本做 gzip 或 Brotli，部分冗余可能缩小——取决于数据和压缩器。gzip 不会彻底去掉 Base64 开销。

Base64 再经过 gzip 会怎样？

HTTP 压缩可以削减 Base64 文本里的部分重复模式。JPEG、PNG 或 ZIP 即便作为原始字节也常常不好压，先 Base64 再 gzip 同样因数据而异。gzip 之后没有统一的额外百分比。

该不该把文件存成 Base64？

Base64 可以把二进制放进 JSON 字段、小的内联资源、纯文本 API、复制粘贴或 Data URL。大文件上，存储、内存和载荷都会变大。这并不是说“永远别对文件用 Base64”。

为什么 JSON API 里常见 Base64？

JSON 没有原生的原始二进制类型，所以接口常把字节放进 Base64 字符串。大文件时，multipart/form-data、对象存储或直接二进制上传可能更合适。两种选择都不是永远最好。

为什么邮件里用 Base64？

MIME 可以用 Base64，让二进制附件以文本安全的字符传输。同样的体积开销仍然存在。这是传输表示，不是更小的文件。

什么时候这点额外体积划算？

当二进制必须放进文本、载荷较小、接口要求 Base64、或你需要 Data URL 时，额外体积可能划算。对大型媒体，系统允许的话优先用原始二进制。

什么时候该避开 Base64？

大文件、带宽紧张、频繁传输、或已经有二进制通道时可以跳过——这是情境问题，不是“Base64 是坏习惯”。

可核对的带填充 Base64 长度

原始字节数与标准带填充 Base64 字符数：

原始字节数	Base64 字符
1	4
2	4
3	4
10	16
100	136
1,000	1,336

每一行都遵循 4 × ceil(n / 3)。这些是 Base64 字符个数。

例子：1,000 字节的文件会变成多大？

4 × ceil(1000 / 3)。ceil(333.333…) = 334，4 × 334 = 1336。所以 1,000 字节变成 1,336 个 Base64 字符。按 UTF-8/ASCII 存储时每个字符通常 1 字节——不要把 1,336 当成精确的内存字节数。

Base64 占用的内存会比文件大小暗示的更多吗？

有些运行时按每个字符超过 1 字节来存字符串，编码/解码还可能同时保留缓冲区和字符串。内存用量并不恰好等于字符长度。

一份简单的体积取舍指南

系统若接受原始二进制，为体积请优先用它。只允许文本时，Base64 可能合适。载荷很大时，先找二进制上传通道。需要 URL 安全文本时，可考虑 Base64URL——3 变 4 的扩大仍然在。

• 需要发送二进制数据
• ↓
• 允许原始二进制？为体积优先二进制
• 纯文本字段？Base64 可能合适
• 大载荷？检查是否有二进制上传通道
• 需要 URL 安全文本？考虑 Base64URL
• ↓
• 大输入上预期大约多 33% 的文本

在浏览器里编码或解码 Base64

NEXNARA Base64 编码解码 可编码和解码文本，也能把文件转成 Base64 或 Data URL，再把 Base64 转回文件。

文本先按 UTF-8 字节再做 Base64，不是仅限 ASCII。可选 Standard 或 Base64URL。文件输出可以是原始 Base64 或 Data URL（标准字母表）。非法输入会被拒绝。非 UTF-8 字节应转到文件，不要当文本解码。

超过 10 MB 的文件可能拖慢标签页（会警告）。超过 32 MB 的文件会被拦截。

编码和解码在你的浏览器里完成。本工具不会把文件发到 NEXNARA 服务器。广告和其他站点功能仍会使用网络。

在 Base64 编码解码 中粘贴文本或文件，对比原始字节和编码后的长度。

FAQ

为什么 Base64 会增加文件体积？

它把 3 字节（24 位）映射成 4 个字符（4 × 6 位）。存成文本后，较大输入大约多三分之一。

Base64 总是大 33% 吗？

不是。较大输入接近约 33.3%。很短的输入会因填充增得更多。请用 4 × ceil(n / 3)。

Base64 比二进制大多少？

标准带填充长度是 4 × ceil(n / 3) 个字符。Data URL 前缀还会再加。

Base64 压缩能减小文件吗？

Base64 不压缩。对编码文本再用 gzip 或 Brotli 可能缩小一部分；它们不会在每种情况下都抹掉开销。

Base64URL 更省空间吗？

它可以去掉 = 填充，字符串可能短 0–2 个字符。3 变 4 的编码结构相同。

大文件该用 Base64 吗？

只在需要文本时。对于大或频繁的传输，二进制通道往往更小。API 使用 Base64 并不总是错。