Base32 Encoder / Decoder
Encode or decode RFC 4648 Base32 strings — the format behind TOTP secrets and DNSSEC
About this tool
The Base32 Encoder/Decoder converts text or hex bytes to and from RFC 4648 Base32 — the encoding you'll most often run into as the format behind TOTP/2FA secret keys (the string you type or scan as a QR code into Google Authenticator) and in DNSSEC records, where Base32's case-insensitivity and avoidance of visually similar characters (no 0/1/8/9, unlike Base64) make it a better fit than Base64 for values that sometimes get manually typed or read aloud. Encoding works in fixed 5-bit groups (32 = 2^5 symbols) padded to a multiple of 8 characters with =, verified here against the official RFC 4648 test vectors.
When to use it
- →Decoding a TOTP/2FA secret key to inspect its raw bytes
- →Encoding a value that needs to be case-insensitive and safely spoken aloud or hand-typed
- →Understanding what a Base32-encoded DNSSEC or NSEC3 record actually contains
- →Converting between Base32 and hex when working with low-level cryptographic key material
Tips
- ◆Base32 is case-insensitive by convention — this decoder accepts either case, though the canonical RFC 4648 output is uppercase.
- ◆Unlike Base64, Base32's alphabet (A-Z, 2-7) deliberately excludes 0, 1, 8, and 9 to avoid confusion with O, I/L, B, and g — this is exactly why TOTP secrets use it instead of Base64.
- ◆Padding (=) brings the output to a multiple of 8 characters — most TOTP apps strip it, but it's part of the formal RFC 4648 spec and this tool includes it by default.
Frequently asked questions
Why does my authenticator app's secret key look different from this tool's output?
Most authenticator apps display the secret without its trailing = padding, since padding is optional in practice for TOTP even though it's part of the formal spec. If you remove the padding characters from this tool's output, you should get the same string the app shows.
What's the difference between Base32 and Base58?
Base32 (RFC 4648) uses a 32-character alphabet and is the standard for TOTP secrets and DNSSEC — it's case-insensitive and includes padding. Base58 uses a differently-curated 58-character alphabet (no padding, also avoiding ambiguous characters) and is specifically associated with Bitcoin-style addresses and identifiers. They solve a similar problem — safe, unambiguous encoding — for different ecosystems.