Base32 Validator

Base32: case-insensitive encoding for TOTP secrets, Tor v3 and human-friendly identifiers

Base32 is the cousin of Base64 designed for environments where humans have to read, type or speak the encoded string. Standardized in RFC 4648 alongside Base64, Base32 uses an alphabet small enough to be case-insensitive and visually unambiguous, sacrificing density for legibility.

Every 5 input bytes become 8 output characters, giving a 60% overhead — worse than Base64's 33% but the trade-off pays off in dictation: try reading a Base64 string over the phone and then a Base32 one, and you'll appreciate the difference.

RFC 4648 alphabet and the missing digits

The standard Base32 alphabet is A-Z plus 2-7 — deliberately excluding 0, 1, 8 and 9. The reason is human transcription: 0 looks like O, 1 looks like I or l, and 8 and 9 are visually close to B and q. The validation regex is ^[A-Z2-7]+=*$ and the length must be a multiple of 8.

Padding uses the = sign exactly like Base64 — but Base32 allows up to 6 padding characters at the end (Base64 allows at most 2), because the bit-alignment between 5-byte groups and 8-character chunks is less forgiving.

Crockford Base32: the human-friendly alternative

Douglas Crockford proposed an alternative Base32 alphabet specifically optimized for human handling. It uses 0-9 and A-Z but excludes I, L, O and U — the first three because they look like digits, the last because it can produce accidental obscenities. Crockford Base32 is case-insensitive (lowercase is mapped to uppercase on decode), tolerates hyphens for readability, and adds an optional checksum character. It is the backbone of ULID identifiers and many short URL schemes.

Where Base32 shows up in production

• TOTP secrets (Google Authenticator, Authy, 1Password): the shared secret in otpauth:// URIs is encoded as Base32. A typical secret is 160 bits = 32 characters, sometimes shown with spaces every 4 chars for readability.
• Tor v3 .onion addresses: 56 characters of Base32 representing 35 bytes (256-bit public key + checksum + version). v2 was 16 chars; v3 was deployed in 2020 to defeat hash collisions.
• ULID identifiers: 26-character Crockford Base32 strings combining a 48-bit timestamp and 80 bits of randomness, lexicographically sortable.
• Bitcoin BIP-32 mnemonic backups: some seed-storage devices use Crockford Base32 to make hand-copying safer.
• DNS-based identifiers: hostnames have to be case-insensitive, so Base32 is a natural fit.

Base32 vs Base64 vs Base58 vs Hex

• Hex (Base16): simplest, 100% overhead, only 16 chars (0-9 A-F). Easy to read but verbose.
• Base32: 60% overhead, case-insensitive, no ambiguous characters. Best for humans.
• Base58: 36% overhead. Used in Bitcoin addresses; avoids 0, O, I, l. Not in RFC 4648.
• Base64: 33% overhead, case-sensitive, denser. Best for machines and bandwidth.

Libraries and tooling

Node ships no native Base32 (only Base64), so you reach for base32 or thirty-two on npm. Python's standard library has base64.b32encode / base64.b32decode (despite the module name). Go provides encoding/base32 with both standard and Hex variants. For Crockford Base32 specifically, look for base32-encode or implement the alphabet swap yourself — it's a 10-line function.

FAQ

How does Base32 compare to Base64?

Base32 is case-insensitive and uses a visually unambiguous alphabet, so it's easier to read, dictate and type. Base64 is denser (33% vs 60% overhead) but case-sensitive. Choose Base32 when humans touch the string, Base64 when only machines do.

Is padding mandatory?

In strict RFC 4648, yes — the encoded length must be a multiple of 8 with = filling the gap. In practice, many libraries accept unpadded input and infer the byte count from the character count. Crockford Base32 omits padding entirely.

Does Google Authenticator use Base32?

Yes. The shared TOTP secret in otpauth://totp/...?secret=... URIs is always Base32. A 160-bit secret produces a 32-character Base32 string, often grouped in 4-char blocks for easier manual entry.

Why exclude 0, 1, 8 and 9?

To prevent visual confusion when a human reads or transcribes the string. 0 blurs with O, 1 with I/l, and the remaining digits aren't excluded but the alphabet only needs 32 symbols — 2-7 was a clean range to pick.

Is Base32 case-sensitive?

No. RFC 4648 defines the alphabet as uppercase only, but the encoding is canonically case-insensitive: most decoders accept lowercase and uppercase identically. This is exactly why Base32 fits DNS hostnames and dictation scenarios.