Base32 Encode / Decode

Convert text to Base32 and Base32 back to text.

0 chars
0 words
0 lines
0 chars
0 words
0 lines

Base32 Encoder and Decoder

This Base32 converter turns text into Base32 and decodes Base32 strings back into readable text. It runs entirely in your browser, supports the three alphabets you're likely to meet in practice, and updates the result as you type.

What is Base32?

Base32 is a binary-to-text encoding defined in RFC 4648. It reads the input 5 bytes (40 bits) at a time and splits them into eight 5-bit groups, each mapped to one of 32 characters. The standard alphabet is A–Z plus the digits 2–7; the digits 0, 1, 8 and 9 are left out because they're easy to mix up with O, I, L and B. When the input isn't a multiple of 5 bytes, the output is padded with = to a multiple of 8 characters. For example, Hello encodes to JBSWY3DP, and Hi becomes JBUQ====.

Where you'll see Base32

  • 2FA and TOTP secrets – the setup key shown under an authenticator QR code (like JBSWY3DPEHPK3PXP) is a Base32 string. Google Authenticator, Authy and most TOTP libraries expect secrets in this format.
  • Case-insensitive identifiers – because the alphabet has only one letter case, Base32 values survive systems that change case, such as DNS names, email local parts, and file systems on Windows and macOS.
  • Human-typed codes – licence keys, onion addresses and short IDs use Base32 (often Crockford's variant) so they can be read aloud or copied from paper.

Base32 vs Base64

Base32 is less compact: 5 bytes become 8 characters, an overhead of about 60%, while Base64 adds only about 33%. In exchange you get an alphabet without mixed case or symbols like + and /, which makes Base32 safer in URLs, file names, and anywhere humans have to type the value.

Options

  • Alphabet – RFC 4648 is the default. Base32hex (0–9, A–V) keeps the sort order of the original bytes. Crockford removes I, L, O and U, never pads, and while decoding it treats O as zero and I/L as one.
  • Padding – keep the trailing = characters or drop them. Many TOTP secrets are shared without padding; the decoder accepts both.

The decoder ignores spaces, dashes and line breaks, so grouped keys like JBSW Y3DP EHPK 3PXP work too. If a character doesn't belong to the chosen alphabet, you'll see exactly which one and where. Need to put the result in a link? Run it through URL Encode / Decode.

Frequently Asked Questions

An authenticator secret such as JBSWY3DPEHPK3PXP is Base32-encoded random bytes, not text. Decoding it works, but the resulting bytes are usually not valid UTF-8, so they can't be shown as readable text. The secret is meant to be fed into an authenticator app or a TOTP library as-is.

No. The standard alphabets only use upper-case letters and digits, so the decoder converts lower-case input to upper case before decoding. That's one of the main reasons Base32 is used for codes people type by hand.

RFC 4648 uses A–Z and 2–7. Base32hex uses 0–9 and A–V, so encoded values sort in the same order as the original bytes. Crockford's variant drops I, L, O, and U to avoid confusion, treats O as 0 and I/L as 1 when decoding, and never uses padding.

Base32 stores 5 bits per character while Base64 stores 6. Every 5 bytes of input become 8 characters, so the output is about 60% larger than the input, compared with roughly 33% for Base64.