Base64 is the encoding almost everyone knows, but it's not the only one, and using it where it doesn't belong causes real problems: broken URLs, ambiguous cryptocurrency addresses, identifiers that need to be dictated over the phone and end up causing confusion. Each encoding exists because it solves a specific limitation the others don't cover.
They all solve the same base problem
All these encodings turn binary data into printable text, because many systems (email, URLs, JSON) only reliably guarantee transporting text, not arbitrary binary bytes. The difference lies in which characters each one uses and why that choice matters depending on the context.
Base64: the general-purpose option
Uses 64 characters (A-Z, a-z, 0-9, +, /) and is the most compact, standard encoding for embedding binary data in text: email attachments, images embedded in HTML/CSS, authentication tokens (like a JWT's payload). Its problem: the + and / characters have special meaning in URLs, so raw Base64 can break a URL if not encoded properly.
Base32: when it has to be dictated or typed by hand
Uses only 32 characters (A-Z and 2-7, deliberately avoiding letters and numbers that get visually confused like 0/O or 1/I/l). It's longer than Base64 for the same data, but much safer to transcribe by hand or dictate over the phone without errors. It's used in two-factor authentication recovery codes, precisely because the user sometimes has to type them manually.
Base58: the one Bitcoin chose (and why)
It's Base64 without the ambiguous characters: it drops 0, O, I, l, and also + and / to avoid problems with URLs and line breaks when copy-pasting. Bitcoin and many other cryptocurrencies use it for wallet addresses, precisely because a single misread character in an address can mean irreversibly sending funds to the wrong one.
Base85: maximum density at the cost of readability
Uses a much wider alphabet (85 characters), making it more compact than Base64 for the same data (fewer characters to represent the same number of bytes). The cost is that it uses less friendly symbols to read or type by hand. It's used in formats like PDF (Adobe uses a variant, ASCII85) where file size matters more than the encoded text's human readability.
Hex and URL encoding: special cases
Hex represents each byte as two digits (0-9, A-F); it's less compact than Base64 but extremely common for representing hashes, CSS colors and binary values when debugging, because each byte reads directly and predictably. URL encoding isn't a general binary-to-text encoding, but specifically escapes characters with special meaning inside a URL (spaces, &, ?).
How to use the multi-base encoder
- Type or paste the text you want to encode or decode.
- Choose the format: Base64, Base32, Base58, Base85, Hex, URL or HTML.
- Get the result instantly, in either direction (encode or decode).
You can do it free with the multi-base encoder on this site, processing everything in your browser.
How to choose quickly
- You're embedding it in HTML, JSON or an email: Base64.
- Someone has to type it or read it aloud: Base32.
- It's a cryptocurrency address or an identifier that can't be misread: Base58.
- You need maximum compactness and readability doesn't matter: Base85.
- You need to represent bytes directly and debuggably: Hex.
- You're putting the value inside a URL: URL encoding.
Frequently asked questions
Which one is more secure? None of them is "encryption": all are reversible with no key, they only change the data's representation, not protect it.
Why does Base64 sometimes break a URL? Because it includes + and /, characters with special meaning in URLs; that's why a URL-safe variant of Base64 exists that replaces them.
Does Bitcoin use Base64? No, it uses Base58 specifically to avoid ambiguous characters that could cause funds to be lost due to a transcription error.
Is my text processed on any server? No, encoding and decoding happen entirely in your browser.
Encode and decode in Base64, Base32, Base58, Base85, Hex, URL or HTML for free with the multi-base encoder, 100% in your browser.