Base32 Encoder / Decoder

Encode and decode text using RFC 4648 Base32 encoding

What is it and how does it work?

Base32 is a binary-to-text encoding scheme that represents binary data using 32 characters: the uppercase letters A–Z and digits 2–7. Like Base64, it converts arbitrary bytes to a printable ASCII string — but Base32 uses a smaller, more human-friendly character set. Base32 output is case-insensitive (A and a are both valid), contains no ambiguous characters (no 0 vs O, no 1 vs I vs l), and is safe in URLs, filenames, and case-insensitive environments. The tradeoff: Base32 is 60% larger than the original data (vs. 33% overhead for Base64).

Base32 encoding is primarily used in: TOTP/HOTP two-factor authentication (the shared secret key is Base32-encoded — the string you enter into Google Authenticator), DNS labels, Onion addresses (Tor hidden services use Base32 for their .onion addresses), and some QR code payloads. This tool encodes and decodes between raw text/bytes and Base32, supporting both RFC 4648 standard Base32 and Base32hex (0-9, A-V).

Common use cases

• 2FA secret key: when setting up TOTP authentication (Google Authenticator, Authy), the secret key shown in the QR code is Base32-encoded — encode your secret bytes here to get the key to enter manually.
• Tor onion address: decode a .onion address to see the raw public key bytes — the address is Base32 encoded (v3 onion addresses are 56 Base32 characters encoding a 256-bit key).
• DNS-safe identifiers: encode binary identifiers as Base32 for use as DNS subdomain labels — Base32 avoids uppercase/lowercase ambiguity and special characters that DNS doesn't support.

Frequently asked questions

What is the difference between Base32 and Base64?

Base64 uses 64 characters: A-Z, a-z, 0-9, +, /. Base32 uses 32 characters: A-Z, 2-7. Base64 encodes 6 bits per character (24 bits → 4 chars, 3:4 ratio = 33% overhead). Base32 encodes 5 bits per character (40 bits → 8 chars, 5:8 ratio = 60% overhead). Base32 advantages: case-insensitive, no ambiguous characters (O/0, I/l/1), safe in filenames and DNS. Base64 advantage: more compact output.

Why does Base32 use A-Z and 2-7, not A-Z and 0-9?

The RFC 4648 character set (A-Z, 2-7) avoids digits 0 and 1 because they're visually ambiguous with letters O and I in many fonts. Including 0-9 would require using 0 and 1, creating confusion. Using 2-7 gives 6 digits without ambiguity, combined with 26 letters = 32 characters. The alternative Base32hex uses 0-9, A-V — which maintains numeric ordering but includes ambiguous characters.

How does TOTP use Base32?

TOTP (RFC 6238) generates 6-digit codes from a shared secret and the current time. The shared secret is arbitrary bytes (typically 10-20 bytes of cryptographic randomness). Base32 is used to encode this secret for display to users — it's human-typeable (case-insensitive, no ambiguous characters) and compatible with QR codes. When you scan a QR code to set up 2FA, the QR code typically contains a URI like `otpauth://totp/example@gmail.com?secret=JBSWY3DPEHPK3PXP&issuer=Example` where `JBSWY3DPEHPK3PXP` is Base32.

What are the padding characters in Base32?

Base32 uses `=` as padding to make the output length a multiple of 8 characters. Since Base32 encodes 5 bits per character and input bytes are 8 bits each, 8 input bytes → 64 bits → 64/5 = 12.8 → 13 characters, but outputs are padded to 16. Padding variants: 0 padding chars needed for 5 bytes (40 bits = 8 chars exactly); 1 padding char for 4 bytes; 3 for 3 bytes; 4 for 2 bytes; 6 for 1 byte. Many implementations omit padding (called "unpadded Base32").

Security

Password Strength Checker · ROT13 Cipher · Hex Encoder / Decoder · Caesar Cipher · Vigenère Cipher · Atbash Cipher