Base64 vs Base32 vs Base58 vs Base85: which encoding, and why

Binary-to-text encodings exist because a lot of systems that carry text will mangle arbitrary bytes. Every one of them pays for safety with size, and they differ in what they are optimising for: the smallest output, surviving a case-insensitive system, being read aloud, being pasted into source code. Picking the wrong one usually works — until the output passes through the one system it was not designed for.

The short answer

What each one costs, measured

We ran the same 3,000 random bytes through each encoder. Three thousand divides evenly by three, four and five, so padding does not distort the ratio:

The Base58 figure matches the theory: each character carries log₂58 ≈ 5.858 bits, so a byte needs 8 ÷ 5.858 ≈ 1.366 characters. It is the only row without a fixed packing ratio, and that turns out to matter for more than size.

Base64: the default, for good reason

Base64 is the densest encoding that is safe almost everywhere text goes, which is why email attachments, data URIs, PEM certificates and most APIs use it. Its 64 characters are the upper and lower case letters, the digits, + and /, with = as padding.

The gotcha is those last two characters. In a query string + means a space, and / is a path separator. Any Base64 that ends up in a URL, a filename or a cookie should be the URL-safe variant from RFC 4648 §5, which swaps them for - and _ and usually drops the padding. JWTs use exactly that. More on the format in the Base64 glossary entry.

Base32: when case or humans get involved

Base32 uses only uppercase letters and the digits 2 to 7. That makes it 60% larger than the input instead of 33%, and it buys robustness: Base32 survives case-insensitive storage, DNS labels, case-folding filesystems and being dictated down a phone line. That is why TOTP authenticator secrets in otpauth:// URIs are Base32, and why DNSSEC uses it for NSEC3 hashes.

There are four alphabets in real use, and the same string decodes differently under each: the RFC 4648 standard alphabet; RFC 4648's extended-hex alphabet, whose digits-first ordering means encoded strings sort in the same order as the bytes; Douglas Crockford's, which drops I, L, O and U and, when decoding, reads I and L as 1 and O as 0 so a misread character still lands on the right value; and z-base-32.

The gotcha is the final character. It only carries part of a byte, and RFC 4648 says the unused low bits must be zero. Most decoders do not check: we tried MZXW6YTBOJ====== — one letter off the canonical MZXW6YTBOI======— and both Python's b32decode and Go's base32.StdEncoding returned foobar without complaint. So two different strings decode to the same bytes, which quietly breaks anything that compares encoded values — a cache key, a deduplication check, a signature over the encoded form. It also usually means the value was truncated or hand-edited. Our Base32 tool decodes such strings and says so, rather than silently discarding the bits.

Base58: built for people copying addresses

Base58 exists for one job: values that people copy, paste and occasionally retype, such as Bitcoin addresses and IPFS content identifiers. The rationale is spelled out in a comment in Bitcoin's source:

Don't want 0OIl characters that look the same in some fonts and could be used to create visually identical looking data. A string with non-alphanumeric characters is not as easily accepted as input. E-mail usually won't line-break if there's no punctuation to break at. Double-clicking selects the whole string as one word if it's all alphanumeric.

Every one of those is a reason Base64's +, / and = were unacceptable. It is also not a bit-packing scheme at all: 58 is not a power of two, so the whole input is treated as one big integer and repeatedly divided by 58. That has two consequences people miss.

First, leading zero bytes vanish unless handled separately. A zero byte at the front of a number adds nothing to its value, so a naive implementation drops it. Base58 encodes each one as a leading 1 instead — and getting that wrong corrupts exactly the values that matter, because a standard Bitcoin address begins with a 0x00 version byte. That is where the leading 1 in those addresses comes from.

Second, it is quadratic. Dividing an ever-shorter big integer by 58 once per output character is O(n²). We measured our own implementation:

The absolute numbers depend on the machine; the shape does not. Each fourfold increase in input multiplies Base58's time by about sixteen, while Base64 grows in a straight line. At 16 KB Base58 is roughly a thousand times slower. That is irrelevant for a 25-byte address and disqualifying for a file — which is why nobody uses Base58 for files.

Bitcoin addresses add a further layer, Base58Check: a four-byte checksum from a double SHA-256, so a mistyped address fails verification instead of decoding to plausible garbage. Our Base58 tool verifies that checksum and names the version byte.

Base85: the smallest, and two dialects

Base85 turns four bytes into one 32-bit integer and writes it as five base-85 digits — 25% overhead, the best of the common encodings. You meet it in two forms. Ascii85, from Adobe, uses the 85 printable characters from ! to u, collapses an all-zero group to a single z, and appears inside PDF and PostScript streams. Z85, from ZeroMQ, uses a different 85 characters chosen to avoid quotes, backslashes and commas, so its output can be pasted into source code, JSON or a shell command without escaping.

The gotcha is arithmetic. Five base-85 digits can express values up to 85⁵, about 4.44 billion, but four bytes only reach 4,294,967,295. So some five-character groups — anything above s8W-! — are not valid at all. A decoder that ignores this wraps the value and returns four wrong bytes with no complaint. Z85 adds a second trap: it is defined only for whole four-byte words and carries no length field, so padding a ragged input is something you have to own rather than something the format records.

A decision guide

• No special constraints? Base64. It is everywhere, it is fast, and every language has it built in.
• Going into a URL, filename, cookie or token? Base64url.
• Case might be changed, or a human will read it out? Base32 — Crockford's alphabet if people will type it back in.
• Short identifier that people copy and paste? Base58, with a checksum if a typo would be expensive.
• Every byte counts, or the data is already Ascii85 or Z85? Base85 — Z85 if it is going into source code.
• Debugging, and you want to see the bytes? Hex. Twice the size, but every byte is two characters you can read directly; our number base converter helps with individual values.

One thing they all share

None of these is encryption. Each is a reversible change of alphabet that anyone can undo, so a secret encoded in Base64 is exactly as exposed as the secret itself. That also means it is safe to decode a token or a key to inspect it — as long as the decoder runs in your browser rather than on someone else's server. Every encoder linked above does; here is how to check that for yourself.