Base32 decode is a reversible text encoding that converts a 32-symbol alphabet — uppercase letters A through Z plus the digits 2 through 7 — back into the original five-bit groups that were assembled into bytes; the cheat sheet you need records the alphabet positions, the eight-characters-to-five-bytes ratio, the padding rules that turn partial groups into valid output, and the exact validation errors that should stop a malformed value from being silently accepted. RFC 4648 section 6 defines the canonical alphabet and the equals-sign padding used in every standard implementation, so a working cheat sheet maps each letter to its decimal index, lists how many equals signs a given input length requires, and flags common mistakes such as mid-string equals signs, the wrong padding count, or non-zero unused trailing bits. This page gives you that reference: the full alphabet table, the length-to-padding relationship, the three-step decoding workflow, the failure messages you can expect, and a short worked section that walks through the published RFC test vectors and shows why each decoded string either recovers cleanly or fails the validator. Bookmark this for quick lookups when decoding TOTP secrets, license keys, or any text that arrived as the 32-symbol subset of ASCII.
The Base32 Alphabet at a Glance
Every Base32 string you encounter draws from the same 32-symbol table defined in RFC 4648 section 6. Memorising it removes an entire class of decoding errors at a glance:
| Index | Char | Index | Char | Index | Char | Index | Char |
|---|---|---|---|---|---|---|---|
| 0 | A | 8 | I | 16 | Q | 24 | Y |
| 1 | B | 9 | J | 17 | R | 25 | Z |
| 2 | C | 10 | K | 18 | S | 26 | 2 |
| 3 | D | 11 | L | 19 | T | 27 | 3 |
| 4 | E | 12 | M | 20 | U | 28 | 4 |
| 5 | F | 13 | N | 21 | V | 29 | 5 |
| 6 | G | 14 | O | 22 | W | 30 | 6 |
| 7 | H | 15 | P | 23 | X | 31 | 7 |
Six anchor points carry most of the diagnostic value: 0 → A, 7 → H, 17 → R, 25 → Z, 26 → 2, 31 → 7. The alphabet intentionally jumps from Z to 2 instead of continuing through 0 and 1, because the human eye easily confuses 0/O and 1/I — that jump is the reason a Base32 cheat sheet needs to be looked at rather than guessed. Decoders normalise lowercase letters to uppercase before lookup, so a string typed in lowercase decodes identically; encoders always emit uppercase canonical output, however, so your reference values stay stable across tools.
How to Decode Base32 in Three Steps
The decoding side of an RFC 4648 implementation follows three concrete steps. Open the Base32 Encode / Decode tool and:
- Choose Decode for an RFC 4648 Base32 value (leave Encode off).
- Paste the Base32 string into the input area and read either the recovered UTF-8 text or a specific validation error.
- Copy the output, or use Swap to send it back into the input and confirm that Encode reproduces the original string.
The entire conversion runs in the current browser tab. UTF-8 conversion, bit grouping, validation, and clipboard preparation happen locally, and nothing is uploaded — useful when the payload is a private secret you do not want to share with a server. An old output cannot remain attached to newer text: the result is derived from the current input and current mode every time, and a clipboard denial never changes the conversion result.
Padding and Length Rules You Must Check
Base32 expands data because eight encoded characters always represent exactly five input bytes — before any padding is added. Output length is rounded up to a multiple of eight using equals signs, so the number of equals signs depends only on the input byte count modulo five:
- 0 bytes → output is empty, no padding.
- 1 byte → output is 8 chars, 6 of them equals signs.
- 2 bytes → output is 8 chars, 4 equals signs.
- 3 bytes → output is 8 chars, 3 equals signs.
- 4 bytes → output is 8 chars, 1 equals sign.
- 5 bytes → output is 8 chars, no padding at all.
A quick decoder check runs this rule in reverse: count the trailing equals signs, look up the implied byte count, and verify the data portion matches. Two more rules matter equally. The trailing bits inside the last partial group must be zero, and equals signs may appear only at the very end of the string. Mid-string padding, the wrong padding count, or non-zero trailing bits each trigger a specific validation error rather than a silent interpretation of different bytes — which is exactly what you want when the input came from an unreliable source.
Common Decode Errors and What They Mean
When a Base32 string fails to decode, a focused tool surfaces a named reason rather than a single generic failure. Recognising the wording speeds up debugging because each error points at a specific mistake:
- Invalid character: a punctuation mark, a digit outside 2 through 7, or a stray 0 or 1 slipped past the validator. The allowed alphabet is uppercase A–Z and digits 2–7 only — nothing else.
- Equals sign not at end: an equals sign appeared before the final position. Equals signs only belong at the very tail of the string as padding.
- Incorrect padding count: the number of trailing equals signs does not match what the byte length requires. The pad table above tells you the right count.
- Invalid data length: the unpadded string length mod 8 does not match any byte-aligned interpretation — six characters, for example, can never be a valid Base32 length.
- Non-zero unused bits: the last partial group held meaningful bits in a position the decoder would have to ignore. That signals the input was not produced by canonical encoding and should be regenerated with the standard alphabet.
Treat each of these messages as a fix-it signal rather than a guess-it signal: regenerate the encoded string with the same alphabet rather than hand-correcting it, because a hand-fix that lands one character off can change multiple output bytes.
When Base32 Decode Fails on Valid Strings
Base32 is a binary-to-text encoding, so a string can be syntactically perfect and still fail to produce readable text. The decoded bytes may represent arbitrary binary content — an image chunk, a cryptographic key, a compressed fragment — that simply is not valid UTF-8. A focused text decoder reports that limitation explicitly instead of replacing invalid byte sequences with replacement characters such as the Unicode question mark. If you need the bytes themselves rather than text, you have to use a binary-friendly decoder and inspect the raw byte stream.
The seven official RFC test vectors exercise every padding case from zero through five bytes, which gives a focused decoder something to verify against and gives you a fixture list to test your own code:
- Empty input stays empty.
- f encodes to MY====== (1 byte, 6 equals).
- fo encodes to MZXQ==== (2 bytes, 4 equals).
- foo encodes to MZXW6=== (3 bytes, 3 equals).
- foob encodes to MZXW6YQ= (4 bytes, 1 equals).
- fooba encodes to MZXW6YTB (5 bytes, no padding).
- foobar encodes to MZXW6YTBOI====== (6 bytes, 6 equals in the second block).
Each row follows the padding rule above, and each encoded string round-trips cleanly through Decode when you paste it back into the same tool. After decoding, click Swap and then Encode on the recovered text — a clean round trip reproduces the exact original string, character for character, which is the strongest local verification your decoder matches the published specification.
Limits of This Cheat Sheet
This reference covers RFC 4648 Base32 only. It does not implement Base32hex (the 0–9 A–V alphabet), Crockford Base32 (which folds visually confusing letters), z-base-32 (which adds a small checksum), TOTP key provisioning rules, the case-folding digits 0 and 1, arbitrary alphabets, streaming files, or any checksum variant. When the encoding appears alongside a checksum suffix or a non-standard alphabet, reach for a protocol-specific implementation: a generic decoder cannot tell from the alphabet alone which variant it received. A useful complement for one-click recovery is the decode Base32 strings back to readable text guide, which takes a more tool-first approach to the same task.
The alphabet positions, padding rules, and test vectors used throughout this page follow the published RFC 4648 specification for section 6, so any standard library that claims RFC compliance should agree with every anchor and fixture above — including the alphabet anchors at indexes 0, 25, 26, and 31, which map to A, Z, 2, and 7 respectively. One final reminder worth keeping on the page itself: Base32 is an encoding, not encryption, hashing, signing, or compression. Anyone holding the encoded string can recover the original bytes, and no key, secret, or integrity check is involved. Never treat an encoded value as protected — if you need secrecy, you need a real cipher such as AES-GCM, not a longer alphabet.