Image to Base64 Converter
Turn an image into a base64 data URI you can paste straight into HTML, CSS, JSON, or an email template — no file, no request, no path to get wrong. You also get the two snippets people actually want, an `<img>` tag and a CSS `url()`, and a straight answer about whether a file this size should be inlined at all. The bytes are read off your disk and encoded in this tab; nothing is uploaded and nothing is re-encoded.
Drop an image to encode
One file at a time, up to 2.00 MB — data URIs get impractical well before that. The bytes are read and encoded in this tab; nothing is uploaded.
Output
Nothing encoded yet. Drop an image above — its bytes are read straight off your disk and turned into text here, with no upload and no re-encoding, so the data URI carries exactly the file you dropped in.
Make the icon you are about to inline
Small marks and icons are what belong in a data URI. Design them on Moda.
Try Moda free →What a data URI is actually for
A data URI puts the file inside the document, so the browser needs no second request to draw it. That trade is worth making for things that are small and always needed: a 300-byte icon, a gradient, a bullet marker, a logo in an HTML email where external images are blocked by default until the reader clicks "show images". It is a bad trade for anything large, because the bytes stop behaving like an image and start behaving like source code — they cannot be cached separately, cannot be lazy-loaded, are re-downloaded with every version of the file they live in, and have to be parsed before anything after them renders.
The 33% is real, and it is not the whole cost
Base64 represents three bytes with four characters, so every file grows by exactly a third — a 90 KB photo becomes 120 KB of text, and the panel tells you the number before you paste it anywhere. Compression claws some of that back on the wire, since base64 text gzips better than binary does, but the uncompressed cost is what your CSS parser, your bundler, your diff, and your editor all deal with. There is also a second, quieter cost: an inlined image is invisible to the browser’s preload scanner and to every image optimisation the platform would otherwise apply.
SVG is the exception worth knowing
Small SVGs are the one case where inlining is almost always right, and base64 is not the best way to do it. An SVG is text already, so a data URI can carry it URL-encoded rather than base64-encoded — which is usually *smaller* than the source, where base64 would make it a third bigger. If your SVG contains no characters that need escaping beyond the obvious, `url("data:image/svg+xml,<svg …>")` beats the base64 form. This tool produces the base64 version because it works everywhere and needs no escaping rules; the saving is worth chasing by hand only for something you will ship a lot of.
It is an encoding, not compression and not security
Base64 exists to move binary through channels that only carry text: email bodies, JSON fields, URLs, source files. It makes data bigger, never smaller, and it protects nothing — anyone with the string can turn it straight back into your original file, byte for byte. That last point matters more than it sounds: an image inlined into a public stylesheet or a client-side bundle is exactly as public as a file on a server, and its EXIF metadata comes along for the ride, because the data URI carries the file you dropped rather than a re-encode of it.
Frequently asked questions
Is my image uploaded to encode it?
No. The file is read from your disk into memory in this tab and the base64 is computed here. There is no request and no server involved, which is worth knowing because the images people inline are often internal assets and logos that are not published anywhere yet.
Why is the base64 bigger than my file?
Because base64 spends four text characters on every three bytes, so the output is always about 33% larger than the input. That is inherent to the encoding, not something this tool is doing inefficiently. If size matters, the fix is a smaller image, not a different encoder — compress it first, then encode.
How big is too big to inline?
Under roughly 8 KB, inlining usually wins outright: the image costs less than the HTTP request that would have fetched it, which is why build tools have inlined assets around that threshold for years. Between 8 KB and 100 KB it is a judgement call about caching. Past 100 KB it is almost always the wrong choice, and the panel says so rather than handing you a wall of text with no comment.
Does the image get re-compressed or changed?
No. The data URI carries the file’s own bytes, so what you get back is bit-for-bit the file you dropped in — an animated GIF stays animated, an SVG stays a vector, and a photo keeps its EXIF. That last one is worth a thought before you inline a photo into something public: if the metadata should not travel with it, strip it first.
Can I convert base64 back into an image here?
Not on this page — it goes one way. Decoding a data URI back to a file needs no tool anyway: paste it into a browser’s address bar and the browser renders it, then save it from there. The URL and base64 text encoder/decoder handles the plain-text direction if what you have is a string rather than an image.