Image to Base64 Converter

Image to Base64 Converter at a glance

What it does: Convert an image to a Base64 data URI you can embed directly in HTML, CSS or JSON.
Where it runs: Entirely in your browser — no data is uploaded
Works offline: Yes, once the page has loaded
Cost: Free, with no account and no usage limit
Category: Converters

How to use the converter

Choose an image file - PNG, JPEG, SVG, WebP or GIF.
Copy the data URI, which already includes the data:image/...;base64, prefix.
Paste it into an <img src>, a CSS url(), or a JSON field.

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

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

When embedding is worth it

Every embedded image trades bandwidth for a saved request, and Base64 inflates the file by about 33%. That trade is good in a narrow set of cases.

Worth embedding:

Small icons and UI sprites under roughly 2-3 KB.
Images in an HTML email, where external images are blocked by default in most clients.
A single-file deliverable - a self-contained HTML report or an offline document.
An image that must be inside a JSON payload or a database text column.
A critical above-the-fold image where one fewer request measurably improves the largest contentful paint.

Not worth embedding:

Photographs. A 200 KB JPEG becomes 266 KB of text inside your HTML, downloaded on every page load.
Anything reused across pages, because an embedded image cannot be cached separately - it is re-downloaded with each document.
Anything that changes independently of the page.

The caching problem

This is the argument that decides most cases. A referenced image is cached by the browser and reused across every page that uses it. An embedded one is part of the document, so it is downloaded again on every page view and cannot be cached independently.

The original rationale for inlining was to avoid HTTP request overhead, which mattered a great deal under HTTP/1.1 with its six-connection limit. HTTP/2 and HTTP/3 multiplex requests over one connection, so the cost of an additional small file is now much lower. That has narrowed the case for data URIs considerably.

Data URIs in CSS carry an extra penalty: the stylesheet is render-blocking, so a large inlined image delays first paint for the whole page.

SVG deserves different treatment

SVG is text, so Base64-encoding it is wasteful - you inflate readable markup by a third for no reason. Two better options: paste the SVG markup directly into the HTML, which also lets CSS style its parts; or use a URL-encoded data URI in CSS, which is smaller than Base64 and still valid.

/* Better than Base64 for SVG */
background-image: url("data:image/svg+xml,%3Csvg xmlns='...'%3E...%3C/svg%3E");

Run the file through the SVG optimizer first to strip editor metadata, which often halves the size before you encode anything.

Reduce before you encode

Encoding does not compress - it makes the file a third larger. So any optimisation has to happen first. Resize the image to the dimensions it will actually be displayed at, convert to WebP where support allows, and lower JPEG quality to around 80, which is visually indistinguishable from 100 at a fraction of the size. The image converter does all three locally.

Frequently asked questions

About 33%, because three bytes become four characters. Add a little more for the data URI prefix. Encoding never makes a file smaller.

Browsers handle large data URIs, but performance degrades well before any hard limit. Keep embedded images under a few kilobytes; anything larger is better as a normal file.

No. The file is read with the browser's File API and encoded on your device. Nothing is transmitted, so unpublished images and screenshots containing private data stay local.

An embedded image cannot be indexed by image search, since it has no URL of its own. For decorative icons that is irrelevant; for content images you want discovered, use a normal file with a descriptive name and alt text.

In HTML email they are the reliable way to show an image without it being blocked, and most modern clients support them. Some older Outlook versions do not, so test if it matters.

Nothing you enter here leaves your browser

Image to Base64 Converter does its work in JavaScript running on your own device. The page loads once, and after that there is no upload step and no server involved — which matters here because exported data frequently contains customer records or transactions.

You can verify this rather than taking our word for it: load the page, disconnect from the internet, and the tool keeps working. Our privacy policy sets out what is and is not collected, and this guide explains why the distinction matters.