Image to Base64 Data URI

What a Data URI is

A data URI is a URL that contains the entire resource inline, base64-encoded. Instead of pointing to a remote file, it carries the file content directly: data:image/png;base64,iVBORw0KGgo…. The browser, CSS engine, or email client decodes it on the fly and renders it as if it had been fetched from a separate URL.

The structure is simple: data: scheme, then a MIME type (image/png), an optional encoding marker (;base64), a comma, and the encoded payload. Without the ;base64 marker, the payload is URL-percent-encoded — useful for SVG specifically, where the textual XML survives URL encoding intact and base64 just inflates the size unnecessarily.

When data URIs are useful

• Tiny icons inline in CSS. A 200-byte icon takes one HTTP round-trip if fetched separately; inline, it's free with the stylesheet. Browsers will happily cache the whole CSS bundle.
• Email HTML. Most email clients refuse to load external images by default for privacy reasons. Embedding small assets as data URIs (logo, signature, social icons) ensures they always render.
• Bookmarklets and userscripts. Self-contained pieces of JavaScript that include a tiny image asset without depending on a hosting URL.
• Build-time inlining. Webpack, Vite, and similar tools auto-convert small images (typically <8KB) to data URIs to reduce request count. Configurable via the asset/inline rule.
• Single-file documents. An HTML report you want to share via email — embed the chart images so the report works without separate files.

When NOT to use data URIs

• Anything over ~10 KB. Base64 inflates the original by ~33%. A 100 KB image becomes 134 KB of CSS — costs you parse time, cache eviction risk, and bandwidth on every visit. Use a real image URL with proper caching.
• Reusable assets across pages. If the same icon appears on 50 pages, inlining it means downloading it 50 times. A cacheable external URL is downloaded once.
• HTTP/2 sites with hundreds of small assets. HTTP/2 multiplexing eliminates the request-count penalty that made data URIs popular in the HTTP/1.1 era. Today, a separate small file is often faster overall.
• Anything you want to lazy-load. Data URIs are loaded with the page that contains them. Lazy-loading requires real URLs.
• SVGs. Use percent-encoded data URIs (data:image/svg+xml,%3Csvg…) rather than base64 for SVG. The XML stays roughly the same size after percent-encoding; base64 always adds 33%.

Privacy and security notes

• Everything happens in your browser. Files dropped here are read by the JavaScript FileReader API and converted client-side. Nothing is uploaded; nothing crosses the network. You can verify this in DevTools → Network — there will be no upload requests.
• EXIF and metadata pass through unchanged. If you encode a JPEG, any GPS coordinates, camera serial number, or thumbnail in the EXIF data become part of the data URI too. Strip metadata first with a separate tool if privacy is a concern.
• Data URIs in user-provided content are a small XSS risk. A data URI inside an <img> src is safe; a data URI inside an <a> href can execute JavaScript in some browsers (data:text/html,<script>...). Modern browsers block this in most cases but it's worth knowing if you accept user-supplied images in a CMS.

SVG specifically — skip the base64

/* Don't: base64-encode SVG (wasteful) */
.icon { background-image: url(data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIC4uLg==); }

/* Do: percent-encode the SVG (same size as the source) */
.icon { background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'%3E…%3C/svg%3E"); }

The tool above gives you the percent-encoded form for SVG inputs and base64 for everything else, automatically.