Base64 to image
Paste it however you found it — prefixed, wrapped, URL-safe, unpadded. We work out what it really is and hand you the file.
Line breaks, spaces and a missing data: prefix are all fine. URL-safe Base64 works too.
Paste it in whatever state you found it
Base64 rarely arrives clean. Copied out of a CSS file it has a data:image/png;base64, prefix on the front. Copied out of a JSON payload it may have none. Copied out of an email source it is wrapped at 76 characters with line breaks through the middle. Copied out of a JWT or a URL it is in the URL-safe alphabet, with - and _ where + and / should be, and often with the = padding stripped off.
All four cases are handled. Whitespace is removed, the URL-safe characters are translated back, padding is restored, and a data URI prefix is read and then set aside. You should not have to tidy a string up before a tool will look at it.
What it is, according to the bytes
The type is worked out from the first few bytes rather than from the label. PNG files start with a specific eight-byte signature, JPEG with FF D8 FF, GIF with GIF8, WebP with RIFF followed by WEBP four bytes later, PDF with %PDF. AVIF and HEIC are distinguished by the brand inside their ftyp box, which is the only thing separating two formats that otherwise look identical.
This matters more often than you would think, because the label in a data URI is written by whoever made it and is frequently wrong — image/jpeg on something that is actually a PNG is a classic, and it is why a file sometimes refuses to open in one program while working fine in another. When the declared type and the real one disagree, both are shown, and the download uses the real one.
Not only images
The most common thing behind a Base64 string is an image, which is why this page is named after them, but the second most common is a PDF — an invoice or a report returned by an API as a Base64 field. Those are recognised and downloaded with a .pdf extension. ZIP archives and plain text are recognised too, with text shown as a preview so you can see what you have without saving it first.
If nothing matches, the bytes are still decoded and still downloadable as .bin. An unrecognised format is not an error; it just means the file starts with something we do not have a signature for.
Two things worth knowing
Base64 is about a third larger than the file it encodes: three bytes become four characters. So a 400 KB string decodes to roughly 300 KB of file, and the size shown after decoding is the real one. This is also the reason to think twice before inlining large images in CSS — the page gets bigger, not smaller.
The preview is drawn by handing the decoded bytes to your browser as a blob, which means it can only show formats your browser can decode. On a recent Chrome or Firefox that covers PNG, JPEG, GIF, WebP and AVIF; HEIC generally only previews on Safari. When the preview fails, the decode did not — the file is intact and the download will work regardless.
Everything here happens in the page. The string is decoded by your browser's own Base64 routine, the signature check reads bytes in memory, and the download is assembled locally. Nothing is transmitted, which is the point when the thing you are decoding is somebody's scanned passport or a signed contract.
Common questions
Do I need the data:image/png;base64, part?
No. Paste the string with the prefix or without it. If the prefix is there we read the declared type from it and tell you whether the bytes agree; if it is not, the type is worked out from the bytes alone.
My Base64 has line breaks in it. Is that a problem?
No. Line breaks, spaces and tabs are stripped before decoding. Base64 from email source or from a PEM-style block is wrapped at 64 or 76 characters and works here unchanged.
What about URL-safe Base64 from a JWT or a query string?
Handled. The - and _ characters are translated back to + and /, and missing = padding is added. That is what makes a JWT payload decode here rather than failing.
It says PNG but the data URI says JPEG. Which is right?
The bytes. The label in a data URI is written by whatever produced it and is often wrong. The downloaded file uses the type the bytes indicate, which is why it then opens correctly.
Can it decode a PDF?
Yes. A Base64 PDF is recognised from its %PDF header and downloads with the right extension. ZIP archives and plain text are recognised as well.
Why can I not see a preview of my HEIC?
Because most browsers outside Safari cannot decode HEIC. The decode still succeeded — the file is intact and the download works. Convert it with the HEIC to JPG tool if you need to look at it.
Is anything uploaded?
No. Decoding uses the routine already in your browser and the file is assembled in memory. That is the whole reason to use a page like this for a scanned document rather than a server-side converter.