Image to Base64
Encode an image as a Base64 data URI you can paste straight into CSS, HTML or Markdown. The tool also tells you when inlining is a bad idea, which is more often than most converters admit.
Related tools
How to convert an image to Base64
- Drop your image in. It is read on your device — nothing is uploaded.
- Check the size figures. The tool shows the original, the encoded size and the overhead.
- Pick an output format — a plain data URI, the raw Base64, or a ready-made CSS, HTML or Markdown snippet.
- Copy the result and paste it where you need it.
What a data URI actually is
A data URI puts a file's contents inside the URL itself, instead of pointing at a file on a server. The shape is always the same:
data:image/png;base64,iVBORw0KGgoAAAANSUhEUg…
Four parts: the data: scheme, the media type (image/png), the encoding (base64), and then the file, encoded.
Because it is still a URL, it works nearly everywhere a URL does — the src of an <img>, a CSS background-image, a Markdown image link, an SVG <image> element. The browser decodes it in place. There is no second request, no separate file, nothing to 404.
That last property is the entire appeal, and also the entire problem.
The size question, which most converters skip
Base64 expands data by about a third. Every three bytes become four characters, because 64 printable characters can only carry six bits each. It is not an implementation detail that a better tool could avoid.
So a 4 KB icon becomes roughly 5.4 KB of text. A 200 KB photo becomes roughly 270 KB.
Whether that trade is worth it depends entirely on size:
Under about 10 KB, inlining usually wins. You save an HTTP request. On a connection with meaningful latency, a round trip can cost more time than the extra bytes, and the image cannot arrive late or fail to arrive at all.
Above it, inlining loses, often badly. Three reasons, and they compound:
Caching disappears. A normal image is downloaded once and reused on every page. An inlined one is part of the HTML or CSS, so it is re-downloaded every time that document is, on every page, for every visitor.
It blocks. A data URI inside a stylesheet makes that stylesheet bigger, and stylesheets block rendering. You have moved bytes from a resource that loads in parallel into one that holds the page up.
Compression does not save you. Gzip and Brotli work by finding repetition, and Base64 of an already-compressed PNG or JPEG has very little. Most of the 33% survives the wire.
The warning this tool shows above 10 KB is not boilerplate. It is the answer to the question most people should have asked before converting.
Where inlining genuinely helps
Icons in critical CSS. A 1 KB chevron or checkmark inlined into the stylesheet that is already blocking render costs almost nothing and removes a request.
A single-file deliverable. An HTML report, an email template preview, a self-contained demo — anything that has to work when handed over as one file with no folder of assets beside it.
Placeholder images. A tiny blurred version of a photograph, inlined, shows something immediately while the real image loads. This is what the LQIP technique does, and the placeholder is deliberately kept to a few hundred bytes.
Avoiding a flash. An image that must be present at first paint — a logo in a header that would otherwise pop in a moment later.
Environments with no asset hosting. Some CMS fields, documentation platforms and note-taking apps accept a data URI where they will not accept a file.
SVG is a special case
SVG is text, not binary, which changes the calculation.
Base64-encoding an SVG works, but it is wasteful — you are taking text that was already URL-safe and expanding it by a third for no reason. URL-encoding it instead usually produces a shorter data URI and, as a bonus, one you can still read and edit in place:
background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg'…");
The rules are fiddly — # must be escaped, and single quotes are safer than double inside the attribute — but for a set of inline icons the saving adds up. Base64 remains the simpler option when you just want something that works.
Things that will not accept a data URI
Email clients. Gmail strips them from images. Outlook has never supported them dependably. Host the image or attach it with a CID reference instead.
Some content security policies. A strict CSP with img-src 'self' blocks data URIs unless data: is explicitly allowed. Worth checking before inlining anything into a locked-down app.
Open Graph and Twitter card images. These need a real, publicly fetchable URL — the crawler has to request it.
Some older CMS and forum editors. Anything that sanitises HTML aggressively may strip the src entirely.
Limits and requirements
Output is about 33% larger than input, always. That is the encoding.
Very large images produce very large strings. Browsers cope, but your source file becomes unreadable and your version control diffs become useless.
No compression happens here. This tool encodes the file you give it. If you want it smaller, compress it first with the image compressor, then encode.
Browser support for data URIs is universal in browsers. The gaps are in email clients and in strict CSP setups.
Privacy: how this tool handles your image
The file is read by your browser's FileReader API and encoded in memory on your own machine. Nothing is transmitted, nothing is logged, nothing is stored, and closing the tab discards it.
This is easy to overlook because Base64 feels like a technical, impersonal operation. The images people encode are frequently not: a scanned signature to embed in a document template, a logo for a product that has not launched, screenshots of an internal dashboard, a headshot for an intranet page.
A server-side converter receives every one of those files in full — and request bodies routinely end up in access logs, error trackers and backups that nobody set out to fill with other people's images.
Reading a file and encoding it does not need a server. You can confirm this one does not use one: open developer tools, watch the Network tab while you convert, and see that nothing goes out. Or disconnect from the internet after the page loads — the tool keeps working.
Frequently asked questions
What is a data URI?
A way of putting a file's contents directly inside a URL instead of pointing at a file on a server. It looks like data:image/png;base64,iVBORw0KGgo… — the media type, the encoding, then the file itself as Base64 text. Anywhere a URL is accepted, a data URI usually works: the src of an img tag, a CSS background-image, a Markdown image link. The browser decodes it on the spot, so there is no second request.
When should I inline an image and when should I not?
Inline when the image is small — roughly under 10 KB — and needed immediately, such as an icon in your critical CSS. You save an HTTP request and the image cannot arrive late. Do not inline anything larger. A data URI is about 33% bigger than the file, cannot be cached separately from the document it sits in, and has to be re-downloaded on every page that includes it. Inlining a 200 KB hero image adds 270 KB to your HTML and makes the page slower, not faster.
Why is the Base64 version larger than the file?
Base64 represents every three bytes as four characters, which is a fixed 33% expansion, plus a little padding. That is inherent: you are representing 256 possible byte values using an alphabet of 64 printable characters. Gzip or Brotli on the response claws back some of it, but Base64 of already-compressed data such as a PNG or JPEG compresses poorly, so most of the overhead survives.
Does this work with SVG?
Yes, and it works well because SVG is small. It is worth knowing that SVG does not have to be Base64 at all — it is text, so you can URL-encode it instead and get a data URI that is often smaller than the Base64 version and stays readable. If you are inlining a lot of SVG icons in CSS, URL-encoding is usually the better technique.
Can I use a data URI in an email?
Usually not, and this catches people out. Gmail strips data URIs in images outright, and Outlook has never supported them reliably. HTML email images are normally either hosted somewhere public or attached with a CID reference. If your image has to appear in an email, host it or attach it properly rather than inlining it.
Do data URIs hurt performance?
They can, badly, if you use them for the wrong things. The big cost is caching: a normal image is cached once by the browser and reused everywhere, while an inlined one is part of the document and re-downloaded with it every time. The second cost is blocking — a data URI inside a stylesheet makes that stylesheet larger, and the stylesheet blocks rendering. For a genuinely tiny icon these costs are smaller than the request you save. For anything else they are not.
Is there a size limit?
Browsers accept very long data URIs — megabytes, in practice — so the limit you hit is rarely technical. It is the practical one: a large data URI bloats your HTML or CSS, hurts caching, and makes the source unreadable. The 10 KB guideline in this tool is about what is sensible, not what is possible.
Is my image uploaded?
No. The file is read and encoded by your browser using the FileReader API. Nothing is transmitted, logged or stored, and closing the tab discards it. Worth caring about, because people encode private images for internal dashboards, signatures for documents, and company logos that are not public yet.