Base32 Encoder/Decoder

About Base32 Encoder/Decoder

Base32 writes bytes using 32 characters: the uppercase letters A–Z and the digits 2–7 (RFC 4648, section 6). Its output is longer than Base64's, but it is case-insensitive and skips the easily confused digits 0, 1, 8 and 9, which makes it the usual choice for values humans read and type. The best-known example is the “setup key” shown by two-factor authenticator apps.

This tool converts your text to UTF-8 bytes, encodes them with the standard RFC 4648 alphabet, and pads the result with = to a multiple of eight characters. When decoding it accepts lowercase and ignores whitespace and trailing padding.

Why five bytes become eight characters

32 = 2⁵, so each character carries 5 bits. The smallest bit count that is a multiple of both 8 and 5 is 40, so Base32 processes 5 bytes at a time and emits 8 characters. Output size is ceil(n/5) × 8 — 1.6 times the input, or +60%. Base64 on the same data costs +33%, so Base32 is noticeably longer.

When the final block has fewer than 5 bytes, the leftover bits are zero-filled into characters and the rest of the 8-character block is filled with =. With 1, 2, 3 or 4 leftover bytes you get 6, 4, 3 or 1 padding characters. That's why the RFC 4648 test vector “foobar” ends in six = signs: MZXW6YTBOI====== (6 bytes = one full block + 1 byte).

What Base32 is good for

Base64 is case-sensitive and mixes in +, / and =, which makes it painful to read over the phone or copy from paper. Standard Base32 uses only capitals and 2–7; with no 0, 1, 8 or 9, there's nothing to mistake for O, I or B. Case-insensitivity means a user typing in lowercase gets the same value.

Authenticator apps (Google Authenticator and friends) receive their secret through an otpauth:// URI, and the secret parameter is Base32. When you can't scan the QR code, the string you're asked to type — something like JBSWY3DPEHPK3PXP — is that Base32 secret. The app decodes it to bytes and uses them as the HMAC key for the TOTP algorithm (RFC 6238). Decoding a setup key here therefore usually gives unreadable characters: the underlying bytes are random, not text.

Tor v3 onion addresses are another place you'll see Base32: the 56-character name is a Base32 encoding of the service's public key plus a checksum and version byte, written in lowercase.

Base32 is not one format

RFC 4648 also defines “base32hex”, which uses 0–9 and A–V. Its advantage is that encoded strings sort in the same order as the original bytes, which is why DNSSEC NSEC3 records use it. There are also popular non-RFC variants such as Crockford's Base32 and z-base-32. Different alphabets decode the same string into completely different bytes. If this tool reports an invalid character — a 0, 1, 8 or 9 in the input is the typical sign — you are probably looking at base32hex or another variant, which this tool doesn't support.

Worked examples

How to use it

1. Paste text to encode, or a Base32 string to decode.
2. The result appears immediately; the swap button reverses the direction.
3. If you get an error, look for 0, 1, 8, 9 or symbols — they suggest a different Base32 variant.

Frequently asked questions