Reversing the process
Decoding runs the encoding steps backward: each group of 4 Base64 characters maps back to its 6-bit value, four 6-bit groups combine into 3 bytes, and any trailing = padding tells the decoder how many bytes to discard from the final group. Because the mapping is exact and lossless, decoding always reproduces the original bytes exactly — there's no approximation involved.
Why decoding sometimes fails
- Missing or incorrect padding. A string like
SGVsbG8(missing its trailing=) is invalid under a strict decoder, even though the actual data is recoverable — some tools auto-correct this, others reject it outright. - Mixed alphabets. A string containing
-or_(URL-safe characters) decoded with a standard decoder expecting+//, or vice versa, produces garbage or an outright error. - Embedded whitespace or line breaks from a source that used MIME-style 76-character line wrapping, which some strict decoders won't strip automatically.
- Truncated copy-paste. Base64 strings are long and easy to accidentally cut off partway through when copying from a terminal or log — the result decodes to fewer bytes than intended, silently.
Decoding an image back to something viewable
A Base64-encoded image (commonly seen as a data:image/png;base64,... data URI) decodes back to the exact original image bytes — the data:image/png;base64, prefix isn't part of the encoded data itself, it's a MIME-type declaration telling the browser or viewer how to interpret the bytes that follow. Strip that prefix before decoding if your tool expects raw Base64 rather than a full data URI, then save the decoded bytes with the correct file extension to view it as an actual image.
Common mistakes
- Forgetting to strip the
data:image/...;base64,prefix before feeding the string to a plain Base64 decoder, which will otherwise choke on the non-Base64 prefix characters. - Assuming a decode error means corrupted data. Often it just means padding, alphabet, or whitespace mismatch — issues in the string's formatting, not the underlying content.
- Not verifying the output length matches expectations — a truncated input decodes without necessarily erroring, just producing fewer bytes than the original.
FAQ
Why does my Base64 string fail to decode with an "invalid character" error?
Most likely it's mixing standard (+//) and URL-safe (-/_) alphabet characters, or contains stray whitespace/line breaks the decoder isn't stripping.
Can I decode Base64 back to a viewable image directly?
Yes — strip any data:image/...;base64, prefix first, decode the remaining string to bytes, then save those bytes with the appropriate image file extension.
Is Base64 decoding ever lossy?
No — assuming the input is valid and complete, decoding exactly reconstructs the original bytes, since Base64 is a lossless encoding.
Decode text and images directly in your browser with the Base64 Encoder/Decoder — nothing is uploaded anywhere.