Base64 turns every three input bytes into four text characters. In ASCII-compatible storage that is a 4-to-3 ratio, or approximately 33.33% more data.
The familiar 33% figure is an asymptote, not a universal exact result. Padding makes tiny inputs proportionally larger, while Data URL prefixes, MIME line breaks, JSON syntax, and transport compression change the complete envelope.
Why 24 bits become four characters
Three bytes contain 24 bits. Base64 splits those bits into four 6-bit groups. Each group selects one of 64 alphabet characters. No compression occurs; the same information is regrouped for a text-only channel.
For lengths divisible by three, encoded length is input length / 3 × 4. A 3 MB payload therefore becomes about 4 MB before prefixes or surrounding syntax.
3 bytes = 24 bits
24 / 6 = 4 Base64 symbols
4 / 3 = 1.3333...The exact formula and padding
For n input bytes, padded Base64 length is 4 × ceil(n / 3). One remaining byte creates two data symbols and two equals signs; two remaining bytes create three data symbols and one equals sign.
One byte becoming four characters is 300% overhead, while two bytes becoming four is 100%. As n grows, the ratio approaches 33.33%.
| Input bytes | Output characters | Increase |
|---|---|---|
| 1 | 4 | 300% |
| 2 | 4 | 100% |
| 3 | 4 | 33.33% |
| 6 | 8 | 33.33% |
| 1,000 | 1,336 | 33.6% |
Padding removal changes little
Base64URL and some protocols omit equals padding when length is known elsewhere. This saves at most two characters, not the main 4-to-3 expansion.
Padding is block-completion metadata, not encryption and not hidden content. A decoder can often restore omitted padding from the encoded length.
Prefixes and containers add more
A Data URL adds a prefix such as data:image/png;base64,. JSON adds quotes and possible escapes. MIME may insert CRLF line wrapping. Measure the complete representation rather than only the alphabet characters.
Runtime string memory is implementation-dependent; character count does not always equal exact JavaScript heap bytes.
What gzip changes
General compression can exploit patterns in Base64, so compressed network overhead may be lower than 33%. Compare compressed binary with compressed Base64 under identical conditions.
Already-compressed JPG, PNG, ZIP, PDF, and video bytes provide little redundancy. Storage, parsing, memory, and CPU overhead remain even if gzip narrows transfer size.
When to avoid Base64
Use binary request bodies, multipart uploads, or Blob URLs when available. Base64 is appropriate for small values in text-only protocols or APIs that explicitly require it.
- Do not use Base64 as compression.
- Do not use it as encryption.
- Limit decoded size, not only string length.
- Keep large local previews as Blob URLs.
Key takeaways
The 33% comes from storing four 6-bit symbols as four text bytes for every three input bytes. Use 4 × ceil(n / 3) for exact padded length, then calculate prefixes and container syntax separately.