Base32 Encoder / Decoder

Encode or decode RFC 4648 Base32 strings.

Mode

Text Input

Base32 Output

About Base32 encoding

Base32 (RFC 4648) encodes binary data using 32 case-insensitive characters — A–Z and 2–7 — chosen to avoid ambiguous glyphs like 0/O and 1/I. It's used for TOTP/2FA secret keys, DNS, and any context where a string must survive case-folding or be read aloud. Five bytes encode to eight characters, with = padding. Encoding and decoding both run locally in your browser.

Built and maintained by Meet Shah · Last updated 19 July 2026

What this tool is used for

Reading or producing the shared secret behind a TOTP authenticator entry, which is Base32 by convention.
Encoding a value for a case-insensitive system, where Base64 would collapse two distinct characters into one.
Producing an identifier that survives being read aloud or typed from a printout without ambiguity.
Decoding a Base32 string taken from a DNS record or a filename-safe identifier.
Checking whether a secret was truncated by counting the encoded length rather than guessing.

Frequently Asked Questions

Why use Base32 when Base64 is more compact?: Because Base32 is case-insensitive and its alphabet excludes 0, 1, 8 and I to avoid look-alike confusion. That makes it safe for things humans read aloud, type by hand, or store in case-insensitive systems like DNS.
How much overhead does it add?: 60% — five bytes become eight characters, against Base64's 33%. You are paying that size penalty specifically to buy case-insensitivity and transcription safety, so it is only worth it when those matter.
Where is it actually used?: TOTP two-factor secrets (which is why authenticator setup keys are Base32), Tor onion addresses, DNS-based protocols, and Bitcoin's Bech32 addresses. All are cases where a human or a case-insensitive system handles the string.
Why is the padding so long?: Because 5 bytes map to 8 characters, an incomplete group needs up to six = characters — far more than Base64's maximum of two. Some implementations omit padding entirely, which is a frequent interop problem.
Are there different alphabets?: Yes. RFC 4648 defines the standard alphabet (A-Z, 2-7) and base32hex; Crockford's Base32 excludes I, L, O and U (partly to avoid accidental profanity) and treats similar-looking characters as equivalent on decode.
Why is Base32 used for TOTP secrets?: Because the secret has to be typed or read aloud when a QR code fails, and Base32 is case-insensitive and free of easily confused characters. Base64's mixed case makes it unusable for that, which is the whole reason the standard picked 32.
Which characters does the standard alphabet exclude?: The digits 0, 1 and 8 — omitted because they are confusable with O, I/L and B. The remaining set is A–Z plus 2–7, which is exactly 32 symbols and therefore five bits per character.
What is Crockford's Base32?: A variant that additionally accepts the confusable characters on input, mapping O to 0 and I/L to 1, and offers an optional check symbol. It is designed for identifiers humans transcribe, where forgiving input matters more than a canonical alphabet.

Common errors and gotchas

Expecting Base64's compactness. Base32 carries five bits per character, so the output runs about 60% larger than the input.
Confusing the excluded characters. The standard alphabet omits 0, 1, 8 and 9 to avoid look-alikes, so a zero in the input is a red flag.
Assuming one alphabet. RFC 4648 and Crockford differ, and a string from one will not decode cleanly with the other.
Stripping the padding because it looks excessive. Base32 can need up to six `=` characters and some decoders require them.
Pasting a lower-case secret into a decoder that only accepts upper case, when the encoding is deliberately case-insensitive.