Base32 encodes arbitrary binary data as uppercase letters A–Z and digits 2–7, producing strings that are case-insensitive and avoid visually ambiguous characters like 0/O and 1/I/l. It is used in TOTP authenticator secrets (Google Authenticator, Authy), file system paths on case-insensitive systems, and DNS-safe identifiers. This converter implements the RFC 4648 standard.
Base64 is more compact (6 bits per character vs Base32's 5), but it uses both upper and lowercase letters plus + and / — characters that cause problems in URLs, filenames, and case-insensitive contexts. Base32's alphabet is entirely uppercase and avoids ambiguous characters, making it safer for human transcription, QR codes, and contexts where case may be folded. The trade-off is ~60% overhead versus Base64's ~33%.
= charactersBase32 strings are safe to type, case-insensitive, and free of characters that are easily confused visually. When users manually enter a 2FA secret code from a screen or paper, Base32 reduces transcription errors.
Every 5 bytes of binary data become 8 Base32 characters — a 60% expansion. Base64 gives 33% expansion (3 bytes → 4 characters). Base32 is less compact but more human-friendly.
Zero looks like the letter O, and one looks like the letter I or l. RFC 4648 deliberately excludes them from the alphabet to prevent confusion when humans read or transcribe Base32 strings.
The standard Base32 alphabet (A–Z, 2–7) is already URL-safe — no characters require percent-encoding in URLs. Base64 needs a separate URL-safe variant that replaces + with - and / with _.
See also Base64 Encoder, Base58 Encoder, and ASCII85 for other binary-to-text formats.