100% offline
Developer
Free · no signup
Updated

Base32 Encoder / Decoder

A Base32 Encoder / Decoder converts binary data to and from a 32-character text alphabet, packing five bits per character, using the RFC 4648 standard alphabet or one of its variants — entirely in your browser.

The default. Used by TOTP authenticator secrets, DNSSEC NSEC3 and Amazon S3 ETags.

About Base32 Encoder / Decoder

Base32 trades density for legibility. Where Base64 packs six bits into each character, Base32 packs five, so the output is 60% larger than the input rather than 33% — but the alphabet is limited to uppercase letters and digits, which survives case-insensitive systems, DNS labels, and being read down a phone line. That is why TOTP authenticator secrets, DNSSEC NSEC3 hashes and Amazon S3 ETags all use it. Four variants are here: the RFC 4648 standard alphabet, the extended-hex alphabet whose digits-before-letters ordering makes encoded strings sort in the same order as the bytes they encode, Crockford's alphabet which drops I, L, O and U so nothing can be misread, and Zooko's z-base-32. Input can be text, hex bytes or Base64, so you are not forced to pretend a key is a string. Decoding checks more than the alphabet: if the final character carries leftover bits that are not zero, the input is non-canonical and will not round-trip through a strict decoder, and the tool says so instead of silently discarding them.

What Base32 Encoder / Decoder does

  • RFC 4648 standard and extended-hex alphabets
  • Crockford Base32, with I and L read as 1 and O as 0
  • z-base-32, Zooko's human-oriented alphabet
  • Input as text, hex bytes or Base64 — not just text
  • Flags non-canonical trailing bits that a strict decoder would reject
  • Reports the exact size overhead of the encoding
  • Case-insensitive decoding, with whitespace and Crockford hyphens ignored

When to reach for Base32 Encoder / Decoder

  • Decoding a TOTP or 2FA secret to check what a key actually contains
  • Reading a Base32 value out of a DNSSEC record or an S3 ETag
  • Encoding binary for a system that upper-cases everything it stores
  • Producing an identifier that survives being read aloud or handwritten

How to use Base32 Encoder / Decoder

  1. 01

    Pick a direction

    Choose Encode or Decode. Decoding accepts either case and ignores whitespace.

  2. 02

    Choose the variant

    RFC 4648 is the default. Pick Crockford or z-base-32 if your input uses one of those alphabets — the same string decodes differently under each.

  3. 03

    Set how the input should be read

    Text is treated as UTF-8; switch to hex or Base64 when you are working with raw bytes such as a key or digest.

  4. 04

    Copy the result

    Use the copy button, or send the output back to the input to verify a round-trip.

When to use Base32 Encoder / Decoder vs alternatives

AlternativeUse Base32 Encoder / Decoder when…Use the alternative when…
`base32` on the command lineyou want the Crockford and z-base-32 variants, hex input, and a warning when the encoding is non-canonical.you are piping a file through a script.
Base64the destination is case-insensitive or the value has to be readable by a human — a DNS label, a printed code, a spoken key.size matters more than legibility; Base64 is 33% overhead against Base32's 60%.

Frequently asked questions

Why use Base32 instead of Base64?
Because the alphabet is more robust. Base32 uses only uppercase letters and digits, so it survives case-insensitive storage, DNS labels, filenames on case-folding filesystems, and being dictated over the phone. The cost is size: Base32 output is about 60% larger than the input, against 33% for Base64. Choose Base32 when a human or a case-insensitive system has to handle the value.
Why is my Base32 padded with '=' characters?
RFC 4648 requires the output length to be a multiple of eight characters, and '=' fills the gap when the input does not divide evenly into five-byte groups. The valid pad counts are 1, 3, 4 and 6 — any other number means the string is malformed. Crockford and z-base-32 drop padding entirely.
What is Crockford Base32?
Douglas Crockford's variant designed for values humans handle. It excludes I, L, O and U — the first three because they are confusable with 1 and 0, U because excluding it avoids accidental obscenities — accepts either case when decoding, treats I and L as 1 and O as 0, and allows hyphens as visual separators. It is a good choice for order numbers, licence keys and anything printed.
Can this decode a TOTP or 2FA secret?
Yes. Authenticator secrets from otpauth:// URIs are standard RFC 4648 Base32, usually without padding. Paste the secret and switch the output to hex to see the raw key bytes. Since nothing leaves your browser, this is safe to do with a real secret — which is not something to take on trust from a server-side tool.
What does 'non-canonical' mean when decoding?
The last character of a Base32 string only carries part of a byte, and the unused low bits must be zero. If they are not, the string decodes to the same bytes but re-encoding will not reproduce it, and a strict decoder — Python's base64 module with validate, or Go's StrictEncoding — rejects it outright. When that happens the tool decodes anyway and warns you, because it usually means the string was truncated or hand-edited.

Related concepts