Base32 Encoder Decoder
How it works
Base32 encoding represents arbitrary binary data using only 32 characters: A–Z and 2–7. Like Base64, it converts binary data to a text-safe representation, but uses a smaller alphabet that is case-insensitive, avoids ambiguous characters (0/O, 1/I), and produces output that is more human-readable. Base32 is used in TOTP/HOTP secrets (Google Authenticator), RFC 4648 data encoding, I2P anonymity network addresses, and Bitcoin bech32 addresses.
**Encoding mechanics** Base32 processes input in 5-byte (40-bit) groups, splitting them into eight 5-bit values. Each 5-bit value (0–31) maps to one Base32 character (A=0, B=1, ..., Z=25, 2=26, 3=27, 4=28, 5=29, 6=30, 7=31). Groups shorter than 5 bytes are padded with "=" characters to produce output divisible by 8. Expansion ratio: every 5 bytes of input → 8 Base32 characters (60% overhead).
**TOTP/HOTP secrets** Two-factor authentication apps use Base32-encoded secrets. When you scan a QR code to add an account to Google Authenticator or Authy, the underlying data contains a Base32-encoded secret key (typically 16 or 32 characters, representing 80 or 160 bits of entropy). The decoder converts this back to raw bytes for HMAC-SHA1 computation.
**Base32 vs. Base64** Base64 is more space-efficient (33% overhead vs. 60%) and faster to encode/decode. Base32 is preferred when the output must be: case-insensitive (Base64 is case-sensitive), typed by humans (fewer ambiguous characters), or used in contexts where certain Base64 characters (+ / =) cause problems (URLs, filenames, speech recognition).
**RFC 4648 variants** Standard Base32 uses A–Z and 2–7. Base32hex uses 0–9 and A–V (sortable lexicographic order). Crockford's Base32 uses 0–9 and A–Z minus I, L, O, U (further reducing confusing characters, used in human-readable IDs).
Privacy: all encoding/decoding runs in the browser. No data is transmitted.
Frequently Asked Questions
- TOTP (RFC 6238) specifies that shared secrets be transmitted as Base32 strings because: (1) Base32 is case-insensitive — users typing the secret manually won't introduce errors by capitalising/lowercasing letters. (2) Base32 avoids visually confusing characters (0/O, 1/I/l are absent from the standard alphabet 2–7 + A–Z). (3) Base32 is URL-safe — no + or / characters that need percent-encoding in QR code URLs. The typical Google Authenticator secret is 16 Base32 characters = 80 bits of entropy, which is the minimum TOTP recommends.
- Base64 encodes 3 bytes as 4 characters (33% size overhead). Base32 encodes 5 bytes as 8 characters (60% size overhead). Base64 is more space-efficient because it uses a larger alphabet (64 vs 32 characters), packing more bits per character. For example, a 20-byte SHA1 hash: Base64 = 28 characters; Base32 = 32 characters. The size penalty of Base32 is accepted when case-insensitivity or human-readability matters more than compactness.
- Standard Base32 (RFC 4648): A–Z (representing 0–25) and 2–7 (representing 26–31). Digits 0 and 1 are omitted because they look like O and I/l. Base32hex (RFC 4648 §7): 0–9 and A–V — this variant is sortable (the lexicographic order of Base32hex strings matches their numeric order), useful for sortable IDs. Crockford's Base32: 0–9 and A–Z minus I, L, O, U — maximises readability by removing ambiguous characters, used in ULID identifiers and some URL shorteners. z-base-32: an alternative encoding optimised for human oral transmission.
- A TOTP secret like 'JBSWY3DPEHPK3PXP' can be decoded to its raw bytes using Base32 decoding: each character maps to a 5-bit value; groups of 8 characters produce 5 bytes. 'JBSWY3DPEHPK3PXP' (16 characters) decodes to 10 bytes = 80 bits of entropy. The TOTP algorithm (RFC 6238) uses HMAC-SHA1 of the secret and a time-based counter, so the 80-bit secret provides adequate entropy assuming the secret was generated from a CSPRNG. Base32 is just the transport encoding — the actual secret is the decoded bytes.