Skip to content
ToolBoxGeniehome

SVG Optimizer

Image Tools · Added

An icon exported from a design tool carries the editor's fingerprints: a generator comment, an RDF metadata block, namespaced attributes no renderer reads, and coordinates written to seven decimal places. None of it draws anything. This removes it in your browser, rounds the geometry to a precision you choose, and shows you the file it produced rather than describing it.

The file is read into this tab and cleaned here. It is not uploaded.

The only step that changes the drawing. Two places is invisible on an icon; zero can distort curves.

Optimised SVG

Original
762 B
Optimised
329 B
Saving
57%

4 elements kept

Preview

Preview of the optimised SVG

Percent-encoding, not Base64 — for SVG it is the smaller of the two.

Everything happens in this tab — the markup is never sent anywhere. The preview is the real output, so what you see is what the downloaded file draws.

How to use the svg optimizer

  1. 1Paste your SVG markup, or choose an .svg file — it is read in this tab, not uploaded.
  2. 2Leave the default switches on for a safe clean-up: comments, editor data and scripts go, the drawing stays.
  3. 3Set the coordinate precision. Two decimal places is invisible on an icon and is where most of the saving comes from.
  4. 4Check the preview, then copy the markup, download the file, or take the CSS data URI.

Examples

An exported 24-pixel icon

Input
762 bytes: an XML declaration, a generator comment, an rdf:RDF metadata block, an inkscape:label, and coordinates at seven decimal places
Result
329 bytes — 57% smaller, with the title element and both paths untouched

The drawing is byte-identical in the preview; only things that never rendered were removed.

An SVG carrying script

Input
<svg onload="alert(1)"><script>…</script><circle r="4.123456"/></svg>
Result
The script element and the onload attribute are removed, r becomes 4.12, and both removals are reported above the output

Inlining an icon in CSS

Input
A cleaned 20-line icon
Result
background-image: url("data:image/svg+xml,%3Csvg…"); — percent-encoded rather than Base64

About the svg optimizer

Where the bytes actually are

In a typical exported icon, roughly half the file never draws. The generator comment, the RDF metadata block describing the licence, the editor's own namespaced attributes recording layer names and tool settings, and the XML declaration are all inert once the file reaches a browser.

The other half is precision. A design tool that computes a point as 12.000000000000002 writes it out in full, and every one of those digits is a byte served to every visitor. Rounding to two decimal places on a 24-pixel canvas cannot move a point by more than a hundredth of a pixel, and it is usually the single largest saving in the file.

What it does not do is change how the file compresses. Gzip and Brotli already handle the repetition well, so a 57% saving on the raw bytes is a smaller saving over the wire — real, but not the same number. The figures shown here are raw bytes, which is the honest thing to measure without knowing your server's settings.

Inline, or serve as a file?

A data URI saves a request, which matters for a small icon that appears on every page. It also cannot be cached separately, so the same icon inlined on ten pages is downloaded ten times, and it cannot be styled with CSS the way an inline <svg> element can.

The rough dividing line: inline small, static, ubiquitous icons; serve anything over a couple of kilobytes, anything that changes independently of the page, and anything you need to recolour with currentColor. The tool warns when a data URI passes 32 KB, which is well past the point where a separate file is the better answer.

SVG as an attack surface

Any site that accepts an uploaded SVG and shows it back has to decide what to do about script. An SVG rendered through an <img> tag is inert — scripts do not run and external references do not load — which is why the preview on this page uses one. An SVG inlined into the markup is fully live.

That is the reason the two are not interchangeable, and the reason this tool reports what it removed rather than removing it quietly. If you are cleaning a file that came from outside your team, the count of scripts and handlers is the more useful output on the page.

It is worth being exact about the limit of that, though. Removing script tags and on-event attributes covers the usual cases and not the unusual ones: a javascript: link, an external reference, a style block that imports something. This is a cleaner, and a cleaner is not a sanitiser. For files uploaded by strangers, sanitise on the server with a library built for it and serve the result from an origin that is not your application.

Frequently asked questions

Will optimising change how the SVG looks?
Only coordinate rounding can, and you choose the precision. Everything else — comments, editor namespaces, metadata blocks, the XML declaration — is data that no renderer draws. At two decimal places a 24-pixel icon is pixel-identical; at zero decimal places curves visibly flatten, which is why the preview shows the real output rather than the original.
Why does it strip scripts by default?
Because an SVG is a document, not a picture. Inlined into a page, its script tags execute and its on-event attributes fire with the same privileges as any other code on that page. An SVG accepted from someone else and pasted into a template is a well-known way in. The count is reported whether or not you have removal switched on, so a file that carried script is never handed back looking clean.
Does this make an untrusted SVG safe to inline?
No, and it is important not to read it that way. It removes script elements and on-event attributes, which are the common cases, but it is a cleaner rather than a sanitiser: it does not strip javascript: links, external references pulled in by use or image elements, or anything a style block imports. Treat the counts it reports as a warning that a file is hostile, not as proof that it has been made harmless — for untrusted uploads, sanitise server-side with a dedicated library and serve them from a separate origin.
Are ids and class names safe?
They are never touched. A gradient referenced as fill="url(#brand)", a symbol pulled in with use href="#icon", and any CSS or JavaScript elsewhere on your page all depend on those exact strings. Renaming them shrinks the file and breaks the drawing, so this tool does not offer it.
Why a percent-encoded data URI instead of Base64?
Base64 inflates any payload by about a third. SVG is mostly characters a URI accepts unescaped, so encoding only the handful that break a CSS url() — angle brackets, hashes, percent signs — produces a shorter string than Base64 of the same file. The markup is single-quoted so the double quotes inside it survive.
Does it handle every SVG file?
It handles SVG markup, which is what an .svg file contains. It reads the file as XML tokens rather than building a full DOM, so an SVG with a malformed tag is passed through rather than repaired — run it through the XML Formatter first if you are not sure it is well-formed.

Related tools