Base32 Encode / Decode
Encode text to Base32 or decode it back. Supports standard (RFC 4648) and extended hex alphabets. All in your browser.
How to use the Base32 Encode / Decode
Choose Encode or Decode, then pick the alphabet (standard or extended hex).
Type or paste your text.
Copy the converted result.
What is Base32, and why does TOTP use it instead of Base64?
Base32 encodes bytes using 32 characters (A-Z and 2-7 in the standard RFC 4648 alphabet), packing 5 bits per output character instead of Base64's 6 — the trade-off is about 20% larger output for an alphabet that's unambiguous when read aloud, written by hand, or typed on a phone keypad, and safe in case-insensitive contexts (Base64's mixed case would collide if lowercased). That's exactly why TOTP two-factor secrets (the codes Google Authenticator, Authy, and similar apps import) are Base32-encoded — a 16- or 32-character secret key needs to survive being typed manually or read off a screen without 0/O or 1/I/l confusion, which Base32's alphabet avoids by design. DNSSEC record encoding and some case-insensitive filesystems use Base32 for the same reason. The extended hex variant (0-9, A-V) exists for contexts that need the encoded output to sort in the same order as the original bytes — standard Base32's letters-before-digits ordering doesn't preserve byte ordering, but the hex variant does, which matters for indexed lookups. This tool supports both alphabets and pads output per RFC 4648 by default.
For a step-by-step walkthrough, read our guide: Base32 Encoding Explained: RFC 4648, Hex Alphabet & When to Use It.
Key features
- Encode and decode text to/from Base32
- Both standard (RFC 4648, A-Z 2-7) and extended hex (0-9 A-V) alphabets
- Correct UTF-8 handling for non-ASCII input
- 100% client-side — nothing you type is uploaded
Frequently asked questions
Why do TOTP / two-factor auth secrets use Base32 instead of Base64?
Base32's alphabet (A-Z, 2-7) has no ambiguous look-alike characters and is fully case-insensitive, so a secret can be typed by hand or read off a screen without transcription errors — Base64's mixed-case + and / characters don't have that property.
How much bigger is Base32 output than the original input?
About 60% larger (8 output characters per 5 input bytes), versus Base64's ~33% overhead — the trade-off buys human-readability and case-insensitivity, not compactness.
When would I use the extended hex alphabet instead of standard?
When the encoded strings need to sort in the same order as the original bytes — e.g. indexed database keys — since extended hex (0-9 then A-V) preserves byte ordering while the standard alphabet (A-Z then 2-7) does not.
Is my text uploaded anywhere to encode it?
No — encoding and decoding run entirely in your browser's JavaScript.