Base32 vs Base64: when bigger overhead is the better choice

Base64 packs 6 bits per character and expands data by 33%. Base32 packs 5 bits per character and expands data by 60%. Base32 seems strictly worse, but it has one critical advantage: it's case-insensitive and avoids visually confusable characters. For data that humans type or read aloud, Base32's extra overhead is worth the usability gain.

Encoding focus
Base32 vs Base64
base32-vs-base64
Category
Format Comparison
Comparing encoding schemes side by side

How this is calculated

Base32 is used for OTP secrets (the 16-character codes you type into Google Authenticator), product license keys, and recovery codes. The RFC 4648 Base32 alphabet excludes 0, 1, 8, and 9 to avoid confusion with O, I/l, B, and g/q. Base64's alphabet includes letters in both cases, digits, +, and /, making it error-prone for human transcription. If a user is going to type the encoded value, Base32. If machines are exchanging it, Base64.

Verdict

Base64 for machine-to-machine data exchange. Base32 for anything a human will type, read, or transcribe. The overhead difference (33% vs 60%) is negligible for the small payloads (a few dozen bytes) where human readability matters.

More Encoding scenarios

Frequently asked questions

How do I convert text to Base64?
Paste your string into the Text field and the Base64 output appears instantly. The tool uses standard Base64 (RFC 4648), so the output is identical to Linux's base64 command and every major language's built-in Base64 encoder.
What's the difference between Base64 and hex encoding?
Both represent binary data as text, but with different alphabets. Base64 uses 64 characters and needs roughly 4 chars per 3 bytes (33% overhead). Hex uses 16 characters and needs exactly 2 chars per byte (100% overhead). Base64 is denser, while hex is easier to read byte by byte.
Why does my UTF-8 text break when converted to binary?
UTF-8 encodes non-ASCII characters as multibyte sequences, so a single emoji or accented letter becomes 2-4 bytes. The binary output will be longer than the character count suggests, that's correct behavior, not a bug.
Is it safe to paste sensitive data into the converter?
Yes. The encoding conversion runs entirely in your browser with JavaScript, nothing is sent to our servers, logged, or stored. You can verify this with your browser's Network tab: no requests fire when you type.
What is URL-safe Base64?
A variant that replaces `+` with `-` and `/` with `_` so the result can be safely placed in URLs without percent-encoding. JWT tokens use URL-safe Base64. Standard Base64 is fine for most other uses.
Can I decode Base64 back to the original text?
Yes, the converter is bidirectional. Paste Base64 into the Base64 field and you'll get the original UTF-8 string back. If decoding fails silently, the input isn't valid Base64 (wrong characters, bad padding, or it was double-encoded).