Base64 to Image Converter
This free base64 to image converter decodes a Base64 string or data URI back into a real picture. Paste the code — with or without the data:image/png;base64, prefix — and get an instant preview with the image’s dimensions and MIME type. Download the result in its original format, or convert it to PNG, JPEG, or WebP on the way out. It runs entirely in your browser: nothing is uploaded, and your data never leaves your device.
Decode data URIs from CSS, HTML, or APIs back into a normal image file. Pair with Image to Base64 to round-trip inline assets.
How to use the base64 to image converter
- Paste your Base64 code. Drop a full data URI (starting with
data:image/…;base64,) or just the raw Base64 characters into the box. Stray whitespace and line breaks are stripped automatically, and a raw string without a prefix gets adata:image/png;base64,header added for you — thanks to browser content sniffing, that works even when the underlying image is actually a JPEG or GIF. - Click “Decode & preview”. Or press
Ctrl+Enter(Cmd+Enteron a Mac) straight from the text box. If the string can’t be decoded, you’ll see a clear error instead of a blank result. - Check the preview and metadata. The decoded picture appears immediately, along with its pixel dimensions and detected MIME type — for example
512 × 512 · image/png— so you can confirm it’s the asset you expected before saving anything. - Choose a download format. Keep the original format to save the exact decoded bytes, or convert to PNG, JPEG, or WebP as you export. JPEG conversions are written at 92% quality, a sensible balance of sharpness and file size.
- Download the image. The file saves with the right extension for its format (
.png,.jpg,.webp,.gif, or.svg). Hit Clear to reset and decode the next string.
Because decoding happens with the browser’s own image engine, the tool handles any image type your browser can render — PNG, JPEG, GIF, WebP, SVG, and modern formats like AVIF in browsers that support them.
What Base64 encoding is and why it exists
Base64 is a way of writing binary data using only 64 safe text characters: the letters A–Z and a–z, the digits 0–9, plus + and /, with = used as end padding. The encoder takes every 3 bytes of the original file and rewrites them as 4 characters, each carrying 6 bits of data. That lets raw image bytes — which include control characters and values that would break a text file — travel safely inside HTML, CSS, JSON, XML, or an email body.
The trade-off is size. Because 3 bytes become 4 characters, Base64 output is about 33% larger than the original binary. A 90 KB photo becomes roughly 120 KB of text. Transport compression such as gzip or Brotli claws back only part of that, because image data is already compressed and Base64 scrambles the byte patterns compressors look for. This overhead is the single most important fact when deciding whether to embed images as Base64 at all — more on that below.
You’ll meet Base64-encoded images everywhere in design and development work: inline images in CSS and HTML, icons stored in JSON configuration files, images returned by APIs and AI image generators, email templates, and the clipboard output of countless design tools. This converter is for the moment you have the text and need the actual picture back.
Anatomy of a data URI
Most Base64 images you’ll encounter are wrapped in a data URI, a scheme defined in RFC 2397 that lets a URL carry its own content instead of pointing to a server. A typical example looks like this:
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA…
It has four parts: the data: scheme, the MIME type (image/png), the ;base64 flag telling the browser how the payload is encoded, and then — after the comma — the Base64 data itself. Everything before the comma is metadata; everything after it is the image. That’s why this tool accepts both forms: if you paste a full data URI it reads the declared MIME type from the prefix, and if you paste only the part after the comma it supplies a prefix for you.
A useful detail: browsers don’t blindly trust the declared MIME type. Under the WHATWG MIME Sniffing rules, an image’s real format is detected from its first bytes — its magic numbers — so a JPEG labelled image/png in the prefix will still render in an <img> tag. The preview’s MIME readout reports the type from the prefix, and the first characters of the Base64 itself tell you the true format at a glance, because magic bytes encode to recognizable strings:
| Format | Data-URI prefix | Base64 starts with |
|---|---|---|
| PNG | data:image/png;base64, |
iVBORw0KGgo |
| JPEG | data:image/jpeg;base64, |
/9j/ |
| GIF | data:image/gif;base64, |
R0lGOD |
| WebP | data:image/webp;base64, |
UklGR |
| SVG | data:image/svg+xml;base64, |
PHN2Z or PD94bWwg |
| ICO (favicon) | data:image/x-icon;base64, |
AAABAA |
If a string claims to be image/png but begins with /9j/, it’s really a JPEG — knowing these signatures is the fastest way to diagnose a mislabelled asset. The same trick works in reverse when you’re hunting through a stylesheet or an API response: scan for iVBORw0KGgo and you’ve found every inlined PNG in the file.
How to spot and fix a broken Base64 string
When a paste fails to decode, the string itself almost always tells you why. Work through these in order:
- It was truncated. The most common failure. Consoles, log viewers, and chat apps routinely clip long values, and image strings run to tens of thousands of characters. A valid Base64 payload has a length that’s a multiple of 4 (counting the
=padding); if yours ends mid-word with no padding and the source showed an ellipsis, go back and copy the full value. - It went through a URL. Form and query-string encoding turns
+into a space and percent-encodes/and=as%2Fand%3D. If you see spaces or%sequences inside the payload, URL-decode it first (or replace the spaces back with+). - It’s URL-safe Base64. Some APIs emit the RFC 4648 URL-safe alphabet, which swaps
+for-and/for_. Browsers expect the standard alphabet in data URIs, so convert-back to+and_back to/. - Wrapper characters came along for the ride. Copying out of CSS often brings
url("…"), quotes, or a trailing);with it; copying out of JSON brings the surrounding"marks. Strip everything so the paste starts withdata:or with the Base64 itself. - It’s double-encoded. If decoding “succeeds” somewhere else but yields more Base64-looking text instead of binary, the value was encoded twice — decode the output again.
- It isn’t an image. Base64 encodes any binary, so the string may be a PDF (
JVBERi0), a ZIP (UEsDB), or a font. Check the opening characters against the table above; if they match none of the image signatures, no image converter will render it.
Line breaks are the one thing you never need to fix here: MIME email encodes Base64 in 76-character lines, and this tool strips all whitespace before decoding.
When Base64 embedding makes sense — and when it hurts
Encoding images as Base64 and inlining them is a legitimate technique with a narrow sweet spot. It makes sense for tiny, frequently repeated assets: a hamburger icon in a stylesheet, a small logo in an email signature, a placeholder blur in an HTML payload, or an image inside a self-contained document like a single-file report or an SVG. In each case you save an HTTP request and guarantee the image travels with its document — nothing can 404.
Beyond that sweet spot the costs stack up quickly. The ~33% size penalty applies to every visitor on every load. Inlined images can’t be cached independently — change one character of your CSS and the browser re-downloads every embedded image with it, whereas a normal image URL sits in cache for months. Big Base64 blobs also bloat the HTML or CSS that must be parsed before anything renders, delaying first paint, and they block the browser’s usual optimizations like lazy loading, responsive srcset selection, and prioritized image fetching. Since HTTP/2 and HTTP/3 made extra requests cheap by multiplexing them over one connection, the old “save a round trip” argument has largely evaporated for anything but the smallest files.
Two practical caveats worth knowing: a strict Content-Security-Policy must include data: in its img-src directive or embedded images silently fail to render, and email client support for data-URI images is notoriously inconsistent — several major clients block or strip them. A good rule of thumb: embed images under a couple of kilobytes, link everything else. And when you inherit a project that got this wrong, decoding the blobs back into real files with this tool is the first step to cleaning it up.
How to decode Base64 to an image in JavaScript, Python, and the terminal
A visual converter is the fastest route for a one-off string, but when decoding happens inside a build script, a backend, or a batch job, you want a one-liner. Every mainstream environment ships one:
| Environment | One-liner | Worth knowing |
|---|---|---|
| Browser JS | fetch(dataURI).then(r => r.blob()) |
Accepts a full data URI directly; for raw bytes use Uint8Array.from(atob(s), c => c.charCodeAt(0)) |
| Node.js | fs.writeFileSync('img.png', Buffer.from(s, 'base64')) |
Buffer.from is lenient — it skips whitespace and stray characters |
| Python | open('img.png','wb').write(base64.b64decode(s)) |
Must be binary mode 'wb'; bad input raises binascii.Error |
| Linux / macOS shell | base64 -d encoded.txt > img.png |
Older macOS versions use a capital -D instead of -d |
| PowerShell | [IO.File]::WriteAllBytes('img.png', [Convert]::FromBase64String($s)) |
Strict about padding — the length must be a multiple of 4 |
The mistake behind most failed decodes is feeding the whole data URI into a Base64 decoder. Except for the browser’s fetch(), every function above expects only the payload after the comma — the data:image/png;base64, prefix contains characters outside the Base64 alphabet, so atob() throws InvalidCharacterError and Python complains about invalid input. Split on the first comma first: s.split(',')[1] in JavaScript, s.split(',', 1)-style logic elsewhere. The other classic is writing the output in text mode, which corrupts the bytes on Windows — always write binary.
Base64 is not encryption: safety checks before you use a decoded image
Base64 looks scrambled, but it’s an encoding, not encryption — there’s no key, and anyone can reverse it instantly. Never rely on it to protect a sensitive image, and conversely, treat any Base64 from an untrusted source as exactly as suspicious as an unknown file attachment, because encoding is a favorite way to slip payloads past naive content filters.
Decoding itself is inert — it just produces bytes — but what you do with them next matters. The main image-format risk is SVG: unlike PNG or JPEG, an SVG is an XML document that can contain <script> elements and event handlers, which is why stored-XSS-via-SVG-upload is a recurring vulnerability class. Browsers do not run scripts inside an SVG shown through an <img> element, but opening the same file directly in a tab or inlining its markup into a page will execute them. So before dropping a decoded SVG into production HTML, open it in a text editor and check for <script>, on*= attributes, and foreignObject — or rasterize it to PNG so the scripting surface disappears entirely.
Two quicker checks apply to any format. First, compare the declared MIME type against the magic-byte signature at the start of the Base64 (see the table above) — a mismatch means someone or something mislabelled the file, occasionally deliberately, as in polyglot files crafted to parse as two formats at once. Second, decode privately: a client-side tool never transmits the string, which matters when the payload came from a customer database or an internal API you’re not free to paste into an uploading service.
Frequently asked questions
Is this free and private?
Yes on both counts. The base64 to image converter is completely free, with no sign-up, watermarks, or usage limits. It’s also fully private: decoding, previewing, and format conversion all happen in your browser on your own device. The Base64 you paste is never uploaded, transmitted, or stored on any server — which matters when the string comes from a client project, an internal API, or anything else confidential.
What image formats can it decode?
Anything your browser can display — which in practice covers PNG, JPEG, GIF, WebP, SVG, and, in current browsers, AVIF. Decoding uses the browser’s native image engine rather than a fixed format list, so support tracks your browser exactly. Downloads are saved with the correct extension for PNG, JPEG, WebP, GIF, and SVG sources.
Can I convert the image to a different format while downloading?
Yes. After decoding, the “Download as” menu offers the original format plus PNG, JPEG, and WebP. Choosing the original saves the exact decoded bytes untouched; choosing another format redraws the image and re-encodes it, with JPEG written at 92% quality. Note that conversion rasterizes the picture — an animated GIF is flattened to its first frame and an SVG loses its vector scalability — so keep “original format” when you want the asset exactly as it was encoded.
Do I need the data:image prefix, or is raw Base64 enough?
Raw Base64 is enough. If your string doesn’t start with data:, the tool prepends a data:image/png;base64, header automatically, and because browsers identify images by their actual leading bytes rather than the declared type, JPEGs, GIFs, and WebP files pasted without a prefix still decode and preview correctly.
Is there a size limit on the Base64 I can paste?
No limit is imposed by the tool itself. Modern browsers handle multi-megabyte data URIs comfortably, so photos and full-resolution artwork decode fine — the practical ceiling is your device’s memory. Very long strings may take a moment to paste and render, which is normal; remember that the Base64 text is about a third larger than the image it contains, so a 4 MB paste yields roughly a 3 MB file.
Why does my string show a decode error?
Nine times out of ten the string is incomplete — image Base64 is long, and whatever you copied it from clipped the end. Otherwise check for URL-encoding damage (spaces where + should be, %2F sequences), URL-safe alphabet characters (- and _), leftover quotes or url() wrappers, or a payload that isn’t an image at all. The troubleshooting checklist above walks through each case with the telltale signs.
Is Base64 an image format?
No. Base64 is a text encoding, not an image format — a container of characters that can hold any binary data. The image inside is still a PNG, JPEG, GIF, WebP, or SVG, and it keeps that format through the round trip. That’s why a decoder needs to detect the real type from the data: “Base64” tells you how the bytes are written down, not what kind of picture they make.
Can I view a Base64 image without a converter?
Not as easily as you’d hope. Pasting a data:image/… URI into the address bar used to work, but modern browsers block top-level navigation to data: URLs because phishing pages abused the trick. You can still set it as an <img src> in a local HTML file or via the DevTools console — but at that point a paste-and-preview tool that also reports dimensions and MIME type, and gives you a downloadable file, is the shorter path.
Why did the API give me Base64 instead of an image file?
Because JSON can’t carry raw binary. Any API that returns images inside a JSON response has to encode them as text, and Base64 is the standard way — AI image generators are a common example, with OpenAI’s Images API returning pictures in a b64_json field when you request them inline. Copy that field’s value (without the surrounding quotes), decode it, and you have the actual file.
Does converting Base64 back to an image lose quality?
No. Decoding is an exact, lossless reversal — the output is byte-for-byte identical to the file that was originally encoded, so nothing is recompressed, resized, or degraded. Quality only changes if you then re-encode into a lossy format, for example downloading a PNG as a JPEG, which redraws and recompresses the pixels. To keep the asset untouched, download in its original format.
Related design tools
- Image to Base64 — the exact reverse of this tool: encode any image into a Base64 data URI ready for CSS, HTML, or JSON.
- Image Converter — convert decoded images between PNG, JPEG, WebP, and other formats.
- Image Compressor — shrink an image’s file size before you embed or ship it.
- Favicon Generator — turn a logo into a complete favicon set, a common source of Base64-encoded
ICOfiles. - EXIF Stripper — remove camera and location metadata from photos before sharing.