SVG Data URIs Explained: How to Embed SVG in CSS and HTML (2026)

A data URI is a way to include file content directly in a URL string using the data: scheme. Instead of referencing an external file, the file's content is encoded inline:

background-image: url('data:image/svg+xml,<svg ...>...</svg>');

Anatomy of an SVG data URI:

• data: — The URI scheme indicating inline data
• image/svg+xml — The MIME type declaring this is SVG content
• , or ;base64, — The encoding separator (URL-encoded or Base64)
• The SVG content itself — either URL-encoded text or Base64-encoded binary

Browsers parse data URIs the same way they parse external files — the rendering is identical.

There are two ways to encode SVG content in a data URI. The choice significantly affects file size:

Characteristic	URL-Encoded	Base64
Size overhead	~10–20% (only special characters encoded)	~33% (all bytes encoded)
Readability	Partially readable in source	Completely unreadable
CSS compatibility	All modern browsers	Universal (including older systems)
HTML <img> support	CSS background only	Works in <img src> and CSS
Special characters	Must escape #, <, >, "	No escaping needed
Best for	CSS backgrounds (smaller output)	Maximum compatibility

Recommendation: Use URL-encoded data URIs for CSS backgrounds. Use Base64 only when you need to embed SVG in <img src> attributes or when working with environments that have escaping issues.

Follow these steps for optimal results:

• Step 1: Optimize the SVG — Run it through the SVG Optimizer to remove metadata, strip whitespace, and minimize path data. Smaller source SVG = smaller data URI.
• Step 2: Remove the XML declaration — The <?xml version="1.0"?> header is unnecessary for data URIs and adds bytes.
• Step 3: Choose your encoding — For CSS use, URL-encode special characters. For img tags, use Base64.
• Step 4: Construct the URI — Combine the MIME type, encoding separator, and content into the data URI string.
• Step 5: Apply in your CSS — Use the data URI as a background-image value or content in pseudo-elements.

Our SVG to Data URI tool handles all of these steps automatically — paste your SVG and copy the ready-to-use CSS.

Data URIs work best for small, frequently-used graphics embedded in CSS:

• CSS pseudo-elements — Icons in ::before and ::after where you can't use HTML markup
• List markers — Custom bullet points using list-style-image
• Form element decorators — Checkbox marks, select arrows, input icons
• Repeating patterns — Small SVG tiles used with background-repeat
• Critical-path icons — Small icons that must render immediately without waiting for external file downloads

For all of these cases, the eliminated HTTP request outweighs the small increase in CSS file size.

Data URIs have real limitations that make them the wrong choice in several scenarios:

• Large SVGs (>4 KB) — The inline code bloats your CSS file, increasing parse time and reducing cache efficiency
• Frequently changing graphics — Every change requires regenerating the data URI and updating CSS, which breaks CSS caching
• Interactive SVGs — Data URI SVGs cannot be styled with CSS or manipulated with JavaScript. Use inline SVG instead.
• Many unique SVGs — If you have 50+ unique data URIs in your CSS, the file becomes unwieldy. Use an SVG sprite sheet instead.
• Images referenced multiple times — External SVG files are downloaded once and cached. Data URIs duplicate the content every time they're referenced.

Size guideline: If the SVG is under 2 KB after optimization, a data URI is usually beneficial. Between 2–4 KB, measure the impact. Above 4 KB, use an external file.

The performance trade-off is straightforward: you save one HTTP request but increase CSS file size. Here's how the math works for a typical icon:

Approach	HTTP Requests	CSS Size Impact	Total Bytes
External SVG file	+1 request	~40 bytes (URL reference)	~500 B (file) + 40 B (CSS)
URL-encoded data URI	0 requests	~600 bytes (inline)	600 B (CSS only)
Base64 data URI	0 requests	~800 bytes (inline)	800 B (CSS only)

For small icons on HTTP/1.1 connections (where each request has overhead), data URIs win. On HTTP/2+ with multiplexing, the advantage is smaller but still relevant for critical-path rendering.