Data URIs: Complete Guide to Inline Data in URLs

The Problem Data URIs Solve

Every external resource your page loads requires a separate HTTP request. For HTML pages with dozens of small images - icons, decorative bullets, UI chrome - each one costs a round-trip to the server: DNS lookup, TCP handshake, TLS negotiation, request, response. On HTTP/1.1 connections, browsers limited concurrent connections to 6–8 per domain, so many small resources queued up and waited.

A data URI encodes the file's binary content as a base64 string and embeds it directly in the HTML or CSS. The browser decodes it from memory instead of making a network request:

<!-- Traditional: separate HTTP request -->
<img src="/icons/checkmark.png" alt="Check">

<!-- Data URI: embedded inline, zero network requests -->
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQ..." alt="Check">

This matters most for small, frequently used assets like 16x16 icons, spinners, and decorative elements. For these, eliminating the HTTP request can be faster than the overhead of the base64 encoding.

Data URI Syntax: The Full Specification

The data URI scheme is defined in RFC 2397. The format is:

data:[<mediatype>][;base64],<data>

Breaking down each component:

• data: - The scheme prefix. Required.
• <mediatype> - A MIME type like image/png, image/svg+xml, text/css. Optional; defaults to text/plain;charset=US-ASCII.
• ;base64 - Indicates the data is base64-encoded. Omit for plain text data (which can be URL-encoded).
• ,<data> - The actual data. Required. The comma separator is mandatory even for empty data.

Real Examples Across Common Use Cases

<!-- PNG image (base64-encoded) -->
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUg..." alt="">

<!-- SVG (URL-encoded, no base64 needed for text formats) -->
<img src="data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg'...%3E%3C/svg%3E" alt="">

<!-- Inline SVG in CSS background-image -->
.icon {
  background-image: url("data:image/svg+xml,%3Csvg...%3E%3C/svg%3E");
}

<!-- GIF (base64) -->
<img src="data:image/gif;base64,R0lGODlhAQABAIAAAP///..." alt="">

<!-- Plain text -->
<a href="data:text/plain,Hello%20World">Open text file</a>

<!-- HTML document -->
<iframe src="data:text/html,%3Ch1%3EHello%3C/h1%3E"></iframe>

<!-- CSS font (woff2) -->
@font-face {
  font-family: 'MyFont';
  src: url('data:font/woff2;base64,d09GMgAB...') format('woff2');
}

SVG Data URIs: URL-Encoding vs. Base64

For SVG specifically, you have a choice: base64-encode the entire SVG, or URL-encode it as a text string. URL-encoding is generally better for SVGs because:

• SVG is already text; base64 encoding increases size by ~33%
• URL-encoded SVGs are still human-readable in source code
• Some gzip/brotli algorithms compress URL-encoded SVGs better

<!-- Less efficient: base64 SVG (larger, not human-readable) -->
background-image: url("data:image/svg+xml;base64,PHN2ZyB4bWxucy...");

<!-- Better: URL-encoded SVG (smaller, readable) -->
background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24'%3E%3Cpath d='M5 12l5 5L20 7'/%3E%3C/svg%3E");

The minimal URL-encoding for SVGs only requires escaping < as %3C, > as %3E, # as %23, and double quotes as ' single quotes inside the SVG attributes. Spaces can remain as %20 or be left as spaces in modern browsers.

Step-by-Step: Converting an Image to a Data URI

1. Get the image file you want to embed (PNG, JPG, GIF, WebP, SVG).
2. Convert to base64 using one of these methods:
   • Online tool: Use our Image to Base64 converter - upload the image and copy the result
   • Command line: base64 -i image.png | tr -d '\n'
   • Node.js: fs.readFileSync('image.png').toString('base64')
   • Python: import base64; base64.b64encode(open('image.png','rb').read()).decode()
3. Build the data URI by prepending data:image/png;base64, (replace image/png with the correct MIME type).
4. Embed it in your HTML or CSS.

<!-- Step 4 result -->
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJ
AAAADAELLEQVCB2BgYGBgYGBgYGBgAAAABJRU5ErkJggg=="
     alt="1x1 transparent pixel"
     width="1" height="1">

Performance Analysis: When Data URIs Help and Hurt

Data URIs are not universally beneficial. The trade-offs depend on image size, caching behavior, and how many images you embed.

When Data URIs Improve Performance

• Very small images (under 2KB): The HTTP overhead (headers, round-trip latency) exceeds the 33% size increase from base64 encoding. A 500-byte icon in a data URI typically loads faster than a separate HTTP request.
• Critical above-the-fold images: Embedding the hero icon directly in the HTML or critical CSS eliminates a render-blocking HTTP request and can improve First Contentful Paint.
• Email HTML templates: Email clients (Outlook, Gmail mobile) often block external images by default. Inline data URIs ensure images always display without user interaction.
• Single-file deliverables: If you need to deliver a standalone HTML file that works offline (e.g., a report, a demo), data URIs bundle all assets into one file.

