Base64 Decoder

Decoding Base64 means turning those 64 printable characters back into the bytes they stand for. It is the exact reverse of encoding, and it is lossless: the bytes that come out are the bytes that went in.

The interesting part is what happens next. Base64 carries no type information — it is a way of spelling bytes, not a container — so a decoder gets back a pile of bytes with nothing to say whether they are a sentence, a JSON document or a PNG. Working that out is what separates a useful decoder from a text box.

1TWFueSBoYW5kcyBtYWtlIGxpZ2h0IHdvcmsu

1Many hands make light work.

That example is text. Feed the same decoder the contents of a data URI and the bytes will begin 89 50 4E 47 — the signature every PNG starts with — at which point showing you the picture is far more useful than showing you the mojibake those bytes make when read as characters.

Encoding takes 24 bits at a time — three bytes — and re-cuts them into four six-bit groups, each of which picks a character. Decoding runs that backwards: four characters become four six-bit values, which join into 24 bits, which split into three bytes.

1"TWFu"  →  19, 22, 5, 46  →  010011 010110 000101 1011102         →  01001101 01100001 01101110  →  77, 97, 110  →  "Man"

Padding is what handles input that did not divide evenly. One = means the final group carried two bytes; two mean it carried one. The padding contributes no data of its own — it exists so the length is always a multiple of four.

Three things routinely go wrong, and each has its own message here:

• A character outside the alphabet. Usually a value that was truncated, copied along with the text around it, or percent-encoded in transit — run it through the URL decoder first if you see %2B or %2F in it.
• Padding in the wrong place. Almost always two separate values concatenated — decode them one at a time.
• An impossible length. Base64 can never have exactly one character left over after groups of four, so characters are missing from the end.

Two variations are accepted without being asked about. The URL-safe alphabet uses - and _ where the standard one uses + and /; since neither pair can appear in the other, accepting both is never ambiguous. And padding is optional, because JWTs drop it — paste a whole token into the JWT decoder instead and it splits the three segments for you.

Finally, the bytes are tested against UTF-8. If they decode cleanly, the result is text; if they do not, it is a file — and that answer decides which views the tool offers you.

1. 1. Add the Base64. Paste it into the left panel, drop a file anywhere on the tool, or use the upload button. Line breaks, spaces and missing padding are all fine — they are ignored.
2. 2. Check the status bar. It reads Decoded along with the detected MIME type and size. If the input is not valid Base64, it names the problem, its line and column, and offers a button that jumps the cursor there.
3. 3. Look at the detected format. The badge above the output says what the bytes turned out to be. That is what decides whether you get a rendered page, an image, formatted source or a hex dump.
4. 4. Switch views. HTML offers rendered and source; text formats offer the formatted content; binary offers the summary and dump. Statistics is always available.
5. 5. Take the result. Copy the text, or download the file — the download writes the decoded bytes under the extension the detection worked out, so a decoded PNG saves as a working .png. The MIME type lookup goes the other way when you have the media type and need the extension.

For a long document, press Ctrl+F (Cmd+F on a Mac) to search the decoded content rather than scrolling it. Matches are highlighted and counted, and the arrows step through them.

They are exact inverses, and the asymmetry between them is not in the arithmetic — it is in what can go wrong.

Encoding never fails. Every possible sequence of bytes has a Base64 representation. Give an encoder anything and it produces valid output.

Decoding can fail, because not every string is valid Base64. That is why a decoder needs the error messages an encoder does not: a wrong character, bad padding, an impossible length. It is also why a decoder benefits from format detection and an encoder does not — the encoder was handed something whose type the caller already knew.

The practical differences:

• Direction of size. Encoding grows data by about a third; decoding shrinks it by about a quarter, back to the original.
• Certainty. Encoding always succeeds. Decoding validates first, and says precisely where the input stopped making sense.
• What you get back. Encoding always yields text. Decoding might yield text, or might yield a PNG — which is why this tool works out which before deciding how to show it.

One thing they share, and it is the thing most worth knowing: neither is encryption. Base64 has no key. Anyone holding an encoded value can decode it in seconds — this page will do it for them. Treat encoded data exactly as you would treat the original.

Going the other way? The Base64 Encoder handles text and files, with URL-safe output and MIME line wrapping.