Step 1 of 5 · Reading · ~1 min
Read
Variants
Putting It All Together
You've built every layer:
| Layer | What it gave you |
|---|---|
| Why Base64 | the problem: bytes through a text-only channel, at 33% cost |
| The Base64 Alphabet | 6 bits per character, and what = is not |
| Encode: 3 Bytes to 4 Chars | packing 24 bits and slicing them into four groups |
| Padding | what a short final group emits, and what the decoder reads back |
| Decode: 4 Chars to 3 Bytes | the inverse, and trimming by pad count |
| Decode Errors | which inputs a strict decoder must refuse |
| Base64URL | the two-character substitution, and dropped padding |
Beyond:
- Base85 (Ascii85): 4 bytes → 5 chars (vs 3 → 4 in base64). Smaller. Used in PDF and Git binary patches.
- Base91 / yEnc: even smaller for binary-in-text. Niche.
- Hex: simpler but 2x overhead instead of 1.33x.
- Base32 / Base32-Crockford: case-insensitive variants for human-typeable data.
- MIME quoted-printable: efficient for mostly-ASCII data with occasional binary.
When NOT to use base64:
- Files for which native binary works (HTTP body, gRPC)
- Storage (33% bigger)
- Hot loops (encoding overhead)
Where you've seen it:
- Email attachments (MIME)
- Data URIs (
data:image/...;base64,) - HTTP Basic auth
- JWT
- PEM-encoded keys/certificates
- TOTP secrets (Base32)
Discussion
Ask a question, share an insight, or help someone who’s stuck.
Sign in to post a comment or reply.
Loading…