Image to Base64 Converter

How to use 3 steps

Choose a picture under Select Image File.
Press Encode to Base64.
Press Copy Data URI and paste it into your HTML or CSS.

Select Image File:

Base64 Data URI String

How this tool works

The file is read and returned as a data URL — the string that begins with data:, names the file's type, and carries the whole image encoded in base64 after it. That prefix is part of what you get and part of what makes it usable: pasted into a stylesheet or an img tag it works as it stands, because the browser is told what it is looking at before the data begins.

Encoding this way makes the image about a third larger than the file it came from, which is the trade being made. In exchange the image needs no separate request: it travels inside the HTML, CSS or JSON that references it, and cannot arrive late or go missing.

When embedding is worth the size

Small and unchanging is the case for it: an icon, a bullet, a one-pixel gradient. Below a few kilobytes the saved request is usually worth the extra bytes.
Large images are worse embedded: a photograph inlined into a stylesheet makes that stylesheet render-blocking and uncacheable separately, so the page waits for an image it could have loaded alongside.
An embedded image cannot be cached on its own: it is re-downloaded with its host file every time that file changes, where a separate image would have stayed in the browser cache.
Email is the other common use: an inlined image cannot be blocked as a remote request, though several clients ignore data URLs entirely, so test before relying on it.

What you get back is a data URL

Not raw base64 — a complete data URL, beginning with data:, naming the file's type, and carrying the encoded image after it.

That prefix is part of what makes the output usable. Pasted into a stylesheet or an <img> tag it works as it stands, because the browser is told what it is looking at before the data begins. Strip it only if something is specifically asking for the base64 alone.

The [msm_tool slug="image-to-base64"] reads the file in your browser, so nothing is uploaded.

The size cost is about a third

Base64 turns every three bytes into four characters, so expect the encoded version to be roughly 33% larger than the file it came from. That is the trade being made, and whether it is worth it depends entirely on the size of the image.

In exchange, the image needs no separate request. It travels inside the HTML, CSS or JSON that references it, and it cannot arrive late, arrive out of order, or go missing.

Where embedding wins

Small, unchanging assets. An icon, a bullet, a one-pixel gradient, a spinner. Below a few kilobytes the saved request usually outweighs the extra bytes.
Assets that must not fail. A logo in an error page that renders when the rest of the site is down.
Single-file deliverables. An HTML email, a self-contained report, a document someone will save and open offline.

Where it loses, and badly

Large images. A photograph inlined into a stylesheet makes that stylesheet render-blocking — the page cannot paint until the whole thing arrives, including an image the browser would otherwise have loaded in parallel. A 200KB photograph becomes 270KB of CSS that everything waits for.

Anything cacheable. An embedded image cannot be cached on its own. It is re-downloaded with its host file every time that file changes, where a separate image would have stayed in the browser cache across deployments. Inline a logo into your main stylesheet and every CSS change re-sends the logo to everyone.

Anything reused. The same icon embedded in five places is five copies. Referenced as a file, it is one request and then cache.

Email is the awkward case

Inlined images cannot be blocked as remote content, which is genuinely useful — most clients block remote images by default and your carefully designed email arrives as boxes.

But several major clients, Gmail among them historically, refuse data URLs in HTML email outright. So the technique solves one problem and can create another. Test in the clients your audience actually uses before committing to it; for email, a hosted image with good alt text is often still the safer choice.

SVG is usually better inlined as itself

If the image is an SVG, embedding the markup directly is almost always better than base64-encoding it. It is smaller than the encoded version, it can be styled with CSS, and it compresses well because it is text.

Base64 an SVG only when it must sit in a CSS url() and you cannot use the markup directly — and even then, URL-encoding the SVG rather than base64-encoding it produces a smaller result.

A rough rule

Under about 4KB, embedding is usually worth it. Between 4KB and 10KB, it depends on how often the host file changes. Over 10KB, use a file.

Those numbers are not precise and they do not need to be — the cases at either end are obvious, and the middle rarely matters much either way.

Frequently Asked Questions

Specific to the Image to Base64 Converter. Broader questions about this category are answered on the category page.

Why does the output start with data: rather than the base64?

Because that prefix is what makes it usable. It tells the browser the type before the data begins. Remove it only if something is asking for raw base64 specifically.

Why is it bigger than my file?

Base64 turns every three bytes into four characters, so expect roughly a third more. That growth is the cost of embedding.

Should I inline my images?

Small, unchanging ones — icons and the like. Photographs are better as separate files that the browser can cache and fetch in parallel.

Does it work in email?

Sometimes. Inlined images cannot be blocked as remote content, but several email clients refuse data URLs outright. Test in the clients you care about.

Is my image uploaded?

No. It is read in your browser, so encoding something confidential here does not send it anywhere.