Base64 vs Base32 vs Base58: Encoding Comparison and When to Use Each

Three encodings, three different optimization targets. Base64 maximizes density, Base32 maximizes typability, Base58 maximizes copy-paste safety. Picking the wrong one creates real bugs — Base64 in a URL gets mangled, Base58 in a JWT breaks parsers, Base32 in a database wastes 30% of bytes for no reason.

1. Quick comparison

2. Base64 — the default

Standard alphabet: A-Z, a-z, 0-9, +, / with = padding.

The math: 3 bytes (24 bits) → 4 Base64 characters (4 × 6 = 24 bits). 33% size overhead.

Use Base64 when:

• Embedding binary in JSON, XML, or email (MIME attachments, RFC 2045)
• Storing small binary blobs in databases that prefer text
• Encoding data URLs (data:image/png;base64,...)
• Wherever bandwidth matters and the transport is text-only

Avoid Base64 when:

• Putting data in URLs — use Base64URL instead
• Humans will read or type the value — use Base58 or Base32
• Filenames or file paths — / breaks them

3. Base64URL — the URL-safe variant

Same as Base64 but: + → -, / → _, padding = usually omitted. RFC 4648 §5.

This is what JWTs use:

// JWT structure: three Base64URL-encoded parts joined by "."
header.payload.signature

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Spotting Base64 vs Base64URL: if you see + or / or =, it's standard Base64. If you see - or _ and no padding, it's Base64URL.

4. Base32 — typeable by humans

Standard alphabet (RFC 4648 §6): A-Z, 2-7. Note the absence of 0, 1, 8, 9 and lowercase letters — designed for case-insensitive use and visual disambiguation.

The math: 5 bytes (40 bits) → 8 Base32 characters (8 × 5 = 40 bits). 60% overhead.

Use Base32 when:

• Human-typed secrets (TOTP / Google Authenticator setup keys)
• Onion addresses (Tor v3: 56-character Base32)
• Filenames where case-insensitive filesystems exist (Windows, macOS HFS+)
• DNS labels (DNS is case-insensitive; Base32 fits)

The 60% overhead is the cost of avoiding lowercase, digits 0/1, and punctuation. For data only machines see, Base64 is more efficient.

5. Base58 — Bitcoin's design

Alphabet: full 64-char Base64 minus 0, O, I, l, +, /. The choices are deliberate:

• 0 and O — zero vs capital O ambiguity
• I and l — capital I vs lowercase L ambiguity
• + and / — URL/path/shell unsafe

The math: 58 isn't a power of 2, so Base58 doesn't have a fixed bytes-per-char ratio. Encoding requires arbitrary-precision arithmetic (treating bytes as a single big integer and dividing by 58 repeatedly). On average, 137 chars per 100 bytes (~37% overhead).

Use Base58 when:

• Identifiers humans copy-paste (cryptocurrency addresses, IPFS CIDs)
• Short URLs or invitation codes (https://example.com/i/4Cax2pq)
• Database IDs that may appear in URLs (Mastodon uses Base58 for status IDs)

Bitcoin actually uses Base58Check: Base58 + 4-byte SHA-256 checksum. Catches typos before sending coins to a wrong address. Modern Bitcoin (SegWit) moved to Bech32 for stronger error detection — see RFC equivalent BIP 173.

6. Real-world encoding choices

7. Decision rule

1. Will humans copy-paste this? Base58 (or Bech32 for new systems).
2. Will humans type this? Base32.
3. Goes in a URL or HTTP header? Base64URL.
4. Goes in JSON, email, or arbitrary text? Base64.
5. Debugging only, humans read but never type? Hex.

FAQ

References

• RFC 4648 — Base16, Base32, Base64 encodings
• Base58Check encoding (Bitcoin Wiki)
• BIP 173 — Bech32
• RFC 6238 — TOTP