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. Use Base58 for blockchain addresses and content 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, IPFS CIDs), 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
Try the live Encoding Converter. Convert text between binary, hex, decimal, and Base64.
Edit in the full tool

How this is calculated

Base64 is the workhorse: 33% overhead, no ambiguous characters, supported everywhere. Base32 adds more overhead (60%) but is case-insensitive and avoids visually confusable characters (0/O, 1/I/l), making it ideal for human-typed values like 2FA recovery codes. Base58 omits characters that look similar in many fonts (0, O, I, l) and is used by Bitcoin and IPFS because addresses need to be copyable without ambiguity. 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. Base32 adds 60% overhead but stays case-insensitive and drops the 0/O and 1/I/l lookalikes, which matters for 2FA recovery codes typed by hand. Base58 strips confusable characters for Bitcoin and IPFS. Base85 squeezes to 25% overhead but includes quotes and backslashes that break in most 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) replaces characters that aren't safe in a URL with a percent sign followed by two hex digits.
View details ➜

Related guides

Base64 encoding explained
The foundation binary-to-text encoding format.
View guide ➜
Base32 vs Base64
Why Base32 is the human-readable alternative.
View guide ➜

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 IPFS content IDs, and Base85 for PostScript and PDF internals. 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 IPFS hashes get copied by humans, and a single misread character sends funds to the wrong wallet. The omission costs a little encoding efficiency versus Base64, but the error-proofing is worth it for values people retype or verify by eye.
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 it's case-insensitive and skips lookalike characters. Reserve Base58 for blockchain style identifiers and avoid Base85 unless PostScript or PDF internals force it on you.

Related tools

JSON Formatter

Validate, format, and minify JSON data with syntax highlighting.

Use tool ➜

Unix Timestamp

Convert between Unix timestamps and human-readable dates.

Use tool ➜

Cron Generator

Visually build standard 5-part cron expressions or translate them into readable schedules.

Use tool ➜