Paste a base64 string or a data URI and decode it back into a PNG, JPG, WebP or SVG file you can preview and download — all in your browser, with nothing uploaded.
A data: prefix is optional. Without one the format is read from the decoded bytes rather than from a label.
The download is the original binary image file, not text
One field, three ways to fill it — and all three accept the same range of strings.
A base64 string reaches you in whatever shape the tool that produced it happened to use. It may be a bare payload from an API response, a full data:image/png;base64,… URI from a stylesheet, a quoted string copied out of a log line, or the URL-safe variant from a token. This decoder normalises all of them before it looks at a single byte, so the format of the string is never something you have to clean up by hand.
The button reads the clipboard directly. Useful when the string is longer than you want to scroll through, and when the source is an application that copies without letting you select.
Press Ctrl+V (Cmd+V on macOS) with the page focused — you do not have to click into the field first. Pasting is the gesture this tool is built around, so it works from wherever the cursor happens to be.
Editing happens live: the image appears and updates as the string changes. That makes the field usable for trimming a truncated paste down to the last valid character and watching it turn back into a picture.
What counts as a valid string. Line breaks and spaces are ignored, so a wrapped payload works as-is. The URL-safe alphabet (- and _) is translated. Missing = padding is restored. Surrounding quotes, url(…) wrappers and any data: prefix are stripped. Only characters that are genuinely not base64 survive to be reported as an error.
Decoding is one function call. Knowing what the bytes are is the part that separates a working tool from a plausible one.
A raw base64 string carries no type information whatsoever. It is just a number in base 64 — nothing in it says “PNG” or “JPEG”. The only hint is the data: prefix, and that is a label written by whatever produced the string, not a fact about the bytes. Labels get carried over from renamed files, pasted between formats, and hard-coded by some exporter that never actually checked.
So this converter reads the bytes. It matches the first few bytes against the known signatures of every format it supports, and it treats the prefix as a claim to be cross-checked rather than a source of truth. When the two disagree, you are told which one won — because a file that arrived mislabelled is worth knowing about before you save it under the wrong extension.
| Check | What it catches |
|---|---|
| Alphabet | Characters that base64 cannot contain — the quote or line number that came along when the string was copied out of source code. |
| Length | The character count is compared against the ceiling before anything is decoded, so an oversized paste is refused rather than allocated. |
| Arithmetic | Base64 encodes 3 bytes into 4 characters, so a length of 4n + 1 cannot exist. That remainder means the string was cut, and it is reported as truncation rather than as a decoding failure. |
| Signature | The decoded bytes are matched against the format signatures. If nothing matches, the string decoded but is not an image, and the tool says so instead of saving a file with a misleading extension. |
| Content type | A data: prefix that contradicts the signature is surfaced as a warning, and the bytes win. |
“Online” means no install and no sign-up. It does not mean your string takes a trip through someone else’s server.
Plenty of converters post your string to a backend, decode it there, and stream the image back. This one does the whole thing in page memory: the string is parsed, decoded and turned into a blob without a single network request carrying it. That matters more here than in the other direction, because base64 strings are frequently the exact thing you were trying not to put on the wire — an inline image from a private document, a payload out of an internal API response, a screenshot someone sent you in confidence.
It is not a claim you have to take on faith. Open your browser’s developer tools, switch to the Network tab, and decode something. Nothing carrying the string or the resulting image leaves the page.
Decoding speed is bounded by your own CPU. There is no per-day limit, because there is no server counting requests and nothing to rate-limit.
DevTools, Network tab, decode a string. The only requests you will see are the ones that loaded this page in the first place.
The decoded output is a real binary file, not a text rendering of one. That distinction is where most of the work is.
Decoding reverses the encoding exactly: every 4 characters become 3 bytes, the padding is dropped, and what is left is byte-for-byte the file that was encoded. Round-tripping an image through this tool and back through the other one returns the original bytes, which is why the download button produces something your operating system recognises rather than a file that only looks right.
The text form is always larger than the file it carries. Base64 spends 4 characters per 3 bytes, so roughly a quarter of the string is overhead — the “smaller than the text” figure on the result panel is that ratio, measured against the string you actually pasted rather than an estimate.
| Figure | How it is obtained |
|---|---|
| Decoded size | The real byte length of the decoded buffer — the size the saved file will be, not an estimate derived from the string length. |
| Smaller than the text | The ratio between the decoded bytes and the normalised payload, so whitespace you pasted in does not distort it. |
| Pixels | Read from the decoded image itself. Shown as a dash when the format is valid but carries no intrinsic size — an SVG without width and height, for instance. |
| Detected | The format as measured from the bytes, with the prefix’s claim shown next to it whenever the two disagree. |
Any format with a recognisable signature, identified from the decoded bytes rather than from a label.
| Format | Signature, and what it means for you |
|---|---|
| PNG | Matched on the full eight-byte signature. Lossless with transparency, and the format most screenshot tools emit. |
| JPG / JPEG | Matched on the FF D8 FF marker rather than a bare FF D8, which is too generic to be evidence of anything. |
| GIF | Both GIF87a and GIF89a. Only the first frame is shown in the preview; the download carries the whole animation. |
| WebP | Matched through the RIFF container header. |
| SVG | Markup, not pixels, so it is recognised from its text rather than from a byte signature. |
| BMP / ICO | Matched on their leading bytes. ICO is the one format here whose signature starts with a run of zero bytes. |
| AVIF | Read out of the ISO base media container, where the brand is checked rather than assumed — the same container also carries HEIC, which browsers still cannot render. |
SVG is never inlined into this page. A decoded SVG is previewed through an <img> element, which loads it in a context where scripts do not run. Rendering SVG markup directly into the document is how a decoder becomes an XSS vector, and it is a mistake a lot of converters make.
.png that will not open.Paste the base64 string into the field above, with or without a data: URI prefix. The converter validates it, reads the real format from the first bytes of the decoded data, and renders the image — then Download saves it as a file.
Yes. A raw base64 string carries no type information at all, so the format is detected from the decoded bytes themselves, using the same magic-byte check the encoder relies on. If a prefix is present it is treated as a hint only: when it disagrees with the bytes, the bytes win and the page tells you the prefix was wrong.
Three causes account for nearly all of it: the string was truncated when it was copied, it contains characters outside the base64 alphabet (a stray quote or a line number that came along with it), or it is not base64 at all. The tool names which of the three it found rather than returning a generic error.
Yes. Whitespace and line breaks are ignored, so a string wrapped by an email client or an editor still decodes. The URL-safe alphabet using - and _ is accepted alongside the standard + and /, and missing = padding is restored before decoding.
PNG, JPG, GIF, WebP, BMP, ICO, SVG and AVIF, up to 10 MB of decoded data. The format is identified from the bytes, so a string labelled PNG that actually contains a JPEG decodes as a JPEG. SVG is returned as its original markup and previewed as an image — never injected into the page as markup.
No. Decoding happens in browser memory and the string is never transmitted. You can confirm it in your browser's network panel — the only request is for the page itself.