Skip to content
ToolBoxGeniehome

Image to Base64

Image Tools · Added

Convert an image into a Base64 data URI, with copy-ready HTML and CSS snippets. The encoding happens in your browser, and the tool shows you how much larger the file gets — because inlining trades a network request for a bigger asset, and that trade is only worth making for small images.

Or drop a file onto this box.

JPG, PNG, WebP, GIF, BMP or AVIF, up to 2.00 MB. It is read from your device and never uploaded.

Output

How to use the image to base64

  1. 1Choose an image, or drop it onto the box. JPG, PNG, WebP, GIF, BMP and AVIF are accepted.
  2. 2Pick the output you want: the bare data URI, a ready-made <img> tag, or a CSS background-image declaration.
  3. 3For the HTML snippet, write alt text describing the image. Leave it empty only if the image is purely decorative.
  4. 4Check the reported size increase. Above roughly 10 KB, a normal file the browser can cache is usually the better choice.
  5. 5Copy the snippet and paste it into your source.

Examples

A small icon inlined into CSS

Input
A 1.2 KB SVG-style PNG icon · CSS output
Result
background-image: url("data:image/png;base64,iVBORw0…"); — about 1.6 KB

This is what inlining is for. One fewer request, and the icon arrives with the stylesheet rather than after it.

A photograph, which should not be inlined

Input
A 480 KB JPEG
Result
About 640 KB of Base64 — a 33% increase

The tool produces it and warns you. A data URI cannot be cached on its own, so every page carrying it re-downloads the photo in full.

An image emailed as text

Input
A 4 KB PNG · Data URI output
Result
A single line beginning data:image/png;base64,

Data URIs survive anywhere plain text does, which is why they are useful for pasting an image into a JSON payload, a config file or a chat message.

About the image to base64

What inlining actually buys, and what it costs

Every separate image on a page is a request: a lookup, a connection, headers in both directions, then the bytes. For a large image that overhead is trivial next to the payload. For a 500-byte icon it can easily dominate — the negotiation costs more than the thing being negotiated for. Inlining removes it entirely by carrying the image inside the document or stylesheet that references it.

The cost is threefold and worth stating plainly. The payload grows by about a third, because Base64 spends four characters on every three bytes. The image can no longer be cached independently, so it is re-fetched with every document that carries it rather than once per visitor. And it inflates the file it sits in, which for a stylesheet means delaying every rule after it, because CSS is render-blocking and the browser cannot use any of it until the whole file has arrived.

That is why the useful rule is about size rather than taste. Below roughly ten kilobytes the removed request usually wins. Above it, the cache almost always does.

Where data URIs are genuinely the right answer

Beyond performance, a data URI is the only form of an image that survives a text-only channel. That makes it the practical way to embed an image into a JSON API response, a YAML config, an email template that must not reference an external host, or a single self-contained HTML file that has to work with no network at all.

It is also how a low-quality image placeholder works: a tiny, heavily blurred version inlined into the markup so something appears immediately, with the real image swapped in once it downloads. At that size — often under a kilobyte — the encoding overhead is irrelevant and the request saved is the entire point.

One caveat that catches people out: an SVG does not need Base64 at all. It is already text, so it can be inlined directly with URL-encoding, which avoids the 33% penalty completely and stays readable in your source. This tool handles raster images, where Base64 is the only option.

Frequently asked questions

What is a data URI?
It is a way of writing a file's contents directly into a URL instead of pointing at a location. The string begins with the MIME type and the word base64, then the whole file encoded as text. A browser meeting one decodes it and renders the image without making a network request, which is the entire point: the image arrives with the document rather than as a separate fetch afterwards.
Why is the encoded version bigger than my file?
Base64 represents three bytes of binary as four text characters, so the output is always about 33% larger, plus a few characters of header. That is inherent to the encoding rather than a fault in this tool. It is also the reason inlining is a trade: you remove a request and add roughly a third to the payload.
When should I inline an image, and when should I not?
Inline small, ubiquitous images — icons, a logo in the header, a placeholder shown while a real image loads — where the request costs more than the bytes. Do not inline photographs or anything large. A data URI cannot be cached separately from the file it lives in, so a 400 KB image inlined into your stylesheet is re-downloaded on every page that loads it, and it blocks that stylesheet from being parsed until it has all arrived.
Is my image uploaded to encode it?
No. The browser's own FileReader turns the file into a Base64 string in the tab, and the preview shown underneath is rendered from that same string — which is also the proof it round-tripped. Nothing is sent anywhere, so an unreleased logo or an internal diagram is safe to encode here.
Does encoding change the image?
No. The exact bytes of your file are encoded, not a re-compressed copy — this tool never re-encodes what you give it. If you want the image smaller before inlining, which is usually the right order of operations, compress it first and then encode the result.
Why is there a size limit?
Two megabytes, and it is about steering rather than capability. A data URI much beyond that produces a source file no one can read or diff, and it is nearly always the wrong engineering choice. If you genuinely need to move a large image as text, encode it as a file rather than inlining it into markup.