Skip to content
ToolBoxGeniehome

Base32 Converter

Developer Tools · Added

Base32 trades size for legibility: no lower-case letters, no punctuation, and in Crockford's variant no characters you can misread for each other. Convert text or hex bytes either way, in whichever alphabet the thing you are talking to expects.

Direction

A-Z and 2-7. What TOTP secrets, onion addresses and most APIs use.

How to use the base32 converter

  1. 1Choose whether you are encoding or decoding.
  2. 2Pick the alphabet: RFC 4648 for standards work, Crockford where a human has to read it aloud.
  3. 3Paste your input — text, or hex bytes if the data is not text.
  4. 4Turn padding on or off to match what the other side expects.

Examples

A five-byte string

Input
Hello
Result
JBSWY3DP — exactly eight characters, so no padding is needed.

Five bytes is Base32's natural group size, which is why this case comes out clean.

A string that needs padding

Input
ToolBoxGenie
Result
KRXW63CCN54EOZLONFSQ==== — twelve bytes leaves a remainder, and four equals signs fill the last group.

About the base32 converter

Where Base32 actually turns up

The encoding is less common than Base64 but it is not obscure. TOTP authenticator secrets are Base32 precisely because people type them in by hand from a printed code. Tor onion addresses use it because they have to survive DNS, which is case-insensitive. Some content-addressed storage systems use it so a hash can become a filename on any filesystem, including the ones that fold case.

The pattern behind all three is the same: Base32 appears wherever the encoded value has to pass through a system that does not preserve case, or through a human. When neither applies, Base64 is the better trade.

The cost of the alphabet

Every five bits of input becomes one output character, so three bytes of every eight are pure overhead — a 60% increase, against Base64's 33%. On a large payload that difference is real, and it is the reason Base32 never displaced Base64 for general encoding.

It also explains the padding. Five bytes map cleanly onto eight characters, but any other remainder leaves a partial group that has to be filled, which is where the runs of equals signs come from. Padding can be dropped when both sides know the length another way, and plenty of protocols do exactly that — hence the switch on this page.

Frequently asked questions

Why use Base32 when Base64 is shorter?
Because Base32's alphabet survives contact with the physical world. It has no lower-case letters, so it is unaffected by case-insensitive systems such as DNS labels and older filesystems; it avoids punctuation that needs escaping in URLs; and it can be read aloud, typed from a printout or written on a label without ambiguity. The cost is size: Base32 inflates data by 60% against Base64's 33%.
What is different about the Crockford alphabet?
It is designed against human error rather than for round-trip fidelity. It excludes I, L, O and U — the first three because they are confusable with 1 and 0, the last to avoid accidental obscenities — and when decoding it accepts either case and treats I and L as 1 and O as 0. That makes it a good fit for identifiers people read out, and a poor fit for anything expecting strict RFC 4648.
Why do I sometimes get four or six equals signs?
Base32 packs five bytes into eight characters, so a leftover of one, two, three or four bytes produces six, four, three or one padding characters respectively. Only those five block lengths are ever valid, which is exactly why a Base32 string of some other length is rejected here rather than decoded into something plausible-looking.
Can it handle data that is not text?
Yes — switch the input to hex and the bytes are used directly, with no character encoding in the way. Decoding works the same in reverse: if the result is not valid UTF-8 text you get the bytes as hex instead of a string of replacement characters, since silently mangling binary data is worse than declining to display it.

Related tools