Decoding reverses the encoding steps. Let’s decode Q2F0 and Q2F0cw==.
Example 1: “Q2F0”
Step 1 — characters to values using the Base64 alphabet:
| Character | Q |
2 |
F |
0 |
|---|---|---|---|---|
| Value | 16 | 54 | 5 | 52 |
| 6-bit binary | 010000 | 110110 | 000101 | 110100 |
Step 2 — join the bits and split into bytes (8 bits):
010000110110000101110100
01000011 | 01100001 | 01110100
67 | 97 | 116
Step 3 — bytes to characters with the ASCII table: 67 → C, 97 → a, 116 → t.
Result: Q2F0 → Cat
Example 2: “Q2F0cw==” (with padding)
The first block decodes to Cat as above. The second block is cw==:
c w
011100 110000
Two = mean this block holds only one byte. Take the first 8 of the 12 bits and discard the rest (which must be zeros in strict decoding):
01110011 | (0000)
115 → "s"
Result: Q2F0cw== → Cats
What can go wrong
- Invalid characters (spaces,
-,_,%) have no value in the standard alphabet. Strict decoders stop; lenient ones skip them. Our validator shows their exact position. - Wrong length: a valid unpadded length is never 4n + 1, because one leftover character holds only 6 bits — not enough for a byte.
- Non-zero leftover bits, like
Q2F0cx==, are technically invalid but most decoders accept them and decode the same bytes. - Text looks garbled after decoding: the bytes are correct but displayed with the wrong character set. Use character encoding detection.
Try your own value with the Base64 decoder.
Comments (0)
Questions, ideas or a bug in “Base64 decoding step by step”? Leave a comment, rate the tool, or reply to others.
No comments yet. Be the first to share your feedback!