The exact math, not just "roughly bigger"
Both encodings inflate size by a fixed, calculable ratio:
- Hex: output characters = input bytes × 2 (always exact, no rounding).
- Base64: output characters = ⌈input bytes ÷ 3⌉ × 4 (rounded up to the next group of 4, with
=padding filling any remainder).
Worked example: a 1 MB file
| Encoding | Formula | Output size | Overhead |
|---|---|---|---|
| Original | — | 1,048,576 bytes | — |
| Hex | ×2 | 2,097,152 characters | +100% |
| Base64 | ÷3 × 4 (rounded) | ~1,398,104 characters | +33.3% |
For any payload, hex's overhead is a flat 100% regardless of size; Base64 settles at almost exactly 33.3% once the input is reasonably large (small inputs see slightly more overhead due to padding rounding — a 1-byte input becomes 4 Base64 characters, a 300% inflation, because the minimum output group is always 4 characters even for 1–2 leftover bytes).
Why the ratios never change
Hex is fixed at 2 characters per byte because its 16-character alphabet encodes exactly 4 bits per character — 2 characters cover a full 8-bit byte, no more, no less, no rounding needed at any input size. Base64 groups 3 bytes (24 bits) into 4 characters (4 × 6 bits = 24 bits) — a clean division that only needs padding at the very end of the input, not throughout, which is why its overhead approaches (but never quite reaches) a flat 33.3% as payload size grows.
When the difference actually matters
- Small payloads (a UUID, a short token): the percentage difference is real but the absolute byte difference is trivial — pick based on readability needs, not size.
- Large payloads (embedded images, file transfers): the difference compounds — a 10 MB file becomes ~20 MB in hex versus ~13.3 MB in Base64, a meaningful gap for bandwidth or storage-constrained contexts.
Common mistakes
- Assuming both encodings inflate by the same amount. Hex is always exactly double; Base64 is roughly a third larger — not interchangeable assumptions.
- Forgetting padding rounding for very small inputs. A single byte becomes 4 Base64 characters (not the "expected" ~1.33), since the minimum output unit is always a full 4-character group.
- Choosing hex for a large embedded asset out of habit, when the same data in Base64 would be meaningfully smaller for the same underlying bytes.
FAQ
Does Base64 overhead change with input size?
It converges toward 33.3% as input grows; very small inputs (1–2 leftover bytes) see proportionally more overhead due to padding rounding to the nearest 4-character group.
Is hex overhead always exactly 100%?
Yes — every byte becomes exactly 2 hex characters, with no rounding or padding involved at any size.
For a 10 MB file, how much bigger is Base64 output than hex output?
Base64 comes out to roughly 13.3 MB versus hex's roughly 20 MB — hex is about 50% larger than Base64 for the same original data.
Calculate exact output sizes for real payloads with the Base64 Encoder/Decoder — processed entirely in your browser.