How to convert between any two encodings
- Paste your string into the input. With From on Auto-detect, the status line says what the tool thinks it is: “Detected: Base58 · Not right? Read as [Base64] …”.
- If the guess is wrong, click one of the Read as buttons, or set From yourself.
- Choose the target in To. The formats are grouped: text, Base64, bytes and numbers, Base32, big-number bases, Base85/Base91/Base45, and email, URL and legacy encodings.
- Each format’s options appear under its pane, for example Alphabet for Base58 and Base62 or Padding (=) for Base32 and Base64.
- ⇄ Swap moves the output into the input and reverses the two formats. Copy output and Download take the result, and Save bytes downloads the decoded bytes as a file.
Every conversion goes through raw bytes: the input is decoded, and the bytes are encoded again. The Bytes counter under the tool shows how many there are, which is often the quickest check that a key or hash is complete. The single-purpose pages listed above open this same converter with the formats preset.
The encodings compared
| Encoding | Alphabet | Output size | Overhead | Typical use |
|---|---|---|---|---|
| Hex / Base16 | 16 | 2 characters per byte | 100% | Hashes, debugging, byte dumps |
| Base32 | 32 | 8 per 5 bytes | 60% | TOTP secrets, onion addresses, case-insensitive IDs |
| Base36 | 36 | ≈ 1.55 per byte | ≈ 55% | Short case-insensitive IDs and numbers |
| Base45 | 45 | 3 per 2 bytes | 50% | QR codes (EU health certificates) |
| Base58 | 58 | ≈ 1.37 per byte | ≈ 37% | Bitcoin, Solana, IPFS |
| Base62 | 62 | ≈ 1.34 per byte | ≈ 34% | Short URLs and IDs |
| Base64 | 64 | 4 per 3 bytes | 33% | Email, JSON, data URIs, JWTs, almost everything |
| Ascii85 / Z85 | 85 | 5 per 4 bytes | 25% | PDF, PostScript, Git, ZeroMQ keys |
| basE91 | 91 | ≈ 1.23 per byte | 14–23% | Squeezing data into printable ASCII |
| Uuencode / xxencode | 64 | 4 per 3 bytes plus line framing | ≈ 38% | Old email and Usenet attachments |
The overhead is for random data; for the big-number bases it varies by a character or two with the value. Base45 looks wasteful here, but in a QR code’s alphanumeric mode its 45 characters cost 5.5 bits each, which brings it close to 3%.
For a single input, here is the 5-byte string Hello in each:
| Hex | Base32 | Base36 | Base45 | Base58 | Base62 | Base64 | Ascii85 | basE91 |
|---|---|---|---|---|---|---|---|---|
48656c6c6f | JBSWY3DP | 3yud78mn | %69 VDL2 | 9Ajdvzr | 5TP3P3v | SGVsbG8= | 87cURDZ | >OwJh>A |
Three ways to build a base
The encodings fall into three groups, and the group explains most of their behavior.
Bit groups: hex, Base32, Base64, uuencode and xxencode. The alphabet size is a power of two, so each character carries a fixed number of bits (4, 5 or 6). Encoding is fast, works as a stream, and the output length depends only on the input length.
Fixed blocks: Base45 (2 bytes into 3 characters) and the Base85 family (4 bytes into 5). The alphabet is not a power of two, so a small block is converted as a number. Still fast and streamable, with the length again fixed by the input size.
Big numbers: Base36, Base58 and Base62. The entire input is one number, written in the new base. Any alphabet size works and the output has no padding, but every byte affects every character, leading zero bytes need special handling, and the cost grows with the square of the size. This converter keeps leading zeros as leading zero digits and caps these bases at 64 KB of input.
basE91 sits between the groups: it reads 13 or 14 bits at a time, so its length depends slightly on the content.
Which encoding to choose
- Programs talk to programs: Base64, or Base64URL inside URLs and tokens. Every language has it built in, and nothing else is as widely understood.
- People read, type or dictate the value: Base32, preferably Crockford’s variant, or Base36. Both ignore case; Crockford also avoids look-alike letters.
- Short opaque IDs in URLs: Base62 for the shortest letters-and-digits string, Base58 if people may copy it by hand, since it drops
0,O,Iandl. - A QR code: Base45 with the QR alphanumeric mode.
- Every byte counts and the channel is plain ASCII: Ascii85 or Z85 for fixed blocks, basE91 for a few percent more.
- Inspecting bytes: hex. Twice the size, but every byte is two characters you can read.
- A legacy system asks for it: uuencode or xxencode, and nothing new.
The comparison of hex, Base32, Base58 and Base85 goes deeper into the trade-offs against Base64.
FAQ
What is the most compact text encoding for binary data?
Among the common ones, basE91 (about 23% overhead on random data), then the Base85 family (25%), then Base64 (33%). The more compact encodings use punctuation that needs escaping in JSON, HTML or shells, which often makes Base64 the better trade.
Which encoding is best for URLs?
Base64URL for machine-generated tokens, since it is short and standardized. Base62 or Base58 when the value should contain only letters and digits, and Base32 or Base36 when it must survive case changes. Base45 and Base85 contain characters that need percent-encoding.
Why do Base58, Base62 and Base36 outputs vary in length?
They treat the input as one big number, so the length depends on its value as well as on the byte count. Base64, Base32 and hex map fixed bit groups and always give the same length for the same number of bytes.
How does auto-detect decide what my string is?
It tests the input against each format’s rules, from the most distinctive (delimiters like <~ or begin 644) to the most generic, and decodes with the first match. A short string can be valid in several formats; the Read as buttons let you pick another reading.
Do these encodings protect the data?
No. Anyone can reverse every one of them without a key. They only make bytes printable. See encoding vs encryption.