Decode Base64 back to an image
Paste a Base64 string or data URI and get an instant preview plus a downloadable PNG, JPG, GIF, WebP or SVG. Type detected from the bytes.
- Runs in your browser
- Nothing you enter is sent
- Free, no account
Nothing decoded yet. Paste a value above and the preview, detected type and download appear here.
Decoding a Base64 image
Paste the string into the panel above. It can be raw Base64, a complete
data:image/png;base64,… URI, a URL-safe variant with - and
_, or a value that arrived with line breaks in it. All of those are normalised
before decoding, so you rarely need to clean anything up first.
The type is read from the bytes, not the label
A data: URI declares its own MIME type, and that declaration is frequently wrong —
a JPEG saved with a .png extension, a header copied from a different example, a
generic application/octet-stream from an API that never looked. This decoder
checks the file signature instead:
| Format | First bytes (hex) | How the Base64 usually starts |
|---|---|---|
| PNG | 89 50 4E 47 | iVBORw0KGgo |
| JPEG | FF D8 FF | /9j/ |
| GIF | 47 49 46 38 | R0lGODlh |
| WebP | 52 49 46 46 … 57 45 | UklGR |
| SVG | <svg or <?xml | PHN2Zy or PD94bWw |
| ICO | 00 00 01 00 | AAABAA |
Those leading characters are a genuinely useful diagnostic: you can identify a Base64 blob at a glance in a log file without decoding it at all.
Why a paste sometimes fails
- Truncated copy. Base64 must be a multiple of four characters after padding. A selection that stopped short loses the tail bytes and the image will not parse.
- Percent-encoded on the way out. If the string is full of
%2Fand%2Bit was URL-encoded after being Base64-encoded. Decode that layer first. - Double encoding. If the decoded bytes look like more Base64, the value was encoded twice — decode again.
- It was never an image. A PDF, a ZIP or a font decodes cleanly and simply has nothing to preview. The download still gives you the correct file with the right extension.
Where these strings come from
Most people arrive here with a value pulled out of somewhere it was never meant to be read by a
human: a database column, an API response, a Chrome DevTools copy of an
<img> element, a webhook payload, a CSS file inherited from another team, or
a canvas export from an application that only offers toDataURL(). Getting a real
file back out is usually the fastest way to find out what you are actually dealing with.
Saving the result
The download is built as a Blob in this tab and handed straight to the browser's
download manager. There is no request and no temporary file on anyone's server — which is the
point when the string you pasted came out of a production database.
Questions
My string starts with data:image/png;base64 — do I strip that?
No need. Paste the whole thing. The prefix is parsed, and the real file type is then confirmed against the decoded bytes rather than trusted from the header.
It says the type is not what the data URI claims. Which is right?
The bytes. A data URI header is just a label anyone can mistype; we check the file signature — 89 50 4E 47 for PNG, FF D8 FF for JPEG, RIFF…WEBP for WebP — and name the file accordingly.
Nothing previews and the download is a .bin file.
The decoded bytes are not a recognised image. The usual causes are a truncated copy-paste, a string that was URL-encoded on the way out, or a value that was never an image in the first place.
Does it handle URL-safe Base64?
Yes. Hyphen and underscore are mapped back to plus and slash, padding is added when missing, and whitespace and line breaks are ignored, so a value copied out of a JWT or a log line works as-is.