Base32, Base58, Base85: When Base64 Is the Wrong Encoding

Base64 Won by Default, Not by Being Optimal

Base64 is so entrenched that most developers never consider an alternative. It's in email, in data URLs, in JWTs, in every API that has to move a binary blob through a JSON field.

But Base64 makes a specific set of tradeoffs, and those tradeoffs are wrong for plenty of situations. Its alphabet is case-sensitive, which makes it hostile to anything a human has to read aloud or type. It includes characters that are ambiguous in common fonts. And its 33% expansion is average, not good.

Other encodings exist because people hit those walls. Each one is Base64 with a different dial turned.

The Underlying Tradeoff

Every binary-to-text encoding balances two things: alphabet size and safety.

A bigger alphabet packs more bits per character, so the output is shorter. But a bigger alphabet means using more characters, and more characters means a higher chance one of them breaks something downstream.

The math is simple. With an alphabet of n symbols, each character carries log₂(n) bits:

Base64 sits at a genuinely convenient spot — 64 is a power of two, so three bytes map cleanly onto four characters with no leftover bits. That clean alignment is a big part of why it won.

Base32: Built for Humans and Case-Insensitive Systems

Base32 uses 32 characters, standardly A–Z plus 2–7. Five bytes become eight characters, a 60% expansion — noticeably worse than Base64.

You pay that penalty for real benefits:

Case insensitivity. The alphabet is uppercase only, so nothing breaks when a system lowercases your string. DNS is case-insensitive. Some filesystems are case-insensitive. Base64 strings passing through either can be silently corrupted; Base32 strings can't.

No ambiguous characters. The digits 0, 1 and 8 are excluded specifically because they're confusable with O, I/l and B in many typefaces.

Human-transcribable. People can read Base32 over the phone and type it into a form without much trouble. This is exactly why TOTP secrets — the string behind your authenticator app — are Base32. You have to be able to type them.

Base32 also shows up in Tor onion addresses, in some DNS-based protocols, and in Crockford's Base32 variant, which goes further by treating I, L and O as aliases for 1, 1 and 0 during decoding so common transcription mistakes self-correct.

Base58: Bitcoin's Anti-Typo Alphabet

Base58 is Base62 (alphanumerics) with four characters removed: 0, O, I and l. It was introduced for Bitcoin addresses and has since spread to other identifier systems.

The rationale is entirely about copy-and-transcription safety:

• No visually ambiguous characters. Zero versus capital O, capital I versus lowercase l — the classic confusions, all eliminated.
• No punctuation. Alphanumeric-only strings double-click to select as a single word in most interfaces. Base64's + and / break that.
• Line-break resistant. Because there's no punctuation, the string doesn't get mangled when it wraps in an email or chat client.

The cost is significant complexity. 58 isn't a power of two, so there's no clean bit-level mapping. Base58 encoding requires arbitrary-precision arithmetic — repeated division of the whole input as a big integer. That makes it slower and makes streaming impossible, since you can't encode a chunk without the whole value.

For a 25-byte Bitcoin address, none of that matters. For a 50 MB file, it very much does. Base58 is for short identifiers, full stop.

Base58Check adds a version byte and a four-byte checksum derived from a double SHA-256, so a mistyped address fails validation rather than sending funds into a void.

Base85: When Every Byte of Size Counts

Base85 (and its Ascii85 variant) packs four bytes into five characters — a 25% expansion versus Base64's 33%. On large payloads that's a real saving.

It achieves this by using 85 characters, which is the smallest alphabet where 85⁵ exceeds 2³², making the four-byte-to-five-character mapping possible.

The price is a wide, punctuation-heavy alphabet. Ascii85 uses characters from ! through u, which includes quotes, backslashes, angle brackets and other characters that need escaping in JSON, XML, HTML and shell contexts. A Base85 string dropped into JSON without escaping will break the parser.

Where it's used:

• PDF uses Ascii85 for embedded binary streams.
• PostScript uses it for the same reason.
• Git uses a Base85 variant in binary patch format.
• Z85, a ZeroMQ variant, deliberately chooses an alphabet that's safe for string literals in source code.

If you're considering Base85, ask whether the 8-percentage-point size saving justifies the escaping burden. Usually it doesn't, unless you're the format designer and control the whole pipeline.

Base62: URL-Safe Without the Punctuation

Base62 uses 0–9, A–Z and a–z. Nothing else. Expansion is about 34%, essentially the same as Base64.

Why bother if it's not smaller? Because it's alphanumeric-only, which means:

• Nothing to percent-encode in a URL
• No characters that break shell commands or SQL
• Double-click selects the whole token
• No padding characters

Base62 is common in URL shorteners and public-facing IDs. Like Base58, it needs big-integer arithmetic and isn't streamable, so it's for short values.

Note that base64url — the URL-safe Base64 variant that swaps + and / for - and _ — solves most of the same problem while keeping Base64's clean bit alignment and streaming. If you want URL safety at Base64 speed, base64url is usually the better answer than Base62.

Choosing in Practice

Humans will type or read it aloud → Base32, or Crockford's Base32.

Short public identifier where typos must be caught → Base58Check.

Short URL-safe token → base64url, or Base62 if you specifically need alphanumeric-only.

Arbitrary binary in JSON, email, or a data URL → Base64. It's the default for good reason.

Case-insensitive transport such as DNS → Base32. Base64 is unsafe here.

Large payload in a format you control, size matters → Base85, if you can handle the escaping.

Debugging, hashes, low-level protocol work → hex. It's twice the size and worth it for how easy it is to read byte boundaries.

Try It Yourself

You can encode and decode Base64 in the browser with the Base64 Encoder/Decoder:

1. Paste text or binary content into the input.
2. Choose encode or decode.
3. Copy the result.
4. Compare the output length against your input to see the expansion in practice.

Encoding the same short string and watching how the output length changes as input length crosses each three-byte boundary makes the padding behaviour much easier to internalise than reading about it.

Common Mistakes

Assuming any of these are encryption. All of them are reversible with no key. Encoding is not obfuscation and certainly not security.

Using Base58 or Base62 for large data. The big-integer arithmetic is quadratic in input size. It'll work and then fall over as your inputs grow.

Forgetting Base32's padding. Standard Base32 pads to eight-character blocks with =. Some implementations omit it; mixing padded and unpadded implementations causes decode failures.

Passing Base85 through JSON unescaped. Its alphabet includes quote and backslash characters. This breaks in production, not in testing with short inputs.

Storing Base64 in a case-insensitive database column. Base64 is case-sensitive. A CI collation on that column will corrupt your data.

FAQ

Which encoding is smallest? Of the common ones, Base85 at 25% expansion. Anything smaller needs an alphabet so wide it stops being safely printable.

Is Base58 more secure than Base64? No. Neither provides any security. Base58 reduces transcription errors, which is a usability property.

Why does Base32 exist if Base64 is more efficient? Case insensitivity and human readability. Some transports lowercase strings, and some strings must be typed by hand. Base64 fails at both.

Can I decode Base32 with a Base64 decoder? No. Different alphabets and different bit groupings. You need the matching decoder.

What's the difference between Base64 and base64url? base64url replaces + with - and / with _, and usually drops padding, so the output is safe in URLs and filenames without percent-encoding.

The Takeaway

Base64 is a reasonable default and a poor universal answer. The question worth asking is what your string has to survive — a human typing it, a case-insensitive lookup, a JSON parser, a URL, a phone call — and picking the alphabet that survives it.

Try the free Base64 Encoder/Decoder at sadiqbd.com — no sign-up, instant results.