Base32 Encoder and Decoder

What Base32 is for

Base32 turns arbitrary bytes into a 32-character, case-insensitive alphabet so the result survives copy-paste, voice dictation, QR codes, and case-folding transports that mangle Base64. It trades density for robustness: every five bytes become eight characters, a 60% size overhead versus 33% for Base64. That overhead is a fair price wherever a human might read, type, or dictate the value.

The most common place engineers meet Base32 is the shared secret in a TOTP or HOTP authenticator (RFC 6238 / RFC 4226). The otpauth:// URI behind a 2FA QR code stores its secret parameter in Base32 precisely because it is case-insensitive and avoids the +, /, and = characters that complicate URLs. You will also see Base32 in DNS-based systems, NSEC3 hashes, Bitcoin/onion-style addresses, and anywhere a token needs to be read aloud.

Standard Base32 vs base32hex

RFC 4648 defines two alphabets. Standard Base32 (§6) uses A–Z followed by 2–7. The extended-hex variant, base32hex (§7), uses 0–9 followed by A–V; its advantage is that encoded strings sort in the same order as the bytes they represent, which matters for keys in ordered databases such as DNSSEC NSEC3. The two are not interchangeable — decode with the same alphabet you encoded with, or you will get different bytes back.

Common mistakes

• Confusing Base32 with Base64. A string of only A–Z2–7 with no lowercase is almost always Base32; mixed case with + or / is Base64. Use the Base64 tool for the latter.
• Including 0, 1, or 8 in standard Base32. They are not in the alphabet — they are often transcription errors for O, I/L, and B.
• Decoding a TOTP secret as text. The decoded bytes are a raw key, not a string. Switch the result to a hex view (this tool falls back to hex automatically when the bytes are not printable UTF-8).
• Mismatched alphabet. Decoding base32hex data with the standard alphabet silently produces wrong bytes — pick the matching variant.

Related tools