TechCompare LogoTechCompare

Binary-to-text encoding compared: Base64, Base32, Base58, and more

Default to Base64 for binary-in-text. Use Base32 when humans will type or read the encoded value and the reduced digit set helps. Use Base58 for Bitcoin addresses and legacy CIDv0 identifiers, or Base32 for modern CIDv1 identifiers. Avoid Base85 unless you're working with PDF or PostScript internals.

Binary-to-text encodings convert arbitrary bytes into printable characters so they can travel through text-only channels: JSON, XML, email, URLs, and printed QR codes. The main families are Base64 (MIME, data URIs), Base32 (OTP secrets, product keys), Base58 (Bitcoin addresses and legacy IPFS CIDv0 strings), and Base85 (PostScript, PDF). Each trades overhead for specific usability properties.

By TechCompare · Updated

Encoding focus
Binary-to-text encodings
binary-to-text
Category
Format Comparison
Comparing encoding schemes side by side

How this is calculated

Base64 is the workhorse: 33% overhead and broad support, but its mixed-case alphabet includes visually confusable characters. Base32 adds more overhead (60%) and uses the RFC 4648 alphabet A-Z plus 2-7, so it excludes the digits 0, 1, 8, and 9 but still contains letters such as I, L, and O. Base58 omits characters that look similar in many fonts (0, O, I, l) and is used by Bitcoin and legacy IPFS CIDv0 strings because identifiers need to be copyable. Modern IPFS CIDv1 strings commonly use Base32. Base85 (Ascii85) has only 25% overhead but uses characters that break in many contexts (quotes, backslashes). For most modern use cases, Base64 is the right default.

Verdict

Each encoding optimizes for a different constraint. Base64 carries 33% overhead and works almost everywhere. RFC 4648 Base32 adds 60% overhead and excludes the digits 0, 1, 8, and 9, but it still includes potentially confusable letters such as I, L, and O. Base58 strips a wider set of confusable characters for Bitcoin and legacy IPFS CIDv0 identifiers. Base85 squeezes to 25% overhead but includes quotes and backslashes that break in many parsers.

More Encoding scenarios

Base64 vs Hex
Base64 and hexadecimal both encode binary data as text, but they serve different purposes.
View details ➜
UTF-8 vs ASCII
ASCII maps 128 English characters to 7-bit values.
View details ➜
URL encoding guide
Percent-encoding (also called URL encoding) represents a byte with a percent sign followed by two hex digits when that byte can't appear literally in the URL component being built.
View details ➜

Frequently asked questions

What are the main binary-to-text encodings?
Four families cover nearly everything: Base64 for MIME, JSON, and data URIs, Base32 for OTP secrets and product keys, Base58 for Bitcoin addresses and legacy IPFS CIDv0 strings, and Base85 for PostScript and PDF internals. Modern IPFS CIDv1 strings commonly use Base32. Each trades byte overhead for a different usability property, so the right pick depends on who or what touches the encoded value.
Why does Base58 avoid certain characters?
Base58 drops 0, O, I, and l because those pairs look identical in many fonts. Bitcoin addresses and legacy IPFS CIDv0 strings get copied by humans, and a mistyped character will usually fail the identifier's checksum or validation. A different valid destination would require a checksum-valid address, so don't treat visual similarity as a substitute for checking the full address.
Which binary-to-text encoding should I use?
Default to Base64 whenever machines exchange the data - it's compact at 33% overhead and supported everywhere. Switch to Base32 when a human will type or read the value, like 2FA recovery codes, because its alphabet excludes the digits 0, 1, 8, and 9 and is commonly handled case-insensitively. It still contains letters such as I, L, and O. Reserve Base58 for blockchain style identifiers and avoid Base85 unless PostScript or PDF internals force it on you.