Browser processing Input is processed on your device. Privacy & storage

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.

Text input
Base32 output

Three alphabets, and picking the right one

AlphabetCharactersUse 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.