Base64 is predictable enough that “about 33% larger” is useful shorthand—but it is not exact for small inputs. Padding makes one byte become four characters (300% larger), two bytes become four (100% larger), and only large payloads converge toward one-third overhead. Z Tools now records that behavior with deterministic raw-byte test cases instead of repeating the shorthand without context.
The exact length formula
Standard Base64 represents each 24-bit group (three bytes) as four 6-bit symbols. For an input of n bytes, padded Base64 has 4 × ceil(n / 3) output characters. The = padding markers do not carry payload data; they preserve group alignment when the final group contains one or two bytes.
Z Tools verification run
The bundled offline suite generated deterministic byte buffers and encoded them with the JavaScript runtime. These values are in benchmarks/results/browser-results.json.
| Input bytes | Base64 chars | Size change |
|---|---|---|
| 1 | 4 | +300% |
| 2 | 4 | +100% |
| 3 | 4 | +33.33% |
| 100 | 136 | +36.00% |
| 1,024 | 1,368 | +33.59% |
| 10,000 | 13,336 | +33.36% |
A reproducible three-byte example
The ASCII bytes for Man are 4D 61 6E. Written as bits, they are 01001101 01100001 01101110. Regrouping into six-bit values yields 010011 010110 000101 101110, or decimal 19, 22, 5, 46. Looking those indexes up in the RFC 4648 alphabet gives TWFu.
Why text encoding must start from bytes
For Unicode text, the browser first needs a byte representation. Z Tools uses UTF-8, so é, Chinese characters, and emoji can occupy multiple bytes even when JavaScript reports a smaller character count. This is why the tool shows byte-oriented status for file workflows and does not treat string length as a file-size measurement.
Data URLs add more than Base64 overhead
A Data URL starts with metadata such as data:image/png;base64, before the encoded payload. For tiny assets, that fixed prefix plus Base64 padding can dominate the total size. For larger assets, the Base64 portion converges toward 4/3 while the prefix becomes negligible. This is one reason “inline every image” is not a general optimization rule.
Base64 is not encryption
Anyone can reverse the transformation. Base64 is for transport through text-oriented formats, not confidentiality or authenticity. JWT segments are a good example: their readable header and payload are Base64URL encoded, while trust comes from signature verification—not the encoding.
Standard vs Base64URL
RFC 4648 defines both. Base64URL substitutes - for + and _ for / so encoded data fits URL contexts without treating those two symbols as structural characters. Some protocols also omit padding when the length can be inferred.
What the Z Tools Base64 tool actually does
- UTF-8 text encode/decode happens locally.
- Local files can be read into memory and converted to Base64/Data URLs without uploading them.
- A valid Base64/Data URL can be reconstructed as a downloadable Blob.
- Malformed input is rejected rather than silently converted to replacement text.
Practical takeaway
Use the exact formula when storage/bandwidth matters, not a blanket 33% assumption. Base64 is excellent when a text-only container is mandatory; it is usually wasteful when raw binary can travel directly over HTTP.