Base32 Encoder / Decoder
Text or bytes to Base32 and back — standard, base32hex or Crockford, with the byte view you need when the payload is not text.
Three alphabets, and picking the right one
| Alphabet | Characters | Use it for |
|---|---|---|
| RFC 4648 standard | A–Z and 2–7 | TOTP and HOTP shared secrets, and most APIs that say "base32". Also what a TOTP app shows you when you copy a setup key. |
| RFC 4648 hex (base32hex) | 0–9 and A–V | Anything that has to stay in sort order when compared as text — digits sort before letters, so numeric prefixes behave. |
| Crockford | 0–9 and the 22 unambiguous letters | Values a human will read aloud or retype: I, L, O and U are removed, and I/L are read back as 1, O as 0. |
Why Base32 exists when Base64 is shorter
Every Base32 character carries exactly 5 bits, so the encoding grows by 60%. Base64 grows by only 33% and is what you should use for a binary blob in an HTTP header. Base32 wins in two narrower situations:
- Case-insensitive transports. Base64 is case-sensitive, and DNSSEC, some licence keys and older mainframe-style systems fold case somewhere on the path. Base32's standard alphabet is already uppercase, so folding it is harmless.
- Human transcription. There are no
+,/or=in the middle of a standard Base32 string, and no ambiguous letter pairs once you avoid the letters Crockford removes.
Padding, and reading it strictly
Eight symbols carry five bytes, so a payload that is not a multiple of five bytes needs
= to square off the last group. Decoding here accepts input with or without
padding, and with spaces, dashes or newlines in it — secrets get copied out of the middle of
a sentence often enough that rejecting whitespace would be hostile.
One thing it will tell you about is a non-canonical tail: if the bits past the last complete byte are not zero, the string cannot have come from a correct encoder. That is a warning rather than an error, because real TOTP secrets are frequently stored that way.
When the payload is not text
Base32 is often used for binary data — a hash, a key, a compressed blob. Decoding it and rendering the result as UTF-8 would produce replacement characters and lose exactly the bytes you wanted, so the byte view is shown alongside: the same payload as hex, which is lossless and easy to compare against another source.
Edge cases worth knowing
- Decoding is case-insensitive in every alphabet, which is what makes a folded secret still work.
- Stray characters are rejected by name. Anything outside the chosen alphabet is reported, so a secret copied with a trailing period or a smart quote is obvious rather than silently truncated.
- Empty input is not an error — it just encodes to nothing. That matters when you are typing into the box, not when you have finished.
- The 60% overhead is exact. A 100-byte payload becomes 160 characters, plus
up to six
=signs. The size line turns into a useful sanity check when a key you expected to be 20 bytes is clearly longer.
FAQ
My TOTP secret has no padding — is it still valid?
Almost always, yes. Authenticator apps strip the padding because it carries no information. Paste it with or without and the decoded bytes are identical.
Do I need padding checked for a TOTP secret?
If you are generating a secret for an app to consume, uncheck it — that is what the apps expect. If you are writing it into a document for a human, keeping it makes the grouping clear.
How do I turn a Base32 secret into a QR code?
Use the TOTP generator: paste the secret and it builds the full otpauth:// URI, which the QR code generator can render.
Is anything I paste sent to a server?
No. Encoding and decoding are plain JavaScript in this tab.