Base32 Decoder

Decode and encode RFC 4648 Base32 (A–Z, 2–7) — as used in TOTP secrets, onion addresses and DNS tunnelling — and see binary results as hex.

Runs entirely in your browser. Your browser blocks this page from opening connections or loading anything from other sites. Nothing you enter is uploaded or saved.

requests since opened: 0
How to verify this yourself
  1. Open your browser’s developer tools (F12, or ⌥⌘I on Mac) → Network tab, then use the tool. No new requests appear.
  2. Or disconnect from the internet after the page loads — the tool keeps working, because it never needed the network.
  3. See the rule itself: in the Network tab, select this page’s document → Response Headers → content-security-policy contains connect-src 'none' and no 'unsafe-inline' for scripts.
  4. Press Test the lock: the page tries a harmless request and the browser blocks it (the Console shows the refusal).
How to use
  1. Paste the Base32 string; lowercase, spaces and missing = padding are fine.
  2. Read the text, or the hex dump for binary data such as a TOTP key.
  3. Choose “Text → Base32” to encode instead.

Steps

  1. 1.

Output

working…

How Base32 works

Base32 (RFC 4648) splits data into 5-bit groups and writes each as one of 32 characters: A–Z and 2–7. Every 5 bytes become 8 characters, so the output is 60% longer than the input, and = pads the last block to 8 characters. The decoder accepts lowercase and missing padding, which many systems drop.

Where you meet it

TOTP secrets: the secret= value in an otpauth:// QR code is Base32. Decoding it gives the raw HMAC key — binary, so it is shown as hex. Onion services: a v3 .onion address is the Base32 encoding of the service’s public key, a checksum and a version byte. DNS: because DNS ignores case, tunnelling and exfiltration tools often pack data into Base32 labels, so long random-looking subdomains in your DNS logs are worth decoding.

Not every Base32 is the same

Several variants use different alphabets. Base32hex (also in RFC 4648) uses 0–9 and A–V and keeps sort order; Crockford’s Base32 drops I, L, O and U and is used in IDs such as ULIDs; z-base-32 reorders the alphabet for readability. If a string contains 0, 1, 8 or 9 it is not standard Base32. For the time inside a ULID, use the Timestamp Converter.

Common questions

How do I recognise Base32?

Only capital letters A–Z and digits 2 to 7, often padded with = to a multiple of 8 characters. Digits 0, 1, 8 and 9 never appear, which avoids confusion with the letters O, I and B.

Why does my decoded TOTP secret look like garbage?

It is a random key, not text. The decoder shows it as hex instead — that is the HMAC key your authenticator app uses.

Why is Base32 used in DNS?

Domain names are case-insensitive and limited to letters, digits and hyphens. Base32 survives that, so DNS tunnelling and data-exfiltration tools often encode data as Base32 labels.

Known limitations

  • Standard RFC 4648 alphabet only. Base32hex (0–9, A–V), Crockford and z-base-32 use different alphabets and will decode to the wrong bytes.
  • TOTP seeds are secrets: the page cannot send them anywhere, but still avoid pasting live production seeds into any tool.
  • Browser extensions with access to this site can read the page. For sensitive data, use a private window with extensions off. How the lock works

tools v0.9.0 · build 7317bbb · 2026-10-07

Related reading on CipherMind

Standards & references