Base64 to Image Converter

Paste a Base64 string, preview the decoded image, and download it as a file. The conversion runs locally in your browser.

Runs in your browser No upload required Convert
Paste a data URL or raw Base64 image string. Decoding runs locally in this browser.

Decoded image preview appears here.

How to use Base64 to Image

  1. Paste a full data URL or raw Base64 image string into the input box.
  2. Choose a fallback MIME type if the string does not include a data URL prefix.
  3. Select Convert to preview the image locally.
  4. Use Download image to save the decoded result.

Why this tool exists

A Base64 to image converter is useful when an image has been embedded in JSON, CSS, HTML, email templates, API responses, or database fields. Instead of saving the encoded value into a text file and writing a small script, you can paste it here and inspect the image immediately. CleanWebTools accepts full data URLs such as data:image/png;base64,... and raw Base64 payloads when you know the expected image type.

This tool is designed for quick inspection, not for collecting your files. The decoding work happens in the browser with standard web APIs. The text you paste is converted into bytes on your device, turned into a Blob, and displayed with a local object URL. No server upload is required for the conversion itself. That matters when the image came from a private issue report, a test fixture, a signed document preview, or a customer support case.

Base64 is an encoding format, not encryption. Anyone who can read the string can decode the original content. If you are working with screenshots, ID documents, access tokens embedded in QR codes, or production customer files, treat the pasted value as sensitive. Use the preview only long enough to confirm the file type and content, then clear the field when you are done.

For SEO and workflow clarity, this page focuses on one task: turning Base64 into a visible image. If you need the reverse operation, use Image to Base64. If you need to decode ordinary text, a dedicated Base64 text decoder is a better fit.

Common examples

  • Input (raw Base64 with no prefix): iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAC0lEQVR42mP8z8BQDwAEhQGAhKmMIQAAAABJRU5ErkJggg== → a valid 1x1 PNG. To render it in HTML you must prepend the prefix yourself: <img src="data:image/png;base64,iVBOR...">. The leading iVBOR decodes to bytes 89 50 4E 47, confirming it really is PNG.
  • Common failure: pasting data:image/jpeg;base64,/9j/4AAQSkZJRg... into a strict decoder. The decoder chokes on the data:image/jpeg;base64, part because that text isn't valid Base64. Strip everything up to and including the first comma, leaving /9j/4AAQSkZJRg..., which decodes to bytes FF D8 FF — a real JPEG.
  • base64url fix: a JWT-style string aGVsbG8td29ybGQ_Zm9v contains _, which atob() rejects. Replace - with + and _ with /, giving aGVsbG8td29ybGQ/Zm9v, then decode normally.

FAQ

My Base64 throws 'InvalidCharacterError' but it came straight from a JWT — what's wrong?

You almost certainly have a base64url string, not standard Base64. JWTs, URL parameters, and filenames use the RFC 4648 section 5 alphabet, which swaps + for - and / for _ and usually drops the = padding. Standard decoders like the browser's atob() only know the +, /, = alphabet and reject - and _ outright. Translate every - back to + and every _ back to / (and re-pad to a multiple of 4) before decoding, and the same bytes will render fine.

Can I trust the image/png label in the data: prefix to know the real format?

No — that MIME type is a claim the encoder wrote, not a fact about the bytes. The true format lives in the magic number of the decoded data: PNG starts with 89 50 4E 47 0D 0A 1A 0A, JPEG with FF D8 FF, GIF with 47 49 46 38 (GIF8), and WebP with RIFF at offset 0 plus WEBP at offset 8. Browsers sniff these bytes, so a JPEG mislabeled image/png still displays — but if you save it as .png based on the label, strict viewers and file-type checks will reject it.

Why does my data: URL work in the browser but disappear after going through an email or CMS?

Server-side sanitizers are the usual culprit. Many HTML sanitizer implementations and parsers historically strip any data URI longer than 65519 characters (roughly 64 KB), so a Base64 image that renders perfectly in a live <img> tag silently vanishes once it passes through an email client, a sanitizing CMS, or a constrained DB text column. Anything bigger than ~48 KB of original binary (which inflates past the 64 KB text threshold) is at risk — host those as real files instead of inlining them.

By Alpha Loop · Last updated