Base32 encoder and decoder

What is base32?

Base32 represents arbitrary bytes using 32 printable characters, so that data which is not text can travel through places that only accept text. It is defined in RFC 4648, the same specification that defines base64 and base16, and it works in quanta of five bytes: forty bits split into eight groups of five, each group becoming one character.

The obvious question is why anyone would use it when base64 exists and is smaller. Base32 costs eight characters per five bytes against base64's four per three — a ratio of 8/5 against 4/3, which makes base32 exactly 6/5, or 20 percent, larger. You pay that 20 percent for one property: the alphabet is case-insensitive. Base64 needs both upper and lower case to reach 64 characters, so anything that folds case destroys it. Base32 uses only 26 letters and six digits, so it survives case-insensitive filesystems, DNS labels, hostnames, and being read aloud or written down.

That is the whole trade, and it explains where base32 actually shows up: in DNSSEC records, in file-sharing magnet links, and in the shared secrets that two-factor authenticator apps store, where a human sometimes has to type the thing.

How to use it

1. Pick Encode or Decode, then choose an alphabet. Standard is what you want unless you know otherwise. Extended hex is the other alphabet RFC 4648 defines, and the section below explains when it is the right one.
2. Paste your text or your base32 into the box. Encoding shows the byte count, the character count and the expansion ratio. Decoding is forgiving about whitespace and about lower case, because neither carries meaning here.
3. Copy the result. When encoding you can turn the trailing = padding off, because real specifications do. If you paste in something that is not a canonical encoding, the tool decodes it anyway and tells you, rather than pretending the input was fine.

Two alphabets, and the one nobody implements is the one that sorts

RFC 4648 defines base32 twice. Section 6 gives the familiar alphabet: A to Z, then the digits 2 to 7. Section 7 gives a second one it calls extended hex: the digits 0 to 9, then A to V. Almost every base32 implementation offers only the first, and the reason the second exists is exact rather than decorative.

The extended hex alphabet is in ascending ASCII order. Character values run 0 through 9 and then A through V, which is the order those characters already sort in, so the encoded string sorts exactly the way the underlying bytes do. The standard alphabet is not in ASCII order: it maps value 0 to the letter A, which is 0x41, and value 26 to the digit 2, which is 0x32. The last six values therefore sort before the first twenty-six, and the ordering breaks.

That is a claim worth measuring rather than asserting, so the tests do. Over twenty thousand generated pairs of equal-length byte strings, the extended hex alphabet preserves the ordering of every single pair. The standard alphabet preserves it 74 percent of the time, which is to say it usually looks fine and is unreliable exactly when you need it.

The property has a real consumer, which is the best confirmation available. DNSSEC's NSEC3 records, specified in RFC 5155, store hashed owner names in base32 with the extended hex alphabet, and the specification says why in as many words: that ordering is the same as canonical DNS name order when the names are encoded that way. NSEC3 works by proving that no name hashes into a gap between two neighbours, so the sort order is not a convenience there, it is the mechanism. RFC 5155 also drops the padding entirely, which is why this tool lets you turn it off.

The trade is visual, and it is more subtle than it first looks. The standard alphabet does not simply avoid ambiguous-looking characters — it keeps the letters O and I, which are the ambiguous ones. What it avoids is ambiguous pairs: because the digits 0 and 1 are not in the alphabet, an O can only ever be a letter and a 1 can never appear at all, so no misreading is possible. Extended hex contains 0, 1, O and I all together, and that genuine ambiguity is the price it pays for sorting.

Padding, and three lengths that cannot exist

Base32's padding rules are stricter than base64's and are more often got wrong. Because eight characters carry five bytes, a partial final group leaves a body of 2, 4, 5 or 7 characters, padded back up to eight with 6, 4, 3 or 1 equals signs respectively. Those four numbers are not a convention, they are arithmetic, and a decoder that accepts any other amount is accepting output no encoder produced.

The sharper consequence is that three lengths are impossible. A base32 body can never be 1, 3 or 6 characters longer than a multiple of eight, because no number of input bytes produces those. Compare base64, where only one length in four is impossible. So a base32 string of the wrong length is not merely short or truncated — it is proof that something upstream is broken, and this tool says so rather than guessing at what was meant.

Padding itself is optional in practice. The RFC's own examples include it, DNSSEC explicitly omits it, and authenticator secrets are usually written without it. This tool accepts input either way and lets you choose when encoding, because both are legitimate and a tool that insisted on one would be wrong about half the world.

When the same bytes have several spellings

Section 3.5 of RFC 4648 is titled Canonical Encoding, and it describes a problem most tools ignore. When the final group is partial, the last character carries some bits of real data and some leftover bits. The specification says those leftover bits must be set to zero by conforming encoders, and warns that if they are not, there is no canonical representation and multiple different strings decode to the same binary data.

The number of spellings is fixed by arithmetic. A body ending in 2 characters has 2 spare bits, so four different strings decode to the same single byte; a body of 4 characters has 4 spare bits and sixteen spellings; a 5-character body has 1 spare bit and two; a 7-character body has 3 spare bits and eight. Concretely, the single letter f encodes to MY, and MZ, M2 and M3 all decode back to f as well.

The specification only says a decoder may reject such input, and because it is a may, essentially nothing does. Python's standard library is a fair example of a careful implementation, and it accepted two thousand out of two thousand deliberately mutated strings, returning the original bytes for every one without a word. That is conforming behaviour and it is also how the same data ends up with several representations in systems that assumed it had one.

This tool takes the third option. It decodes non-canonical input, because refusing would be unhelpful and would tell you less, and then it says the encoding was not canonical and shows you what a conforming encoder would have written. If you are comparing base32 strings for equality anywhere — as cache keys, as identifiers, as deduplication keys — that difference is the bug you are looking for.

Honest limits

This encodes and decodes text, not files. The input is treated as text and converted to UTF-8 bytes before encoding, and on the way back the bytes have to be valid UTF-8 or the tool says so rather than handing you replacement characters. That last check means you cannot use this page to round-trip arbitrary binary through the decode direction, which is deliberate: silently mangling bytes is worse than refusing them.

Base32 is an encoding and not encryption. It hides nothing. Anyone who recognises the character set can decode it in seconds, and the fact that a string looks opaque is not protection of any kind. If you want text that other people cannot read, you want encryption, which is a different page on this site.

Finally, the two alphabets here are the two RFC 4648 defines. Other base32 variants exist in the wild — Crockford's, which drops several letters entirely and folds others together, and z-base-32, which reorders the alphabet for human use — and they are not interoperable with these or with each other. If a string will not decode here, the variant is the first thing to check.

Why is it free?

Because it costs nothing to run. The encoding and decoding happen in your browser as you type; nothing is uploaded, nothing is logged, and no server sees your text because no server is involved.

So there is no account, no sign-up and nothing held back behind one. The alphabets and the padding rules come from RFC 4648 itself, the test vectors in the suite are the ones the specification publishes, and the results are checked against Python's standard library as an independent implementation.