How to Decode a Base64 Image String Back Into a File

You open a JSON response, an email source, or somebody’s CSS file, and there it is: a wall of letters and digits three thousand characters long, starting with iVBORw0KGgo. That’s a picture. You just can’t see it yet.

The Base64 to Image tool turns that wall back into something you can look at and save.

What the string actually is

Base64 takes arbitrary bytes and rewrites them using 64 printable characters, so binary data can survive travelling through places that only tolerate text. Email bodies. JSON fields. HTML attributes. Every 3 bytes of the original file become 4 characters, which is where the roughly 33% size penalty comes from.

The first few characters give the format away, because the file’s magic bytes always land in the same place:

iVBORw0KGgo means PNG
/9j/ means JPEG
R0lGOD means GIF
UklGR means WebP
PHN2Zw or PD94bWw means SVG (it’s XML, so it starts as readable text)

Learning those four prefixes has saved me more debugging time than I’d like to admit. When someone swears the API returns a JPEG and the string starts with iVBOR, the argument is over.

Decoding it

Paste the string into the box. You can give it the whole data:image/png;base64,... URI or just the payload after the comma; both work. If you copied it out of a stylesheet and dragged along the url("...") wrapper, that gets stripped too.

The preview appears with the format, the decoded file size, and the pixel dimensions. Then pick what to download: the original bytes, or a re-encode to PNG or JPG.

One detail about JPG that trips people up. JPEG has no alpha channel. If you convert a PNG logo with a transparent background straight to JPG, those transparent pixels have to become something, and the naive answer is black. The tool paints white underneath before encoding, which is what you usually want, but if you need real transparency, stay on PNG.

Why the format is sniffed, not trusted

The MIME type in a data URI is just a label somebody typed. It can be wrong, and in generated code it often is. So the decoder reads the actual file signature from the decoded bytes and reports what the file really is. A JPEG mislabelled as image/png still decodes and still previews correctly.

When Base64 images are a bad idea

Inlining images as data URIs feels tidy. Fewer HTTP requests, no separate asset to deploy. For a 400-byte icon, fine. Past a few kilobytes it starts costing you:

The 33% inflation is paid on every page load, and inline data URIs sit inside your HTML or CSS, so they can’t be cached separately from it
Browsers can’t lazy-load an image that’s already in the markup
Base64 compresses badly under gzip compared to the original binary
A 200 KB photo becomes a 267 KB string, and now your CSS file is 267 KB heavier for every visitor

Rough rule I stick to: under 2 KB, inline it. Over that, ship a real file.

Privacy

The string never leaves your browser. Decoding, format detection, preview, and re-encoding all run in JavaScript on your machine, which matters when the image is an internal diagram, a signed document, or a client’s unreleased artwork.

Got a string you can’t read? Paste it into the decoder and see what it is.