Base32, Base58 and Base85, Explained

After reading this you will know how three common binary-to-text encodings pack bytes into printable characters, why each one exists, and how to reproduce the encoded output by hand.

Base32, Base58 and Base85 all do the same job as Base64: they turn arbitrary bytes into a string you can safely paste into a URL, a config file, or a QR code. They differ in the alphabet size and therefore in how much the data grows. Base64 turns 3 bytes into 4 characters. Base32 turns 5 bytes into 8. Base85 turns 4 bytes into 5. Base58 is not aligned to a byte boundary at all, and treats the whole input as one big number.

Here is the hook. The bytes 48 65 6C 6C 6F (the ASCII for Hello) become JBSWY3DP in Base32, 9Ajdvzr in Base58, and 87cURD_* in Ascii85. Same five bytes, three completely different strings. Every difference comes from the alphabet and the grouping rule.

What each encoding is for

These are not encryption. They hide nothing. Anyone can decode them without a key. They exist to move binary data through channels that only accept text.

Base32

32 symbols, defined in RFC 4648. The standard alphabet is A-Z and 2-7. Case-insensitive, no lowercase ambiguity. Used by TOTP secret keys (the seed behind six-digit auth codes), Tor v3 onion addresses, and DNS records where hostnames are case-folded.

Base58

58 symbols. Base64 minus the four lookalike characters 0, O, I and l, and minus + and /. Used by Bitcoin addresses and IPFS content IDs. The point is that a human can copy it by hand without confusing zero and capital O.

Base85 (Ascii85)

85 symbols, from ! (0x21) to u (0x75). Used inside PDF streams and Git binary diffs. It is denser than Base64: about 25% overhead instead of 33%.

When to use which, and when not to

Pick the encoding by the constraint, not by taste.

Use Base32 when the string must survive case-folding or be typed by a human on a phone keypad. TOTP keys and onion addresses both qualify. The cost is size: 8 characters for every 5 bytes, a 60% expansion.

Use Base58 when a human copies the value by eye and a single wrong character is a disaster, as with a Bitcoin address. The cost is speed and irregular length, because Base58 does big-integer division rather than bit slicing.

Use Base85 when size matters and the transport is text-safe but not URL-safe. PDF chose it to keep files small. Do not use raw Ascii85 in a URL: it contains characters like <, > and & that need escaping.

For general web work where you want the smallest common denominator, Base64url is usually the right default and none of these three. Reach for these three only when the specific format demands it.

The math behind the grouping

Base32 and Base85 both slice a fixed number of input bytes into a fixed number of output symbols. The rule follows from matching bit counts.

Here n_{\text{in}} is the number of input bytes in one group, b is the base, and n_{\text{out}} is the number of output symbols. Each symbol carries \log_2 b bits. For Base32, \log_2 32 = 5, so 5 bytes (40 bits) give exactly 8 symbols with no remainder. For Base85, \log_2 85 \approx 6.409, and 4 bytes (32 bits) map to 5 symbols because 5 \times 6.409 \approx 32.05 bits, just enough to cover 32.

Base58 does not slice bits. It reads the entire input as one unsigned integer and repeatedly divides by 58, collecting remainders. Leading zero bytes are handled separately: each 0x00 at the front becomes one leading 1 character (the first symbol in the Base58 alphabet).

The input of k bytes becomes the number N. You then write N in base 58. Because there is no fixed grouping, the output length varies slightly with the leading byte values, which is why Base58 addresses are not all the same length.

A worked example with "Hello"

Comparing the size overhead

The most practical difference is how much larger the encoded output gets. The overhead is fixed per encoding and follows directly from the grouping formula above.

Common mistakes

Confusing the Base32 alphabet with base32hex. RFC 4648 defines two Base32 variants. The standard one uses A-Z2-7. The "extended hex" variant uses 0-9A-V and sorts differently. Decoding one with the other alphabet gives garbage. TOTP uses the standard alphabet.

Assuming Base58 has padding. It does not. Base58 output length depends on the numeric value, so two inputs of the same byte length can encode to different string lengths. Do not pad Base58 to a fixed width.

Mixing Ascii85 and Z85. Ascii85 (used by PDF) and Z85 (used by ZeroMQ) share the density but use different alphabets and different handling of the all-zero group. The PDF variant maps four zero bytes to the single character z. Feeding a z to a strict decoder that does not expect it will fail.

Treating an encoding as a checksum. Base58Check, the format Bitcoin actually uses for addresses, appends a 4-byte SHA-256 double-hash checksum before encoding. Plain Base58 has no error detection. A single mistyped character decodes to different bytes with no warning.

Related tools

If you have a string and you are not sure what encoding or cipher produced it, the Cipher & Hash Identifier runs frequency analysis and pattern checks to narrow it down. If you find that a value was obscured with a repeating key rather than encoded, the XOR Cipher & Brute-forcer can recover single-byte XOR keys and let you test candidate keys.

Related tools

XOR Cipher & Brute-forcer

XOR text with a key, and brute-force single-byte XOR.

Cipher & Hash Identifier

Guess the cipher or hash from a sample, with frequency analysis.

AES Encryption

Encrypt and decrypt text with AES-GCM or AES-CBC.

Cryptographic Key Generator

Random keys, IVs, salts and API tokens from a CSPRNG.

Enigma Machine Simulator

Operate a full Enigma I — rotors, plugboard, lamp board — and watch each letter travel the wiring.

JWT Builder & Signer

Build and sign JSON Web Tokens (HS256/384/512).