Base32 Encode & Decode
RFC 4648 and Crockford Base32 with confusable-tolerant decoding and a byte hex view.
The + and / in Base64 misbehave in URLs and filenames, and O/0 or l/1 are indistinguishable in handwriting. Base32 solves both with 32 unambiguous characters (A-Z, 2-7): case-insensitive, no confusables — at the price of 60% size growth. It lives in two places: two-factor secrets (the Google Authenticator otpauth convention) and data that humans transcribe.
This tool supports both the RFC 4648 standard and the Crockford variant — which removes I/L/O/U entirely and maps 0 and 1 back to O and I automatically, ideal for human copy chains. Decoding is forgiving: mixed case, space or dash separators (PEM style), and missing trailing = padding all decode correctly.
RFC 4648 vs Crockford
The standard alphabet is A-Z2-7 padded with = to multiples of 8; Crockford reorders the alphabet to 0-9A-Z minus I/L/O/U, skips padding, and treats 0/O and 1/I/L as identical when decoding. 2FA secrets use the standard variant; human-transcribed codes (order numbers, invite codes) are safer in Crockford.
Why the 60% size growth
Each Base32 character carries 5 bits (Base64 carries 6), so the same bytes need more characters: 8 bytes becomes about 13. The tax buys an all-pronounceable, all-writable 32-character set — the fee for the human channel.
Frequently asked questions
- Decoding reports an invalid character — why?
- The standard alphabet is A-Z and 2-7 only: a 0, 1, 8 or 9 means the input is Crockford, Base58 or something else — switch alphabets. Crockford decoding auto-corrects 0→O and 1→I.
- Does it handle Chinese text?
- Yes. Text is UTF-8 encoded to bytes before Base32, so Chinese, English and emoji all round-trip correctly.
- What does this have to do with 2FA secrets?
- The uppercase string in an authenticator app is the Base32 encoding of the secret's bytes; the site's TOTP tool decodes it the same way before computing codes.