Base32 vs Base58 vs Base85: How to Choose a Binary-to-Text Encoding

Binary-to-text encoding is what you reach for when raw bytes need to pass through a text-only channel: a TOTP secret, a wallet address, a config value, a QR payload, a PDF stream, or a small binary fixture pasted into source code. Base32, Base58, and Base85 all solve that job, but they optimize for different pain points.

If you want to test the same bytes while reading, use Toolora's Base32 / Base58 Encoder & Decoder for RFC 4648 Base32, Crockford Base32, Base32hex, Bitcoin Base58, and Ripple Base58. For Ascii85 and Z85, use the Base85 / Ascii85 Encoder & Decoder. I also cross-check Base64 when I care about interoperability, so the Base64 Encoder/Decoder is a useful reference point.

The Short Answer

Use Base32 when humans may read, type, dictate, or re-enter the value. It uses a small alphabet, can be made case-insensitive, and avoids punctuation. That is why TOTP secrets are normally shown in Base32 instead of Base64.

Use Base58 when you need a compact alphanumeric value and want to avoid characters people confuse: 0, O, I, and l. That is the reason Bitcoin-style addresses use Base58. It is not as simple as Base32 internally because 58 is not a power of two; implementations usually do repeated division over a big integer or byte array.

Use Base85 when size matters and the channel tolerates punctuation. It packs bytes more tightly than Base32 and Base58, but its alphabets contain characters that can be awkward in URLs, shells, markdown, JSON strings, or email. It fits better inside controlled formats such as PDF/PostScript streams, git binary patches, and explicit source-code fixtures.

Alphabets: What Actually Appears in the Output

The alphabet is the real product decision. A smaller, cleaner alphabet usually costs more characters. A denser alphabet usually includes punctuation or mixed-case characters that are easier to break in surrounding syntax.

| Encoding | Typical alphabet | Good fit | |---|---|---| | Base32 RFC 4648 | ABCDEFGHIJKLMNOPQRSTUVWXYZ234567 plus optional = padding | TOTP, DNS-ish labels, uppercase-only channels | | Base32 Crockford | 0123456789ABCDEFGHJKMNPQRSTVWXYZ | human-entered IDs, coupon codes, support codes | | Base58 Bitcoin | 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz | blockchain addresses, compact alphanumeric tokens | | Ascii85 | printable ASCII from ! through u, with optional z compression for four zero bytes | PDF, PostScript, git-style binary text | | Z85 | 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ.-:+=^!/*?&<>()[]{}@%$# | source embeds where Z85 is expected |

Here is one real input encoded five ways. The input string is exactly:

Hello, Toolora!

UTF-8 bytes:

48656c6c6f2c20546f6f6c6f726121

Actual outputs from the local encoder benchmark:

| Encoding | Output | Characters | |---|---:|---:| | Base32 RFC 4648 | JBSWY3DPFQQFI33PNRXXEYJB | 24 | | Base32 Crockford | 91JPRV3F5GG58VVFDHQQ4R91 | 24 | | Base58 Bitcoin | 32UWxgjUxco2GgxRjxdGt | 21 | | Ascii85 | 87cURD_*#1Df9H1Ea^* | 19 | | Z85 | nm=QNz.92gz/oDgA:Z9 | 19 |

That example shows the trade-off clearly. Base85 is shortest, but it emits _, *, #, =, ., /, and :. Base58 is still short, and every character is alphanumeric. Base32 is longer, but it is the easiest to read out loud.

Size Overhead Benchmark

I tested deterministic byte arrays rather than prose strings so the table is not accidentally biased by English text. The benchmark ran locally on 2026-06-05 with Node and this byte pattern: byte[i] = (i * 31 + 17) & 255. The source for the numeric claim below is that local benchmark, using the same encoding rules as the Toolora tools linked above.

The cleanest numeric takeaway: on the 1024-byte benchmark payload, Base85 produced 1280 characters, exactly +25.0% overhead, while Base32 produced 1640 characters, +60.2%. Base58 landed at 1398 characters, +36.5%, close to Base64's 1368 characters, +33.6%.

Short inputs show padding effects. A 16-byte payload becomes 32 Base32 characters because padded RFC 4648 Base32 emits groups of 8 characters. If you remove padding or use Crockford Base32, the visible output can be shorter, but the core density is still 5 bits per character.

How I Pick in Real Work

When I need a user to read the value over a call, I pick Crockford Base32. The lost density is worth it because the alphabet drops I, L, O, and U, and a decoder can accept lowercase input and hyphens. A support code like 9H4K-2Q7T-M8VC is less compact than Base58, but it is easier to say twice without mistakes.

For wallet-like identifiers and public keys, I pick Base58 only when the ecosystem already expects it. Bitcoin and Solana users recognize that shape. The important caveat is that Base58 alone is only an encoding, not validation. Bitcoin's Base58Check adds version bytes and a checksum; raw Base58 does not prove the payload belongs to any chain.

For binary blobs inside controlled text formats, Base85 wins on density. A 32-byte key becomes 40 Z85 characters in the benchmark. That is a nice fit for a source fixture or a compact config value if every reader agrees on Z85. I avoid it for URLs unless I am willing to percent-encode or wrap the value carefully, because punctuation changes the failure mode.

If the bytes are meant for web APIs, data URIs, HTTP headers, or broad tooling, Base64 often beats all three in practice. It is not part of this article's title, but it is the compatibility baseline. Use Base32, Base58, or Base85 only when their alphabet trade-off is the reason you are choosing them.

Common Mistakes

Do not treat variants as interchangeable. RFC 4648 Base32, Crockford Base32, and Base32hex use different alphabets. Bitcoin Base58 and Ripple Base58 also differ. Ascii85 and Z85 are both Base85-style encodings, but their alphabets are not the same.

Do not call encoding encryption. Anyone can decode Base32, Base58, or Base85 without a key. If the payload is secret, encrypt or sign it first, then encode the resulting bytes for transport.

Do not ignore surrounding syntax. A Base85 string may be shorter in isolation and still worse in a URL if several characters require escaping. Paste a sample into the actual destination and compare the final size, not only the raw encoded string. For byte-level debugging before you encode, Toolora's Text to Hex Converter is a quick way to inspect the exact UTF-8 bytes.

My rule is simple: Base32 for humans, Base58 for compact alphanumeric identifiers, Base85 for dense controlled text, Base64 when compatibility matters more than the alphabet.

Made by Toolora · Updated 2026-06-05