Valid in both alphabets
RFC 4648 and Crockford share these symbols and decode them to different bytes
MZXW6
Base32 Encoder and Decoder
Encode or decode base32 in both the RFC 4648 and Crockford alphabets. They overlap enough that one string is often valid in both and decodes to different bytes, so both are shown rather than guessed at.
Paste below, or drop a file anywhere on this panel
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Convert. Nothing leaves this tab.
Formatted
Results
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Examples
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
Unpadded, as a TOTP secret arrives
Legal for its format and rejected by a strict RFC 4648 decoder, which pads to a multiple of eight
MZXW6YTBOI
Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Assuming there is one base32 alphabet
RFC 4648 and Crockford overlap enough that a string can be valid in both and decode to different bytes, with nothing in the string to say which produced it.
Instead:Find out from the source. TOTP secrets and DNS records are RFC 4648; Crockford appears in identifiers meant to be read aloud.
Rejecting an unpadded string as invalid
RFC 4648 requires padding unless the specification using base32 says otherwise, and TOTP secrets and many identifier schemes drop it. A strict decoder refuses input that is perfectly correct for its format.
Instead:Accept unpadded input and pad it yourself before decoding, or use a decoder that tolerates it.
Choosing base32 over base64 without a reason
It is about 60% larger for the same data. The size is the cost of surviving case folding, hand transcription and DNS labels.
Instead:If the value never leaves a machine, use base64. If a human types it or DNS carries it, base32 earns the extra bytes.
Two alphabets, and a string can be valid in both
Base32 is larger than base64 and exists anyway, because it survives things base64 does not. Which alphabet produced a string is not recoverable from the string.
Why base32 exists at all
It is about 60% larger than base64 for the same data, which sounds like a straight loss. What it buys is surviving case folding, hand transcription and DNS labels, none of which base64 does. That is why a TOTP secret is base32: a human types it, and an alphabet that is case-insensitive and free of visually confusable characters is the whole point.
RFC 4648 against Crockford
RFC 4648 uses A to Z then 2 to 7. Crockford uses 0 to 9 then A to Z excluding I, L, O and U. A string using only letters A to H and digits 2 to 7 is legal in both and decodes to different bytes, with nothing in the string to say which. This tool shows both rather than picking, because picking would be wrong about half the time.
Crockford is deliberately forgiving
I and L decode as 1, O decodes as 0, and U is excluded entirely to avoid accidental profanity. Decoding is case-insensitive. All of that exists so a human reading a code aloud cannot produce an invalid one by confusing similar glyphs, which is a different design goal from RFC 4648.
Padding is optional in practice and required in the spec
RFC 4648 pads to a multiple of eight characters, so only zero, one, three, four or six equals signs can ever appear. Any other count means characters were lost. TOTP secrets and many identifier schemes drop padding entirely, which is legal where the specification using base32 says so, and is rejected by a strict decoder.
Direction is genuinely ambiguous for short input
A short run of letters and digits is decodable as base32 and is also just a string. Lowercase input is almost always text, since base32 is conventionally uppercase, but that is a convention rather than a rule. Both directions are shown for exactly that reason.
What this cannot see
Which alphabet your producer used, which is the question that decides the answer when a string is valid in both. Find it from the source: TOTP secrets and DNS records are RFC 4648, and Crockford turns up in identifiers designed to be read aloud.
More encoding tools
Base64 Encoder & Decoder Both directions, UTF-8 done right Unix Timestamp Converter Seconds or milliseconds? It says which JWT Decoder & Inspector Read the claims, and what is wrong with them URL Encoder and Decoder Which of the two functions you actually want HTML Entity Encoder and Decoder Five characters, not four hundred Hex Encoder and Decoder Bytes, with a hex dump String Escape Converter Six targets, one of them injection Punycode and IDN Converter The domain that is not what it looks like