SVG Optimizer — make vector graphics smaller & faster

What does this tool actually do?

You drop an SVG file (or a folder of them, in bulk mode), the tool runs it through a specialised SVG optimiser and shows you the result: a smaller source, a render preview against the original, and the byte savings. The optimisation happens in your browser via a WebAssembly-free, pure-JavaScript optimiser engine — no upload, no account, no tracking. Output: a single optimised file or a ZIP archive when you batched several. The interface is intentionally narrow: four presets, a Custom mode for power users, and two output toggles (pretty-print and multi-pass). Everything else lives behind the Custom toggle list so first-time users aren’t drowned in twenty checkboxes.

The size win you should expect varies dramatically with how the SVG was authored. A hand-coded path with three-decimal coordinates and no decoration shrinks by 5–15 %. A logo exported from a vector design tool with editor namespaces, comments, metadata, and eight-decimal precision routinely drops 60–80 %. A workflow that round-trips an SVG through a screen-recording tool and an editor can produce files that are 90 % overhead — we’ve seen 200 KB icons collapse to 25 KB without a single pixel changing in the render.

Why optimise SVGs at all in 2026?

Three reasons that all compound. First, first-paint performance: each kilobyte of inline SVG is a kilobyte that delays your hero rendering. Modern sites inline 8–20 icons in their navigation alone; trimming 3 KB per icon shaves 60 KB off the critical-path payload. Second, gzip ratio: optimisers sort attributes alphabetically (sortAttrs), which improves compressor windows — the optimised SVG isn’t just smaller raw, it gzips better too. Third, build pipeline integration: SVGs that pass through this tool already have their editor-junk stripped, so downstream tooling (icon-font builders, sprite generators, framework loaders) gets cleaner input.

There’s also a privacy angle that surprises people. Design-tool exports often embed user metadata in the SVG: the author’s user-account name, the file path on their local disk, the editor’s working timestamp, sometimes even unrelated reference images encoded as data URIs. Strip the comments and metadata and that information stops shipping with your asset. The same hygiene argument applies to publishing a public logo from an internal corporate workflow — the export shouldn’t carry your laptop’s user folder structure.

How do the four presets differ?

