Base32 Encode

About Base32

Base32 trades density for legibility. Where Base64 packs three bytes into four characters, Base32 takes five characters to carry the same three — but its alphabet has one case, no punctuation and no character that can be mistaken for another, so a Base32 string survives being read aloud, typed off a screen, printed on a recovery card or written into a URL path. That is why two-factor secrets, Tor onion addresses and DNSSEC NSEC3 hashes are all written in it.

Three alphabets are in use and they are not interchangeable. RFC 4648 §6 is the common one — A–Z then 2–7, which is what an otpauth:// secret uses. Its extended hex variant in §7 puts the digits first so that encoded strings sort in the same order as the bytes behind them. Crockford's drops I, L, O and U entirely, accepts either case, and lets hyphens be sprinkled in for grouping. Decoding here tells you when a character is not in the alphabet you chose, and when the length is one Base32 cannot produce — which means characters have gone missing.

Where it helps

• One case and no punctuation, so it survives being spoken, typed, or put in a URL path.
• Covers all three alphabets in real use, and says which one it applied.
• Names the character that is not in the alphabet rather than reporting a generic failure.
• Catches lengths Base32 cannot produce, so a truncated paste is not decoded as though it were whole.

Limits

• About 60% larger than the bytes it carries, against Base64's 33% — it buys legibility with size.
• An encoding, not encryption: anyone holding the string can decode it, so a secret in Base32 is still a secret in plain sight.
• The three alphabets produce different strings from the same bytes, and decoding with the wrong one can succeed and give you the wrong answer.
• Crockford's check symbol is not implemented; only its alphabet and its lenient reading are.

Frequently asked questions

Why does my TOTP secret decode to gibberish as text?

Because it is not text. A TOTP secret is twenty random bytes used as an HMAC key. Switch the output to Hex — the tool says so when the bytes are not valid UTF-8.

Does the padding matter?

Only to strict parsers. RFC 4648 pads with = to a multiple of eight characters; otpauth:// secrets are normally written without it. Decoding accepts either.

What is the difference between Base32 and Base32hex?

Only the order of the alphabet. Extended hex puts 0–9 first so encoded values sort in byte order, which is why NSEC3 uses it. The same bytes give different strings in each.

Can I decode an onion address with this?

Yes — a v3 address is the part before .onion, in the RFC 4648 alphabet, and decodes to 35 bytes: a 32-byte public key, a two-byte checksum and a version byte.

Related tools

• Base64 — Encode or decode UTF-8 text and URL-safe Base64
• Base58 — Encode or decode Base58, and verify the Base58Check checksum an address carries
• Hash Generator — SHA-2, SHA-3, BLAKE and legacy digests, in any encoding
• HMAC Generator — Keyed message authentication codes
• URL Encoder — Percent-encode components or whole URLs
• HTML Entities — Escape and unescape HTML entities

More Encoders & Decoders tools

• Base64 — Encode or decode UTF-8 text and URL-safe Base64
• Base32 — Encode or decode Base32 in the RFC 4648, extended hex and Crockford alphabets
• Base58 — Encode or decode Base58, and verify the Base58Check checksum an address carries
• URL Encoder — Percent-encode components or whole URLs
• HTML Entities — Escape and unescape HTML entities
• JWT — Read, verify and sign JSON Web Tokens
• Punycode — Convert internationalised domain names to and from their ASCII form
• Unicode Converter — Escape, unescape and inspect code points
• Unicode Inspector — Analyse every character: category, script, block and encoding
• Number Base Converter — Binary, octal, decimal and hexadecimal, with the bits explained
• Hex and Text Converter — Text to hexadecimal bytes and back, with a dump
• Gzip Compressor and Decompressor — Compress and expand gzip, zlib and raw deflate