SVG Simplifier & Optimizer

Frequently Asked Questions

How much can it reduce file size?

Usually 40–80% on SVGs exported from Illustrator, 40–70% on Figma exports, 35–55% on Sketch, and 10–25% on hand-written SVG. The biggest wins come from Illustrator's metadata bloat, which the optimizer strips completely. You see the exact saving for your file in the result banner.

Will it change how my SVG looks?

No. Every default optimization is lossless: the rendered pixels stay identical. The preview on the right shows the cleaned SVG rendered with the same dimensions; use it to visually verify before downloading. If you ever see a difference, it means an aggressive option (e.g. very low numeric precision) is over-simplifying a path, so raise the precision.

What is the difference between SVG optimization and SVG minification?

Minification just strips whitespace and shortens attribute names. Optimization (what this tool does) also removes unused metadata, collapses paths, converts shapes to the smallest equivalent form, and rounds numeric precision. Optimization typically gives 3–5× bigger savings than minification alone.

Does it remove Illustrator / Inkscape / Figma metadata?

Yes, by default. It strips the <sodipodi:namedview> element (Inkscape), <inkscape:*> attributes, Illustrator's xmlns:a namespace, Figma-generated numeric IDs, and the "Generator" / "Created with" comments. These are all invisible to the browser but can make up 30–50% of an unoptimized SVG.

Can I keep the viewBox or the IDs?

Yes, both are toggles. viewBox is KEPT by default because removing it breaks CSS/HTML scaling. It only saves ~25 bytes, so turn it off only for a fixed-size SVG you never resize. IDs are DROPPED by default since they are usually Figma layer noise; turn 'Keep id attributes' on for SVG sprites or when your CSS/JavaScript selects nodes by id.

Is this the same as running SVGO from the command line?

Yes. It is SVGO v4 itself, the same library the CLI, webpack, Vite and svgr use, running in your browser instead of Node. With matching settings the output is byte-for-byte identical to `npx svgo input.svg`. The difference is convenience: no install, no config file, and a live preview of what each setting costs you.

Why does the tool show a gzipped size?

Because that is what actually travels to your users: every web server serves SVG with gzip or brotli compression. Raw byte savings can be misleading, because SVGO removes a lot of repetitive text that gzip was already compressing well, so a 70% raw reduction might be 45% after gzip. The gzipped figure is the honest measure of what you saved in load time.

What numeric precision should I use?

3 is the default and safe for essentially everything. Drop to 2 for icons and UI graphics, where it is usually invisible and worth another 10–15%. Drop to 1 or 0 only for small, simple shapes, and watch the side-by-side preview: at low precision, curves start visibly flattening. Large-canvas artwork (maps, detailed illustrations) may need 4 or more.

Can I recover the original SVG after optimizing?

No. The optimization is destructive by design: removed metadata, collapsed nodes and rounded coordinates cannot be recovered. Keep the original in version control before optimizing.

Is my SVG uploaded anywhere?

No. SVGO runs as JavaScript inside your browser tab. Your file is never uploaded to a server; you can confirm in the DevTools Network tab that no request fires when you optimize. This matters for logos and assets under NDA.

Can I optimize an SVG path specifically (svg path optimizer)?

Yes. Path-level optimizations are the single biggest source of bytes in most icons. The optimizer's path-focused plugins (convertPathData, mergePaths, removeUselessStrokeAndFill) reduce numeric precision (6 decimals to 2-3), merge consecutive `<path>` elements that share styles, convert absolute commands (`M L`) to relative ones (`m l`) when they're shorter, and drop redundant subpaths. Typical path savings: 30–60% of total file size on icon SVGs.

Does it work for SVG sprites and icon sets?

Yes, and it's especially useful for sprites because the savings compound across many icons. The optimizer can be run on individual icons before bundling, or on the assembled sprite file. For sprites, keep `cleanupIDs` disabled so your CSS / JavaScript selectors that reference per-icon IDs still work.

Is this an SVG simplifier, and does it reduce the number of points in a path?

No. It does not remove nodes. A path that arrives with 4,000 anchor points leaves with 4,000 anchor points. What it does is make each of those points cost fewer bytes: coordinates are rounded to your chosen precision, absolute commands become relative, redundant `L` segments collapse into `H` and `V`, and consecutive paths sharing a style are merged. On a traced or auto-generated path that is typically a 50–70% byte reduction with pixel-identical output. If you genuinely need fewer nodes, because the path came from an image trace and is heavy to animate or edit, that is curve refitting (Ramer–Douglas–Peucker), and it is lossy by definition: the shape changes slightly. Use Inkscape's Path → Simplify (Ctrl+L), Illustrator's Object → Path → Simplify, or the `simplify-js` library. Run that first, then bring the result here for the lossless byte pass. The two steps are complementary, not alternatives.

How do I simplify an SVG path with this tool?

Lower the precision slider. It is by far the biggest lever on path data. Design tools export coordinates at 6 decimal places (`M 12.847362 4.019283`), which is roughly a thousand times finer than any screen can resolve. Dropping to 2 decimals typically cuts path data by half on its own. As a rule of thumb: precision 3 is safe for anything (the default, visually lossless at any zoom), precision 2 is right for icons and logos rendered under ~200 px, and precision 1 works for small monochrome UI icons but can start to visibly shift curves. Turn on multipass so the pipeline re-runs until the output stops shrinking; on complex paths that finds another 3–8% the first pass misses. The side-by-side preview updates live, so lower the value until you can see a difference, then go back one step.

Is this SVGO online?

Yes. It runs the real SVGO v4 inside your browser tab instead of in Node: the same library you would install with `npm i -D svgo`, the same plugin pipeline, the same `preset-default`, the same output for the same input. The only difference is where the code executes. There is no server, so nothing is uploaded and it works offline once the page is cached. If you already have an `svgo.config.js` in a project, the settings here map onto the plugins it configures.

How does this compare to SVGOMG?

SVGOMG is Jake Archibald's tool and the reference implementation. If you know it and like it, keep using it. Both run SVGO in the browser and produce near-identical output, because both delegate to the same library. Where this one differs: it shows the gzipped size alongside the raw size, which is the number that actually travels over the wire and is often a very different story (a 40% raw saving can be 15% gzipped, because gzip was already collapsing the repetition SVGO removed). It also exposes precision as a single slider rather than a per-plugin list, which is faster when precision is the only knob you actually want to turn. SVGOMG exposes more individual plugin toggles and has a nicer drag-and-drop demo set. Neither uploads your file.

Can it repair a broken SVG?

Only in a narrow sense. SVGO has to parse your file before it can do anything, which means the XML must be well-formed: an unclosed tag or a stray `&` will make it fail outright rather than fix it. It is an optimizer, not a recovery tool. What it does reliably clean up: editor cruft that breaks rendering elsewhere (Illustrator's `<foreignObject>` wrappers, Figma's empty groups and clip paths), duplicate or colliding IDs that break a page when two inlined SVGs share them, and missing-viewBox scaling problems. What it will not do: reconstruct malformed markup, recover a truncated file, or convert an embedded raster back into vectors. For genuinely broken XML, open the file in a text editor and fix the parse error first. The browser console will usually point at the exact line.