When Data URIs Hurt Performance

• Images over 5–10KB: The 33% base64 overhead becomes significant. A 10KB image becomes ~13.3KB when base64-encoded. Combined with the fact that data URIs cannot be separately cached, this is rarely worth it.
• Images used on multiple pages: An external image file gets cached by the browser after the first load and served from disk cache on subsequent pages. A data URI is re-parsed every time the page loads - there is no cross-page caching.
• Large CSS files: Embedding many images in a CSS file inflates its size dramatically. A large CSS file blocks rendering; a large external image does not. The cure is worse than the disease.
• HTTP/2 environments: HTTP/2 multiplexing allows many resources to be downloaded concurrently over a single connection. The "reduce requests" argument for data URIs is much weaker with HTTP/2, while the caching drawback remains.

Rule of thumb: use data URIs for images under 2KB that appear on every page of your site. For everything else, serve images as external files with proper caching headers.

Browser Size Limits for Data URIs

Browsers impose limits on how large a data URI can be. Exceeding the limit causes the data URI to silently fail and the image not to render:

• Chrome / Edge / Firefox: No enforced limit in practice for page content; limits apply in specific contexts (e.g., URL bar). Tested up to several MB in <img> and CSS.
• Safari: Documented limit of 2MB for data URIs used as CSS backgrounds. Large data URIs in <img> tags generally work up to tens of MB.
• Internet Explorer 8: Hard 32KB limit. IE9+ raised this to 4GB in theory, but practical performance degraded badly above a few KB.

For modern browsers in 2026, you will rarely hit a hard limit for reasonable use cases. The practical constraint is performance, not browser limits.

Security Considerations

Data URIs can be misused in phishing attacks and XSS exploits. Key security notes:

• Never trust user-supplied data URIs: If user input is rendered as a data URI, an attacker can inject data:text/html,<script>...</script> to run arbitrary HTML.
• Content Security Policy (CSP): A CSP img-src directive of 'self' does NOT allow data URIs. You must explicitly add data: to the allowlist: img-src 'self' data:. Be cautious - allowing data: for scripts is dangerous.
• Browser sandbox: Modern browsers sandbox data URIs loaded in the address bar or iframes, preventing access to the document's cookies and origin. But data URIs in <script src="data:..."> execute in the page's context.

Frequently Asked Questions

What is the difference between a data URI and a blob URL?

A data URI embeds the actual encoded data inline in the string. A blob URL (blob:https://example.com/uuid) is a reference to binary data stored in browser memory, created with URL.createObjectURL(). Blob URLs are more memory-efficient for large files because the data is referenced rather than embedded, and they can be revoked with URL.revokeObjectURL() to free memory. Data URIs are simpler to use but carry the full data payload in the string.

Why does a data URI image look blurry on retina displays?

The image is not blurry because it is a data URI - it is blurry because you are using a 1x resolution image on a 2x display. Use a 2x image and set the HTML width/height attributes to half the image's pixel dimensions, or use srcset with separate data URIs for 1x and 2x. SVG data URIs are vector-based and inherently resolution-independent.

Can I use a data URI as a favicon?

Yes, with limitations. Use <link rel="icon" href="data:image/png;base64,..."> in the <head>. This works in Chrome and Firefox. Safari has historically had poor support for data URI favicons and may ignore them. For maximum compatibility, serve a real favicon.ico or PNG file.

Do data URIs work in email clients?

It depends on the client. Gmail strips data URIs from the HTML during rendering, making them useless in Gmail. Outlook (desktop) supports them for some image types. Apple Mail supports them. For email, use externally hosted images with absolute URLs instead of data URIs, as most modern clients block only remote images (not inline ones), but Gmail actively removes data URIs.

How do I decode a data URI to get the original file back?

Strip the data:image/png;base64, prefix to get the raw base64 string, then decode it. In a browser console: atob(dataUri.split(',')[1]). For binary files (images), use fetch(dataUri).then(r => r.blob()) to get a Blob. Use our Base64 Decoder for a quick online conversion without writing code.

Use Our Free Image to Base64 Converter

Converting images to data URIs by hand requires a base64 encoder, MIME type knowledge, and careful string construction. Our free Image to Base64 converter handles all of it: upload your image, choose whether you want the raw base64 or the full data URI, and copy the result.

Use our free tool here → Image to Base64 at SecureBin.ai