Base32 Encode / Decode

What Base32 Is And Why It Exists

Base32 is a binary-to-text encoding scheme from RFC 4648. It uses a 32-character alphabet — A-Z plus digits 2-7 — carefully chosen to be case-insensitive and to avoid visually-ambiguous characters like 0/O and 1/I/l. This makes Base32 the right choice whenever encoded data has to be read aloud, handwritten, or printed and re-typed: you won't confuse a zero for an O in a TOTP shared secret.

Base32 vs Base64

Base64 is more compact — 4 output characters per 3 input bytes, vs Base32's 8 output characters per 5 input bytes (33% larger). But Base64 uses a 64-character alphabet including lowercase letters, digits, and `+/` — all of which are case-sensitive and some of which need URL-escaping. For in-software data transport, Base64 wins on compactness. For human-transcribed contexts, Base32 wins on robustness.

Common Use Cases

Two-factor authentication (TOTP / HOTP secrets per RFC 6238 / RFC 4226) are transmitted as Base32 — the secret you see on an authenticator-app setup screen is a Base32-encoded binary key. Tor v3 onion addresses are Base32. Some DNS schemes and Amazon's Glacier vault locks use Base32. Matrix, one of the earliest decentralised-messaging protocols, encodes its user-unique identifiers in Base32.

Padding Choice

RFC 4648 specifies padding with `=` characters to bring the length to a multiple of 8. Strict implementations require padding on decode. Permissive implementations (most modern libraries, including this one) accept unpadded input. The encode-side toggle defaults to padded-on for RFC compliance. Turn it off for targets that strip padding — some URL-embedding schemes, or TOTP setup QR codes that omit the padding to save QR bits.

What is Base32 and when do I need it?

Base32 encodes binary data using 32 characters (A-Z + 2-7). It's used for TOTP/OTP secrets (RFC 6238), Tor onion addresses, and anywhere you need a case-insensitive, human-typable binary representation.

How is Base32 different from Base64?

Base32 uses a 32-character alphabet (all uppercase letters + digits 2-7) that is case-insensitive and avoids visually-ambiguous characters (0/O, 1/I). Base64 uses 64 characters (mixed case + digits + +/) for a more compact encoding. Base32 strings are longer but safer for verbal or printed transmission.

Should I pad the output?

RFC 4648 says yes — pad with `=` to a multiple of 8 characters. Most libraries accept unpadded input, so the toggle is there for targets that are strict about length (e.g., some TOTP libraries).

Does it handle binary data?

This UI is text-in / text-out using UTF-8. For raw binary files, import `encodeBase32` from the lib directly — the helper accepts a `Uint8Array`.