Web is the default and the most aggressive — what most people want for icons and illustrations destined for the browser. It strips comments, metadata, titles, descriptions, editor namespaces, the DOCTYPE, and the XML prolog. It shortens IDs, rounds numeric values to three decimals (mostly invisible at icon sizes), shortens colours (#ffffff → #fff, rgb(255,0,0) → red), converts shapes to paths where the byte count benefits, merges paths, and collapses redundant transforms and groups. It will not remove the viewBox; intrinsic sizing matters too often to risk that silently. Expect 40–80 % reduction on typical design-tool exports.

Figma-safe keeps the IDs intact. Vector design tools reference shapes by id when you set up symbol variants or component overrides; renaming the IDs in a round-trip-imported SVG breaks the variant wiring. It also keeps <title> and <desc> (accessibility) and skips path merging (Figma re-imports each path as a separate object — merged paths flatten the layer panel). Expect 30–60 % reduction.

Editor-safe is the round-trip preset for SVGs that you’ll keep editing in a vector graphics editor. It preserves comments, editor namespaces, IDs, titles, descriptions, layer markers — anything an editor might need to reconstruct its working state. It only runs the safest minifications: attribute cleanup, numeric rounding, colour shortening, and attribute sorting. Expect 5–20 % reduction. Use this when you’re optimising assets in a working folder, not the production export.

Custom lets you tick exactly which optimisations to run. The list is shown in a two-column grid with descriptive labels (no plugin names — just what the optimisation does to your SVG). The starting state matches the Web preset; you can untick individual items, switch on advanced toggles like “remove viewBox” or “remove width/height”, and re-run as many times as you want. This is the mode you reach for when you’ve isolated a regression: untick the one optimisation that broke the icon and re-run.

What’s the side-by-side preview for?

Visual regression is the failure mode that aggressive SVG optimisation hides best. A path that looked fine at 24 px starts to wobble at 96 px because three-decimal rounding pushed a control point off its anchor. A gradient that referenced a missing stop renders solid black instead of the intended fade. A clipPath that depended on an ID got renamed and now the clip clips nothing. None of these break the SVG; they all change how it renders.

The preview renders both versions inside an isolated sandbox. You see the before on the left, the after on the right, scaled to fill the same box. Mouse over to compare details. If the optimised version looks different, the fix is usually one of: switch to a less aggressive preset, raise float precision in Custom mode, or untick the specific optimisation that caused the diff (e.g. removeViewBox, convertShapeToPath, cleanupIds). The preview never modifies your source — it’s a pure render-side comparison.

How does the bulk mode work?

Drop or pick multiple SVG files at once. The tool reads each into memory, applies the active preset to each, and shows you a per-file list with the size delta. An aggregate batch summary above the list shows total bytes saved, weighted reduction percentage, and total optimisation time. You download all the optimised files as a single ZIP archive, or copy individual sources, or download one at a time.

Bulk mode is the right path when you’ve inherited an icon library or a folder of illustrations and need to onboard them into a clean state. The web preset on a 200-icon library typically saves 60–80 % of the total bytes — that’s a noticeable Lighthouse-score improvement for any site that ships them inline. Per-file outliers (an SVG that didn’t shrink, or grew slightly) are flagged in the list so you can spot-check them; usually they’re already-minified inputs that have nothing left to strip.

What does the network tab show while the tool optimises?

Open DevTools, switch to the Network tab, drop a 1-MB SVG into the tool, and watch. You’ll see zero outbound requests for the optimisation itself. The optimiser engine is loaded once (after the page first becomes idle, via dynamic import) and cached by the browser; subsequent files use the in-memory module. We don’t ship analytics, we don’t ping a logging endpoint, and we don’t use the Background Sync or Reporting APIs that some tools use to exfiltrate data quietly.

This isn’t a marketing claim, it’s a verifiable property of how the page is built. The optimiser is a JavaScript module that runs in your tab; SVG sources are read with the browser’s FileReader API; outputs are constructed in memory and written into Blob URLs that the browser keeps local until you close the tab. We use no IndexedDB persistence, no Service Worker storage of your files, and no clipboard hooks beyond an explicit “copy” button you press.

When is this tool not the right pick?

A few cases where you should reach for a different tool. SVG→PNG rasterisation: this tool optimises SVG-as-SVG, it doesn’t render to PNG. Path simplification (Ramer-Douglas-Peucker): this tool tightens path coordinates but doesn’t change the path topology. Bitmap-to-SVG vectorisation: that’s a different problem entirely. Editor-grade interactive editing: this is a one-shot optimiser, not a working canvas. WebP/AVIF conversion: see our image-format converter for raster formats and our image resizer for dimensional changes.

What this tool is great at: shipping clean, small, predictable SVG icons into your production build without losing fidelity, without uploading anything, and without learning a CLI. If you’re already comfortable on the command line, the same optimisation engine ships as a CLI tool — but for the workflow where you’ve got 17 logos in a Slack thread and need them clean by lunch, the browser version is faster.

How does SVG optimisation fit into a build pipeline?

You have three common integration points. At authoring time (this tool, or the equivalent CLI run on a folder once): you optimise SVG before it enters version control, so every commit ships clean source. This is the lowest-friction option for icon libraries that change rarely. At build time (a CLI invocation in your package.json postinstall or build script): you keep the source verbose for editor-friendliness and strip on the way to production. This works well when designers regularly hand off updates and you want to keep the source close to what they exported. At request time (a server middleware that optimises on the fly): rare, generally overkill — the savings don’t outweigh the CPU cost of optimising the same icon on every request.

This tool fits the first integration point exactly: an occasional manual pass that produces production-ready SVG. The output you copy or download is the same byte sequence a CLI optimisation would produce with the same plugin selection, so you can pre-optimise in the browser and commit the result without your CI doing it again. The web preset matches the most common CLI defaults, the Custom mode is exhaustively listed, and the visual diff confirms there’s no surprise before you commit.

What does the size-reduction percentage actually measure?

The percentage above the output represents (original_bytes - optimised_bytes) / original_bytes, calculated on UTF-8 encoded byte length. This is the file size you would write to disk or ship to a browser, not the in-memory representation. For inline SVGs in HTML, this is also the exact byte savings on the document download — every byte you save here is a byte less that the browser has to parse before rendering your icon.

The percentage doesn’t capture two important things. First, gzip ratio improvements: by sorting attributes alphabetically and normalising whitespace, the optimised SVG often compresses better than the raw size delta suggests. Empirically this adds another 10–20 % on top of the raw reduction once gzip is applied. Second, parse-time savings: a smaller SVG with merged paths is faster for the browser’s SVG renderer to parse and paint. We don’t measure parse time here (it’s machine-specific) but the relationship is monotonic — smaller SVGs render faster.

Where can you find the standard and more background?

• W3C SVG specification — the standard the optimiser is faithful to.
• MDN SVG tutorial — how SVGs render in browsers and which attributes browsers respect.
• Wikipedia: Scalable Vector Graphics — historical context and format overview.

Optimise an SVG, watch the byte counter drop, ship a smaller bundle. No upload, no account, no tracking — verifiable in your browser’s DevTools.