Base32 encode and decode

How Base32 works: 5 bytes become 8 characters

A Base32 character carries 5 bits, since 2⁵ = 32, and a byte is 8. The smallest run of bits that is a whole number of both is 40: five bytes, or eight characters. So the encoder takes the bytes five at a time, writes out their 40 bits, cuts them into eight fives and looks each one up in the alphabet. Here is "Hello":

Each group is 40 bits wide: scroll sideways to see all of it.

H, e, l, l and o are the bytes 72, 101, 108, 108, 111. Their 40 bits cut into fives are 01001 00001 10010 10110 11000 11011 00011 01111, which are 9, 1, 18, 22, 24, 27, 3, 15, and in the RFC 4648 alphabet those are JBSWY3DP. Decoding runs the same steps upwards. Text goes through UTF-8 first, so an accented letter is two bytes before Base32 sees it.

The three Base32 alphabets

All three map the numbers 0 to 31 to characters; only the characters differ. Data encoded with one alphabet must be decoded with the same one.

• RFC 4648 Base32 is the one meant by plain "Base32": capitals A–Z for 0 to 25, then 2–7. It is the alphabet of 2FA secret keys and of .onion addresses.
• base32hex, from the same RFC, continues hexadecimal: 0–9, then A–V. Because the characters are in ASCII order, encoded strings sort the same way as the bytes they hold, as long as they are left unpadded (an = sorts after the digits). The bytes 0F, 80, FF are B4======, QA======, 74====== in RFC 4648 Base32, which sort as FF, 0F, 80: the alphabet puts 2–7 after Z, but ASCII puts digits before letters. In base32hex they are 1S======, G0======, VS======, which sort as 0F, 80, FF.
• Crockford Base32, designed by Douglas Crockford for people to read and type, is 0–9 and the letters without I, L, O and U. A decoder ignores case and hyphens and reads I and L as 1 and O as 0, so a code read over the phone still decodes. It has no padding, and may end in a check symbol for the number modulo 37: one of the 32 characters or one of five extras, * ~ $ = U, which this decoder checks. His scheme encodes a number, with any spare bits at the front; this page, like many libraries, applies the alphabet to bytes the RFC 4648 way, with the spare bits at the end. The two agree whenever the length is a multiple of 8 characters. ULIDs, the sortable IDs the UUID and ULID decoder takes apart, are one 128-bit number in 26 characters, so 2 zero bits come first; paste one in Crockford decode mode and the page reads it as that number, with the bytes cut from the left a click away.

Padding: when the bytes do not fill a group

When fewer than five bytes are left, the last group is short. Its bits are filled out with zeros to a whole five, and = signs take the place of the characters with no bits at all, so the output is always a multiple of eight. These are the test vectors from RFC 4648:

A decoder can tell how many bytes the last group holds from its number of characters alone, so the padding carries no information and is often left off, as in 2FA secrets. A group can never end after 1, 3 or 6 characters: no number of bytes produces that, which is how this decoder spots a missing or extra character.

How much bigger Base32 makes data

Every 5 bytes become 8 characters, so Base32 is 60% bigger than the data, against a third for Base64.

The rule: 8 × ⌈n ÷ 5⌉ characters for n bytes with padding, ⌈8n ÷ 5⌉ without. A 20-byte TOTP secret is exactly 32 characters, with no padding needed.

Base32 in two-factor authentication

An authenticator app and a website share a secret key, a run of random bytes. The QR code you scan when you set up 2FA holds an otpauth:// link with the key in Base32, and the "enter this key instead" text under it is the same Base32, often in blocks of four and in small letters. Base32 is used because the key may have to be typed by hand, and an alphabet with one case and no 0, 1 or 8 is hard to mistype. The example key JBSWY3DPEHPK3PXP is 10 bytes: "Hello!" followed by DE AD BE EF.

Common mistakes

• Decoding with the wrong alphabet. A string can be valid in more than one alphabet, and then it decodes without an error into the wrong bytes. "abc" is MFRGG=== in RFC 4648 Base32; read as base32hex, the same characters give the bytes B3 F7 08, not 61 62 63.
• Typing 0, 1 or 8 in RFC 4648 Base32. They are not in the alphabet (nor is 9). If a key seems to contain them, they are almost certainly the letters O, I and B.
• Comparing Base32 strings as case-sensitive. Most decoders, this one included, read small letters as capitals, so jbswy3dp and JBSWY3DP are the same bytes. Some refuse small letters, such as Python's base64.b32decode unless it is given casefold=True, so write capitals when in doubt.
• Treating it as encryption. Base32, like Base64, has no key; anyone can decode it.