Base32 Encoder and Decoder

Features

• Two-way conversion: text ⇄ Base32
• Two alphabets: standard Base32 (A–Z, 2–7) and base32hex (0–9, A–V)
• Pad with =, or emit the compact unpadded form (decoding accepts either)
• Non-ASCII text encoded as UTF-8 bytes, matching standard implementations
• Decoding tolerates lowercase, spaces, line breaks and missing padding
• A character outside the alphabet is reported by name instead of being dropped

How to use

1. Choose the direction: encode or decode
2. Choose the alphabet: standard Base32 or base32hex
3. Paste your content into the input box; the result appears as you type
4. Click Copy to take the result

FAQ

How is Base32 different from Base64?

They encode the same bytes; the difference is how many characters represent 5 bits instead of 6, and which alphabet is used. Base64 uses 64 characters and turns every 3 bytes into 4 characters. Base32 uses 32 characters and turns every 5 bytes into 8 characters. Base32 output is 60% longer, and buys a smaller alphabet with no look-alike characters that is also case-insensitive. Choose Base64 for URLs and databases; choose Base32 when a human has to copy or read the string aloud, or when it goes on a device label.

Why is the Base32 output so much longer than the input?

Each Base32 character carries only 5 bits, while a byte is 8 bits. 8 ÷ 5 = 1.6, so the output is necessarily 1.6 times the input (plus padding). Base64 is 8 ÷ 6 ≈ 1.33 times. This is not an implementation quirk — a smaller alphabet always means a longer string.

Should I use base32hex or standard Base32?

Standard Base32 for almost everything — it is the default, and it is what other implementations expect unless told otherwise. base32hex earns its place when sorting matters: its alphabet runs 0–9 then A–V, so comparing two encoded strings lexicographically gives exactly the same ordering as comparing the original bytes. You need that when the encoded value is a database primary key, or for ordered binary search in DNS (NSEC3). The two are not compatible: the same data produces entirely different strings.

Decoding complains that a character is not in the alphabet

Usually the wrong alphabet. Standard Base32 has no 0, 1, 8 or 9, so a string containing 0 can only fail under the standard table — switch to base32hex and it decodes. Conversely, a string with W, X, Y or Z can only be standard Base32, since the hex table stops at V. The other possibility is truncation, where a trailing partial group picked up a stray character.

Decoding says the bytes are not valid UTF-8 text

That means the Base32 carries binary rather than text — images, keys and archives all look like this. Base32 itself only transports bytes and has no idea what is inside. The output here is a text box, so it cannot display binary; reporting an error is better than substituting replacement characters and letting you believe it decoded successfully.