Online Tool Store
· 5 min read
How to Encode and Decode Base32 Strings
Heshan Fernando
Co-founder & COO
Someone hands you a string like JBSWY3DPEHPK3PXP and says it’s the shared secret for a two-factor login. It isn’t gibberish and it isn’t encrypted — it’s Base32, and until you decode it you can’t tell whether the enrolment failed because the secret is wrong or because the clocks disagree.
Base32 turns up in exactly these awkward places: authenticator secrets, file hashes in URLs, sortable database IDs, DNS-safe tokens. It’s less familiar than Base64, so most people reach for a language REPL and lose ten minutes remembering which library does it. That’s a lot of ceremony for a reversible text transform.
What Base32 actually does
Base32 takes binary data and re-expresses it using 32 characters: the letters A to Z and the digits 2 to 7. It reads the input five bits at a time, and since five bits give exactly 32 possible values, each chunk maps cleanly to one character.
The consequence is a fixed ratio. Every five bytes of input become eight output characters. When your data doesn’t divide neatly by five, the encoder pads the tail with = signs until the output length is a multiple of eight. That’s why so many real-world Base32 values end in a run of equals signs, and why some systems strip them and others reject anything without them.
The alphabet is the interesting design decision. RFC 4648, the standard that defines Base32, deliberately leaves out 0, 1 and 8. Zero looks like O, one looks like I, eight looks like B. Removing them means a human can read a secret aloud over the phone or type it from a printed backup sheet without a transcription error silently breaking everything.
Why people get stuck here
- Confusing it with encryption. Base32 is an encoding, not a cipher. Anyone can decode it. A Base32 string is not protected by being Base32.
- Alphabet mismatches. Standard RFC 4648, base32hex, and Crockford’s Base32 all use 32 characters, but not the same 32 in the same order. Decode with the wrong one and you get plausible-looking garbage rather than an error.
- Padding disagreements. Some libraries require the
=padding, some reject it, and some silently accept either. A secret copied from a working system can fail in a new one for this reason alone. - Case handling. Base32 is conventionally uppercase but case-insensitive by design. A library that treats lowercase as invalid input is being stricter than the standard.
What good conversion looks like
It tells you which character it objected to
A decode failure should name the offending character and its position. “Invalid Base32” is useless; “unexpected 0 at position 11” tells you immediately that someone typed a zero where an O belonged.
It supports more than one alphabet
If you work with sortable IDs or DNS labels you’ll meet base32hex, whose alphabet preserves sort order. Crockford’s variant adds a check character and tolerates common misreadings. A converter that only knows RFC 4648 will quietly mangle both.
Nothing leaves your browser
Two-factor secrets are long-lived credentials. Pasting one into a page that posts it to a server is a genuinely bad idea, whatever the privacy policy says. Browser-only processing is the only sane arrangement for this particular data type.
| Input Type | What You Usually Want | Watch Out |
|---|---|---|
| Authenticator secret | Decode to check the raw key | Never paste a production secret anywhere |
| Sortable ID | base32hex, not standard | Standard alphabet breaks sort order |
| File hash in a URL | Standard, padding stripped | Re-adding = may be required to decode |
Common mistakes to avoid
- Treating a Base32 string as a secret in itself. If it’s visible, it’s readable.
- Decoding with the standard alphabet when the source system used base32hex — you get bytes, just the wrong ones.
- Stripping padding when copying a value into a strict parser, or leaving it in for a parser that rejects it.
- Retyping a secret by hand instead of copying it, then blaming the algorithm when the codes don’t match.
- Assuming a failed authenticator enrolment means a bad secret, when the actual cause is a device clock several minutes out.
How to do it with Base32 Encoder Decoder
The Base32 Encoder Decoder runs entirely in your browser — nothing you paste is transmitted anywhere.
- Paste the text or the Base32 string into the input box.
- Choose a direction: encode to Base32, or decode from it.
- Pick the alphabet the source system uses — standard RFC 4648 unless you know otherwise.
- Read the result, and copy it straight out. If decoding fails, the error names the character that broke it.
For related conversions, the full tools directory has Base64 and URL encoders that follow the same browser-only approach.
Frequently asked questions
Why does Base32 produce longer output than Base64?
Because it packs fewer bits per character — five instead of six. Base32 output is roughly 60% larger than the original data, against about 33% for Base64. You accept that overhead in exchange for case-insensitivity and an alphabet that survives being read aloud.
Can I use a secret generated online in production?
You shouldn’t. Everything here runs locally, but a web page can’t prove that to you, and a two-factor secret is a permanent credential. Generate production secrets inside your own application, with its own random source.
Why do my authenticator codes not match the server?
Usually clock drift rather than a bad secret. Check the time difference first. The second most common cause is an app that ignores non-default settings — several popular ones always use SHA-1, six digits and thirty seconds, whatever the enrolment URI asked for.
Final thought
Treat Base32 as what it is: a transport format, chosen because humans have to read it. If a value round-trips cleanly and still doesn’t work, the problem is almost never the encoding — it’s the alphabet, the padding, or a clock.