Two encodings, two different tradeoffs
Both hex and Base64 turn arbitrary bytes into printable text, but they trade off size against readability differently:
| Hex | Base64 | |
|---|---|---|
| Alphabet size | 16 characters (0-9a-f) |
64 characters |
| Bytes per output character | 0.5 byte (2 chars per byte) | 0.75 byte (4 chars per 3 bytes) |
| Size inflation vs. original | 100% larger (2x) | ~33% larger |
| Human-readability | Easy to eyeball, byte-aligned | Not directly readable |
Hex encodes 1 byte as exactly 2 characters (0xFF → ff), always a clean 2:1 ratio. Base64 packs more efficiently — 3 bytes into 4 characters — because its larger 64-character alphabet carries more information per character (6 bits vs. hex's 4 bits per character).
Why hex still gets chosen despite being larger
Hex's appeal isn't efficiency — it's direct byte-level readability. Each pair of hex characters maps to exactly one byte, no grouping math required, which is why hash digests (MD5, SHA-256), color codes, and memory dumps are conventionally shown in hex: a developer can visually map ff to 255 or 11111111 without decoding a denser alphabet. Base64 has no such direct visual correspondence — you can't glance at a Base64 character and know which bits it represents without a lookup table.
Where each actually gets used
- Hex: hash digests, color codes (
#FF6B35), MAC addresses, memory/byte-level debugging — anywhere byte-level readability matters more than compactness. - Base64: embedding binary in JSON/XML/URLs, data URIs, JWT segments, email attachments — anywhere size matters more than direct readability, and the data is consumed programmatically, not eyeballed.
Common mistakes
- Choosing hex for large binary payloads "for clarity." The 2x size penalty adds up fast for anything beyond a short digest or identifier — Base64's ~33% penalty is far more reasonable for embedding files or large blobs.
- Assuming hex and Base64 encode the same data identically in size. They don't — the same input always produces roughly 50% more characters in Base64 output than the equivalent hex would need... in the opposite direction: hex is the larger one, not smaller, despite looking shorter for very short inputs due to fixed per-byte width.
- Trying to convert between hex and Base64 directly as strings. You must decode back to the original bytes first, then re-encode in the target format — treating one encoded string as if it were input to the other format corrupts the data.
FAQ
Which produces a smaller output, hex or Base64?
Base64 — roughly 33% larger than the original, versus hex's 100% (2x) expansion, because Base64's larger alphabet packs more bits per output character.
Why are hash digests shown in hex instead of Base64?
Readability and convention — each hex character maps to exactly 4 bits, giving a direct, easy-to-eyeball correspondence to the underlying bytes that Base64 doesn't offer.
Can I convert a hex string directly to Base64 without losing data?
Yes, but only by decoding the hex back to its original bytes first, then Base64-encoding those bytes — treating the hex characters themselves as Base64 input would encode the wrong data entirely.
Convert between encodings and generate hash digests with the Base64 Encoder/Decoder and Hash Generator — both run entirely client-side.