SVG to Data URI Converter

It is the whole image written as a URL. The string opens with data:image/svg+xml, and the rest is the markup itself, escaped so it survives inside a URL. Because the artwork travels in the reference, a browser that has the stylesheet already has the image: no second request, no waiting on a connection for a 600-byte icon.

URL-encoding, in nearly every case. SVG is text, so Base64 gains nothing: it turns three bytes into four for a fixed one-third premium regardless of content. Percent-encoding pays two extra bytes only for the handful of characters that must be escaped, typically landing 10–25% above the source. It also stays readable in a diff and compresses better, because gzip and brotli can still see the repeated tag names that Base64 scrambles. Keep Base64 for pipelines that rewrite or double-escape percent signs.

Almost always the namespace. When you write an svg element directly in an HTML page, the parser already knows what it is. A data URI is loaded as a standalone document, so the file has to say so itself with xmlns="http://www.w3.org/2000/svg" on the root element. Without it the browser parses nothing and draws nothing, silently. The other frequent cause is a raw # in a fill colour: unescaped, it turns the rest of the URI into a fragment identifier.

Because the encoded document decides its own geometry. With no viewBox and no width or height, a browser falls back to a 300 by 150 box. With width and height but no viewBox, the shape is locked to that size and refuses to scale. With a viewBox alone it scales freely, which is what you usually want for a background; pair it with background-size, or with explicit width and height on the image tag.

No. The encoded SVG is a separate document, and nothing from the host page reaches inside it: currentColor resolves against that document's own colour property (black, unless the markup sets it), and custom properties are not inherited across the boundary. Three ways round it: edit the fill in the markup before encoding and keep one URI per colour, drive the shape through mask-image so the visible colour comes from background-color, or drop the svg element into the HTML directly where page CSS can style it.

No, and that limitation is by design rather than a bug. An SVG loaded through url() or an image tag runs in a restricted mode: no scripts execute, and no external resource is fetched, whether it is a webfont, a linked bitmap, or a stylesheet. Convert text to paths before encoding, and embed any raster artwork as its own nested data URI inside the markup.

Not a practical one in current browsers: Chrome, Firefox and Safari all accept data URIs in stylesheets far beyond a megabyte. The familiar 32 KB figure is an Internet Explorer 8 limit that stopped mattering years ago. The real constraints sit elsewhere: minifiers and source maps get unwieldy, some CMS fields truncate long values, and every kilobyte is re-downloaded with the file it lives in. Treat 4 KB as comfortable and 32 KB as the point where a separate file is the better engineering decision.

Four things: comments, the XML declaration, whitespace-only gaps between tags, and the line breaks exporters leave between attributes. It never removes an attribute, rounds a coordinate, merges a path, or renames an id, and it leaves character data inside text, tspan, textPath, title, desc, style and script untouched. A document that asks for xml:space="preserve" keeps every gap between its tags as well, though comments and the XML declaration still go. That makes the pass safe but modest. If you want real reductions, run the file through SVGO first and paste the result here.