How to Convert an Image to a Base64 Data URI (and When You Actually Should)

Every extra image on a page is another HTTP request, another round trip, another thing that can 404. For tiny assets — an icon, a 1×1 tracking pixel, an SVG background — that overhead can cost more than the bytes themselves. The fix is to inline the image directly into your CSS, HTML, or JSON as a Base64 data URI, so it ships inside the file that references it.

What a data URI actually is

A data URI packs a file's bytes straight into a URL. The shape is data:[mediatype];base64,[data]. Base64 is a way of writing arbitrary binary bytes using only 64 safe ASCII characters (A–Z, a–z, 0–9, +, /), so it survives contexts that expect text — like a CSS file or a JSON string — without corruption.

The tradeoff is size. Base64 encodes 3 bytes into 4 characters, so the text is roughly 33% larger than the original binary. A 1 KB PNG becomes about 1,336 characters. That's fine for small assets and terrible for a hero photo.

Encoding an image in the browser

Drop an image into the Image to Base64 tool and it reads the file locally with a FileReader and returns the full data URI — nothing is uploaded. That's exactly what this JavaScript does under the hood:

const input = document.querySelector('input[type=file]');
input.addEventListener('change', () => {
  const reader = new FileReader();
  reader.onload = () => {
    // reader.result is already a full data URI:
    // "data:image/png;base64,iVBORw0KGgo..."
    console.log(reader.result);
  };
  reader.readAsDataURL(input.files[0]);
});

Using the result

Once you have the string, paste it wherever a URL is expected. In HTML:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA..." alt="logo">

In CSS, as a background — handy for icons that never change:

.icon-check {
  background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxu...");
  background-repeat: no-repeat;
}

Or embedded in a JSON payload, where a data URI is just a plain string value:

{
  "avatar": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQ..."
}

When inlining is worth it

• Small, static assets — icons, favicons, tiny textures under a few KB.
• Single-file deliverables — an HTML email or a self-contained report that must render with zero external requests.
• Critical above-the-fold graphics — inlining removes a render-blocking request.
• SVGs — vectors stay crisp and often compress well; for SVG you can even skip Base64 and use data:image/svg+xml;utf8, with URL-encoded markup.

Common pitfalls

Base64 is not compression and not encryption. It makes files bigger and is trivially reversible.

• Don't inline large images. A 200 KB photo becomes ~270 KB of text that can't be cached separately and blocks the parser while it downloads with the document.
• Caching changes. An external image is cached once and reused across pages; an inlined one is re-downloaded with every page that embeds it.
• Get the media type right. A JPEG labeled image/png may fail to render. Match the real format — image/png, image/jpeg, image/webp, image/svg+xml.
• Watch your build tools. Long data URIs can bloat CSS bundles and hurt gzip ratios if overused.

Going the other way

If you already have a data URI and need the picture back — say from a config file or an API response — the Base64 to Image tool decodes and previews it. And if you're hand-encoding text rather than images, the general-purpose Base64 Encode / Decode tool covers plain strings.

Conclusion

Base64 data URIs are a precise tool: excellent for shaving requests off small, static assets and building self-contained files, wasteful for anything large. Encode the image locally, confirm the media type, paste the string where a URL belongs, and reserve the technique for cases where removing a network request genuinely pays for the ~33% size penalty.