Convert an image to a Base64 string

Drop in an image and get its Base64 encoding instantly, in whichever form you need: a full data URI, the raw Base64 string on its own, a ready-to-use CSS background-image rule, or an HTML img tag. It all runs online in your browser, so the file is never uploaded to encode it.

No upload No file size limit No sign-up Free

Drop an image here

or click to choose

What a data URI actually buys you

Normally an image is a separate file: the browser requests the HTML, parses it, finds an <img> tag, and fires off a second request to fetch the picture. A data URI skips that second trip entirely by encoding the image's raw bytes as text and putting them directly in the HTML, CSS or JSON — the browser already has everything it needs the moment the first request finishes.

That trade is worth making for small, frequently repeated assets: a favicon-sized icon, a logo mark, a one-color placeholder, a tiny background texture. It stops being worth it as the image grows, for a reason that has nothing to do with encoding and everything to do with caching.

The size cost, and why it compounds

Base64 encodes every 3 bytes of the original file as 4 text characters. That is a fixed, unavoidable 33% size increase before any compression is considered — a 30KB icon becomes roughly 40KB of text. On its own that is a manageable cost for a small file.

The bigger issue is caching. A normal image file is fetched once and stored by the browser; every other page that uses it loads instantly from cache. A data URI is baked into the HTML or CSS itself, so it gets re-downloaded, re-parsed and re-decoded every single time that HTML or CSS loads — there is nothing separate for the browser to cache. Inline a 200KB image and you have not saved a request, you have made every page load 260KB heavier with no way to avoid it.

A rough rule that holds up in practice: inline it if the file is a few kilobytes and used once or twice. Link to it normally the moment it is either large or reused across many pages.

Four formats, four different jobs

FormatLooks likeUse it when
Data URIdata:image/png;base64,iVBOR...Anywhere a URL is expected
Raw Base64iVBOR...Your own code builds the header itself
CSS background-imagebackground-image: url("data:...");Pasting straight into a stylesheet
HTML img tag<img src="data:...">Pasting straight into a page

The data URI is the complete, self-contained value and the one most tools expect by default. Raw Base64 exists for the cases where a config file, an API payload or your own code already knows the MIME type and just needs the encoded bytes without the data:image/png;base64, prefix repeated everywhere.

No quality is lost

Base64 is a text encoding of the exact original bytes, not a re-compression step. Decoding it reproduces the identical file, bit for bit, so whatever quality the source image had going in is exactly what comes out the other end. The only change is representation — binary bytes become a string of 64 printable characters — not content.

Nothing is uploaded

The encoding happens entirely inside your browser via the standard FileReader API. The file is never sent to a server, which matters when the image is from an unreleased design, a private project, or anything else you would rather not route through a third party just to get a text string back.

Frequently asked questions

What is a Base64 data URI, and why would I embed an image instead of linking it?

A data URI packs the image's raw bytes directly into a piece of text using 64 printable characters, so the whole image can live inline in HTML, CSS or JSON instead of as a separate file the browser has to fetch. That trade makes sense for small, frequently used images - an icon, a logo, a tiny background pattern - where saving one HTTP request outweighs a bigger file. For anything much larger than a few KB it usually works against you; see the size question below.

Why is the Base64 output bigger than my original file?

Base64 encodes every 3 bytes of the original file as 4 text characters, which is a fixed 33% size increase before any compression. A 30KB icon becomes a 40KB string. For small assets that overhead is worth paying to save a request; for anything image-heavy, an actual image file loaded normally is smaller over the wire and lets the browser cache it separately, which an inlined string cannot do.

What is the difference between the four output formats?

Data URI is the complete self-contained string (data:image/png;base64,...) - paste it anywhere a URL is expected. Raw Base64 is just the encoded text with no prefix, for when your own code already builds the data URI or header. CSS background-image is the data URI wrapped in a ready-to-paste CSS rule. HTML img tag wraps it in an element with the src already filled in, so you can drop it straight into a page.

Will this work for large images?

Yes, there is no size limit here since nothing is uploaded - but a large embedded image is rarely a good idea regardless of the tool. Inlining forces the browser to download the full string before it can render anything, and it cannot be cached the way a separate image file can. Base64 embedding earns its keep on small assets, not full photos.

Does converting to Base64 lose any quality?

No. Base64 is a text encoding of the exact original bytes, not a re-compression - decoding it back gives you the identical file, pixel for pixel. Whatever quality the source image already had is exactly what comes out the other end.

Is the image uploaded to encode it?

No. The file is read and encoded entirely inside your browser using the standard FileReader API - nothing is sent to a server. That matters if the image is from a private project, an unreleased design, or anything else you would rather not route through a third party just to get a text string.