Base32 Encode/Decode

Base32 and why it exists next to Base64

Base32 encodes binary data using 32 characters: the uppercase letters A through Z and the digits 2 through 7. It trades density for legibility. Where Base64 packs 3 bytes into 4 characters, Base32 packs 5 bytes into 8 characters, so output is larger, but it survives case-insensitive handling and avoids digits that look like letters.

The TOTP connection

Base32 is the standard encoding for TOTP secrets, the shared keys behind authenticator apps. When you set up two-factor auth and see a string like JBSWY3DPEHPK3PXP, that is the raw secret in Base32. It was chosen because people sometimes type these by hand, and Base32 omits the easily-confused 0, 1, and 8 and is not case-sensitive.

Example

"foob" (4 bytes)
-> MZXW6YQ=  (8 chars with = padding)

"Hi" (2 bytes)
-> JBQQ====  (padding fills the group)

The trailing = characters pad the final 8-character block when the input is not a multiple of 5 bytes. Many TOTP implementations strip the padding, so a decoder should tolerate its absence.

Common mistakes

Confusing RFC 4648 Base32 with the Base32hex or Crockford variants produces garbage, since they use different alphabets. Feeding lowercase input to a strict decoder can fail unless it normalizes case first.

FAQ

Why not just use Base64 for TOTP secrets? Base64 is case-sensitive and includes symbols that are awkward to read aloud or type. Base32 was the pragmatic choice for human-handled keys.

My authenticator rejects the secret, why? Often a stray space, a lowercase letter a strict app will not accept, or a character outside the A-Z/2-7 set that was pasted in by accident.