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
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.
