SVG to CSS Converter

What Is an SVG Data URI?

A data URI is a way to embed file content directly inside a URL string, eliminating the need for a separate HTTP request. When applied to SVG images, a data URI encodes the entire SVG markup into a string that can be used as the value of a CSS background-image property, an HTML <img> tag’s src attribute, or any other context that accepts a URL.

The format follows the standard data URI scheme: data:[mediatype][;base64],data. For SVG, the media type is image/svg+xml. The data portion can be either URL-encoded SVG text or a Base64-encoded binary representation.

Why Inline SVG in CSS?

There are several compelling reasons to embed SVG directly in your CSS files rather than referencing external SVG files:

Fewer HTTP requests: Each external file requires a separate network round-trip. For small icons and decorative elements, the request overhead often exceeds the actual transfer time. Inlining eliminates this entirely.
No CORS issues: External SVG files loaded via CSS can trigger cross-origin restrictions. Data URIs are same-origin by definition, bypassing CORS entirely.
Atomic deployment: CSS files with inlined SVGs are self-contained. There is no risk of broken image references due to missing files, incorrect paths, or CDN cache inconsistencies.
CSS pseudo-elements: You cannot use inline SVG in ::before and ::after pseudo-elements, but you can use SVG data URIs as background images in these elements, making them invaluable for icon systems built with CSS.
CSS-only icons: By using SVG data URIs in CSS custom properties (variables), you can build complete icon systems that are switchable via CSS alone, without touching HTML.

URL Encoding vs Base64: Which Is Smaller?

There are two approaches to encoding SVG for data URIs, and they produce significantly different output sizes:

URL Encoding (Recommended)

URL encoding replaces only the characters that are unsafe in a URI context (like <, >, #, and %) with their percent-encoded equivalents. The rest of the SVG text passes through unchanged. For typical SVG content, this produces output that is only slightly larger than the original — often just 10–20% overhead.

An additional optimization is replacing double quotes with single quotes before encoding, since single quotes do not need percent-encoding in a data URI that is itself wrapped in double quotes. This technique, popularized by CSS expert Lea Verou and tools like SVGOMG, produces the smallest possible data URIs for SVG content.

Base64 Encoding

Base64 encoding converts the SVG binary data into a text string using 64 printable ASCII characters. This always increases the size by approximately 33% because every 3 bytes of input become 4 bytes of output. For SVG files, which are already text, this overhead is pure waste — unlike binary formats (PNG, JPEG) where Base64 is the only option.

The main advantage of Base64 is universality: it works correctly regardless of character encoding issues and produces a completely opaque string with no special characters that need further escaping. Some developers prefer it for its simplicity, but for SVG specifically, URL encoding is almost always the better choice.

SVG Minification for CSS

Before encoding, minifying the SVG can dramatically reduce the data URI size. This tool performs several minification steps:

Remove XML comments: Comments like  add zero rendering value.
Remove XML declaration: The <?xml version="1.0"?> prologue is unnecessary for SVG embedded in CSS.
Remove DOCTYPE: SVG DOCTYPE declarations are not required by modern browsers.
Remove metadata: Editor-generated metadata elements contain authoring information that is irrelevant for rendering.
Collapse whitespace: Multiple spaces, tabs, and newlines are reduced to single spaces. Whitespace between tags is removed entirely.

For SVGs exported from design tools like Figma, Illustrator, or Inkscape, minification can reduce file size by 30–60% before encoding even begins.

Practical CSS Patterns for SVG Data URIs

Once you have your SVG data URI, here are the most common CSS patterns for using it:

Background Image

The most common use case is as a CSS background image for icons, decorative elements, or list markers:

.icon-check {
  background-image: url("data:image/svg+xml,...");
  background-repeat: no-repeat;
  background-size: contain;
  width: 20px;
  height: 20px;
  display: inline-block;
}

CSS Custom Properties

Store SVG data URIs in CSS custom properties for a reusable icon system:

:root {
  --icon-arrow: url("data:image/svg+xml,...");
  --icon-check: url("data:image/svg+xml,...");
  --icon-close: url("data:image/svg+xml,...");
}

.btn-next::after {
  content: "";
  background-image: var(--icon-arrow);
  width: 16px;
  height: 16px;
}

List Markers

Replace default list bullets with custom SVG icons:

ul.custom-list {
  list-style: none;
  padding-left: 1.5em;
}

ul.custom-list li::before {
  content: "";
  display: inline-block;
  width: 1em;
  height: 1em;
  margin-right: 0.5em;
  background-image: url("data:image/svg+xml,...");
  background-size: contain;
  vertical-align: -0.15em;
}

Browser Support and Limitations

SVG data URIs are supported by all modern browsers (Chrome, Firefox, Safari, Edge) and have been since approximately 2012. There are a few limitations to be aware of:

No external references: SVGs embedded as data URIs cannot reference external resources (fonts, images, CSS files). All styles and content must be self-contained within the SVG markup.
No currentColor in CSS data URIs: When an SVG uses currentColor as a fill or stroke value, it works when the SVG is inlined in HTML but not when loaded via a CSS background-image data URI. The SVG in a data URI has no access to the parent element’s color context.
Internet Explorer limits: IE 8 supported data URIs up to 32 KB. IE 9+ raised this significantly. These limits are irrelevant for modern browsers.
CSS file size: Inlining many large SVGs can bloat your CSS file. The CSS file is render-blocking, so keeping it lean is important for performance. Consider inlining only small, critical icons.

SVG Data URIs vs Inline SVG vs Icon Fonts

Each icon embedding strategy has trade-offs:

Inline SVG in HTML: Most flexible (supportscurrentColor, CSS animations, JavaScript manipulation) but requires changes to HTML markup.
SVG data URI in CSS: Works in pseudo-elements and as backgrounds, self-contained in CSS, but static (nocurrentColor, no JS access).
SVG sprite sheet: One HTTP request for all icons, supports currentColor via <use>, but requires an external file and tooling.
Icon fonts: Simple to use but accessibility concerns, rendering inconsistencies, and inflexible styling. Generally considered a legacy approach.

For CSS-only icon needs (pseudo-elements, hover states, background decorations), SVG data URIs are the best fit. For interactive icons that need color inheritance and animation, inline SVG in HTML is preferable.

Frequently Asked Questions

Should I use URL encoding or Base64 for SVG?

URL encoding produces smaller output for SVG because SVG is a text-based format. Base64 always adds 33% overhead, while optimized URL encoding typically adds only 10–20%. Use Base64 only if you encounter character encoding issues in specific environments.

Will this work with animated SVGs?

Yes. SVG animations defined with <animate> or CSS @keyframes embedded within the SVG work correctly when loaded as a data URI in a CSS background image. However, the animation will play independently and cannot be controlled from the parent page’s CSS or JavaScript.

Is my SVG data safe?

This tool processes SVG entirely in your browser. No data is sent to any server. The SVG preview is sanitized by removing script elements and event handlers before rendering.

Why is the data URI larger than my original SVG?

The data URI includes the data:image/svg+xml, prefix plus the encoded SVG. URL encoding replaces certain characters with three-character sequences (e.g., < becomes %3C). The total overhead is modest for URL encoding. If using Base64, the 33% increase is inherent to the encoding scheme.