Base64 Image Converter

Convert an image to a Base64 data URI, or paste a Base64 string back into a downloadable image — everything runs locally, nothing is uploaded.

242 views

How It Works

This tool works in two directions. In Image → Base64 mode, pick a file with the browser's native file picker; the tool reads it with the FileReader.readAsDataURL() API and produces a full data URI — a string like data:image/png;base64,iVBORw0KG... — shown in one box, with the raw Base64 payload alone (no prefix) shown in a second box so you can grab whichever form your use case needs, plus a one-click copy button for each. In Base64 → Image mode, paste either a full data URI or just the bare Base64 text into the textarea; if you paste bare Base64 without a prefix, the tool automatically adds a data:image/png;base64, header so the browser can still render it, then shows a live <img> preview with a download button that saves the decoded bytes back out as an actual image file.

Base64 encoding takes binary data and represents it using only 64 printable ASCII characters (A–Z, a–z, 0–9, + and /), which is what lets an inherently binary image be embedded inside text-only formats like HTML, CSS, JSON or a URL. The mechanism is fixed and mathematical: every 3 bytes (24 bits) of the original file become exactly 4 Base64 characters (4 × 6 bits), padded with = when the input length isn't a multiple of 3. That 3-bytes-in, 4-characters-out ratio is also why Base64 output is always roughly 33% larger than the original binary — 4 divided by 3 is about 1.333 — a fixed mathematical overhead, not an approximation or a quality setting.

Good to Know

Embedding an image as a data URI directly in your HTML or CSS has a genuine advantage: it eliminates a separate HTTP request, which matters for very small, frequently-reused assets like icons, small sprites, or a tiny logo baked into an email template where external images might be blocked. The trade-off runs the other way for anything larger: a data URI cannot be cached independently by the browser the way a linked .png or .jpg file can, it inflates the size of whatever HTML/CSS file contains it (by that same ~33%), and it blocks that file from rendering until the entire encoded blob has downloaded. As a rule of thumb, data URIs are a good fit for assets under a few kilobytes and a poor fit for photos, hero images, or anything a user might want cached across page loads.

The MIME type prefix — the image/png, image/jpeg, or image/webp part of data:image/png;base64,... — is not decorative. It is what tells the browser (or any other program reading the string) which decoder to hand the following bytes to; without it, or with the wrong one, an otherwise valid Base64 payload can fail to render or render as the wrong file type entirely. That is exactly why this tool auto-adds a PNG prefix when you paste bare Base64 with none supplied — a reasonable default, though you should switch it to match the original file's actual format if you know it was a JPEG or WebP.

Frequently Asked Questions

Why is the Base64 output always bigger than the original image?

Base64 encodes every 3 bytes of binary input as 4 text characters, so the output is always about 4/3 the size of the input — roughly 33% larger. This is a fixed mathematical property of the encoding (6 bits of information per printable character instead of 8), not something caused by low-quality settings or an inefficient tool.

Is my image uploaded to a server to convert it?

No. Both directions run entirely in your browser: FileReader.readAsDataURL() reads the file locally, and decoding back to an image happens locally too. Nothing is transmitted anywhere.

When should I actually use a Base64 data URI instead of a normal image file?

It makes sense for small, frequently-reused assets — icons, tiny UI sprites, a logo in an HTML email — where saving one extra HTTP request outweighs the ~33% size increase. It is a poor fit for photos or any image you want the browser to cache independently across pages, since an inline data URI is re-downloaded every time the containing HTML or CSS file loads.

I pasted a Base64 string but nothing shows up in the preview — why?

Two common causes: the string is missing (or has an incorrect) MIME type prefix — this tool auto-adds data:image/png;base64, if none is present, which only helps if the underlying bytes are actually PNG data — or the Base64 text itself got truncated or corrupted (for example, by whitespace/line breaks inserted when copying from certain sources). Double-check the prefix matches the real format and that you copied the complete string.

What is the difference between the "full data URI" and the "Base64 only" output boxes?

The full data URI (starting with data:image/...;base64,) is what you paste directly into an HTML src attribute or a CSS url() so the browser renders it immediately. The Base64-only box strips that prefix, which is what you want when a program, API, or config file expects just the raw encoded payload and will attach its own type information separately.

Comments

No comments yet — be the first to write one!

Similar Tools