🔠 Base32 Encoder and Decoder Online

What is the Base32 Encoder Decoder?

Base32 is a way of representing binary data using a set of 32 printable ASCII characters: the uppercase letters A to Z and the digits 2 to 7. The digits 0, 1, and 8 are deliberately left out because they are easy to confuse with the letters O, I, and B. That choice makes Base32 friendly for humans to read aloud, type, or write down, which is why it shows up in things like two-factor authentication secret keys and case-insensitive file identifiers. Base32 is one of three binary-to-text encodings defined in the same internet standard, alongside Base16 (hexadecimal) and Base64.

The encoding works at the bit level. Each Base32 character carries 5 bits of information, because 2 to the power of 5 is 32. The encoder reads the input as a stream of 8-bit bytes, lines all those bits up end to end, then slices the stream into 5-bit groups. Each group is a number from 0 to 31, which maps to one character in the alphabet. Since 8 bits and 5 bits share a least common multiple of 40 bits, the algorithm settles into neat blocks of 5 input bytes producing 8 output characters. When the input does not fill a whole 40-bit block, the final group is padded with zero bits and the output is padded with = characters so its length stays a multiple of 8.

The most common place people meet Base32 is two-factor authentication. When you set up an authenticator app such as Google Authenticator, Microsoft Authenticator, or Authy, the shared TOTP secret is delivered as a Base32 string (often inside a QR code as the "secret" parameter). Base32 is chosen here precisely because a human may need to type the secret by hand: the alphabet has no look-alike characters, it is case insensitive, and it travels safely through systems that uppercase or lowercase text. Decoding that Base32 secret back to raw bytes is the first step every authenticator performs before it runs the HMAC and time-step math that produces your 6-digit code.

Base32 is not the same as Base64, and it is not encryption. Compared with Base64 it uses a smaller alphabet, avoids look-alike characters, and is case insensitive, but it produces longer output: Base32 inflates data by about 60 percent, versus roughly 33 percent for Base64. The trade is deliberate. You give up compactness to gain something you can dictate over the phone or print on paper without ambiguity. Like all such schemes Base32 is fully reversible and uses no key, so anyone can decode it. It hides nothing.

There is more than one Base32 alphabet in the wild. The standard RFC 4648 variant (A to Z then 2 to 7) is what TOTP and most general tools use. A second variant, base32hex (sometimes called extended hex), uses 0 to 9 then A to V so that the encoded text sorts in the same order as the underlying bytes, which is why DNSSEC NSEC3 records rely on it. A third, Crockford Base32, drops the letters I, L, O, and U to make short identifiers even harder to misread and adds an optional check symbol. They are not interchangeable: a string encoded with one alphabet will decode to garbage under another, so you have to know which variant produced your data.

This tool first converts your text to UTF-8 bytes, then groups those bytes into 5-bit chunks by hand, and reverses the process on decode, so multibyte characters round-trip correctly. It accepts upper or lower case input on decode and tolerates strings whose = padding has been stripped, which is common when Base32 travels through URLs or config files. Because every step runs locally in JavaScript, you can paste TOTP secrets, API material, or private notes without any of it being uploaded to a server.

When to use it

• Reading or generating the secret keys used by TOTP authenticator apps (Google Authenticator, Authy, Microsoft Authenticator), which are shared in Base32.
• Producing case-insensitive identifiers that survive systems which do not preserve upper and lower case, such as file names, share links, and database keys.
• Encoding small binary blobs for environments where the + and / characters of Base64 would break URLs, file paths, or DNS labels but readability still matters.
• Decoding a Base32 string you found in a config file, QR code, or migration script to inspect the original text or bytes inside it.
• Teaching or learning how bit-level encodings group data, since Base32 blocks are short enough to trace by hand step by step.
• Sanity-checking a 2FA setup by decoding the Base32 secret to confirm it matches the expected raw key before trusting an authenticator.

How to use the Base32 Encoder Decoder

1. Choose Encode to turn text into Base32, or Decode to turn Base32 back into text.
2. Type or paste your content into the input box. The result updates as you type.
3. Read the encoded or decoded result, including any = padding shown on encode.
4. On decode, do not worry about upper or lower case or missing padding; the tool normalizes both.
5. Press Copy to copy the result, or Swap input and output to feed the result back through the other direction.

Formula & method

Worked examples

The RFC 4648 Base32 alphabet (index to character)

How input length maps to padding (per final block)

Sample text and its Base32 encoding (RFC 4648 test vectors)

Base32 variants compared

Size overhead: Base32 versus Base64 and hex

Common mistakes to avoid

• Confusing Base32 with Base64. They are different schemes. Base32 uses 32 characters (A to Z and 2 to 7) and is case insensitive, while Base64 uses 64 characters including lowercase, +, and /. Feeding Base64 into a Base32 decoder fails because the alphabets do not match.
• Including the digits 0, 1, or 8. Standard Base32 omits 0, 1, and 8 to avoid confusion with O, I, and B. If you see those digits, the data is not RFC 4648 Base32; it may be base32hex (which uses 0 to 9) or Crockford Base32.
• Mixing up the variants. A string encoded with base32hex or Crockford will not decode correctly under the standard RFC 4648 alphabet, and vice versa. Always confirm which variant produced your data before decoding it.
• Treating Base32 as encryption. Base32 hides nothing. Anyone can decode it instantly, so never use it to protect passwords, tokens, or private data. Use real encryption when you need secrecy.
• Dropping or mangling the = padding. RFC 4648 Base32 pads each final block with = so the length is a multiple of 8. Some systems strip padding, which can break strict decoders. This tool adds padding on encode and tolerates its absence on decode.
• Encoding text that was already binary. If your input is itself raw bytes (such as a downloaded key) rather than UTF-8 text, encoding it through a text box can mangle it. Use a tool or library that reads bytes directly when round-tripping non-text data.

Glossary

Base32

An encoding that represents binary data using 32 characters (A to Z and 2 to 7), chosen to avoid look-alike symbols and to be case insensitive.

RFC 4648

The internet standard that defines Base16, Base32, and Base64 encodings, including the exact Base32 alphabet and padding rules.

base32hex

A Base32 variant using the alphabet 0 to 9 then A to V, which preserves byte sort order and is used by DNSSEC NSEC3 records.

Crockford Base32

A human-friendly Base32 variant that removes the letters I, L, O, and U and supports an optional check symbol.

TOTP

Time-based One-Time Password, the 2FA scheme whose shared secret is distributed as a Base32 string for easy manual entry.

Encoding

A reversible transformation of data into another format. Unlike encryption it uses no key and provides no secrecy.

Padding

The = characters added to the end of Base32 output so its length is always a multiple of eight.

UTF-8

The dominant character encoding for text. It represents each character as one to four bytes, which Base32 then groups into 5-bit chunks.

Frequently asked questions