How much smaller should an SVG get?

It depends entirely on how much cruft the export carried. A design-tool export with namespaces, metadata, and six-decimal coordinates commonly drops 60 to 70 percent — our realistic test icon went from 1,756 bytes to 552 with the default SVGO preset. A clean hand-written SVG might only lose 10 to 20 percent, because there's little left to remove. If a tool claims 90 percent, it's usually comparing against a file that was mostly metadata to begin with.

Is it safe to remove the viewBox from an SVG?

No — the viewBox is the scaling contract. It defines the coordinate system that width and height then display at any size; strip it and the SVG renders at a fixed intrinsic size in some contexts or refuses to scale in others. SVGO disables its removeViewBox plugin by default for exactly this reason. The attributes that can safely go are width and height — once a viewBox exists and CSS or the parent element controls sizing.

What does SVG path precision actually cost?

Almost nothing visually, a lot in bytes. Six decimals (40.123456) is design-tool output; three decimals (40.123) is the default optimization target and differs by less than a thousandth of a coordinate unit — invisible at icon and illustration sizes. Two decimals is fine for large artwork; one decimal can visibly nudge curves on small detailed icons, so compare a preview before shipping it.

Should I optimize SVGs used inline in HTML?

Yes, and more aggressively than files loaded via img tags. Inline SVG shares the page's HTTP budget as text, so every byte counts double; dropping width and height (letting the viewBox plus CSS size it) is standard practice inline; and you can go one step further by stripping the xmlns attribute, which HTML parsers don't require in that context. Just keep IDs unique per page when inlining multiple optimized files, since ID minimization can collide across inlined copies.

How to Optimize SVG Files

⚡ Web performance⏱️ 7 min readFree tool included

SVG is the format that promises infinite scalability and then ships a 12-kilobyte icon. The gap between promise and payload is almost never the drawing — it's everything the export tool packed around it. Optimization is the discipline of closing that gap without changing a pixel.

Where the bytes actually are

Open a design-tool export in a text editor and the picture is immediate. Before the first path, you'll find an XML declaration, a DOCTYPE, generator comments, editor namespaces (inkscape:, sodipodi:, sketch:), a metadata block, and often a namedview element recording the author's zoom level. Inside the drawing: wrapper groups for layers that no longer matter, an empty group or two, unused gradients and clip paths still sitting in defs, and coordinates written to six decimal places. On a realistic export we use for testing — a simple delivery-truck icon — that invisible cargo accounts for the majority of 1,756 bytes. The drawing itself is tiny.

That's why honest optimization numbers vary so much. The same default SVGO preset that removes 68.6 percent from that editor icon (1,756 → 552 bytes) might remove 15 percent from a cleanly hand-written file. The percentage reflects the export's hygiene, not the optimizer's quality — a claim of "90% smaller!" usually means the input was mostly metadata to begin with.

Phase one: remove what nobody renders

The safe half of optimization deletes things no renderer uses: XML declarations, comments, editor namespaces and their elements, metadata, empty containers, and unreferenced defs. It's risk-free by construction — if nothing references it, nothing misses it. One nuance: "unused" means unreferenced by ID, so a gradient applied through a style attribute survives even when it looks orphaned to a human. The engine resolves references; you don't have to.

Phase two: shrink what remains

Then the visible weight. Three moves do most of the work:

Precision truncation. 40.123456 becomes 40.123. Three decimals is the sweet spot — the dropped digits are thousandths of a coordinate unit, far below a pixel at icon sizes.
Absolute to relative. M 40.123 180.235 L 200.346 180.235 becomes M40.123 180.235h160.223 — the horizontal run is one number instead of two coordinate pairs.
Shape merging. Adjacent paths sharing paint collapse into one path with multiple subpaths; the truck test icon's two rectangles become a single d attribute, saving a whole element's worth of markup.

The dial that can bite is precision. At one decimal, fine curves on small icons can visibly shift — which is why it's an option next to a preview, not a default. If the before/after previews match, ship it; if they don't, step precision back up.

The rules worth memorizing

Attribute	Keep or drop	Why
`viewBox`	Always keep	The scaling contract — remove it and responsive sizing breaks
`width`/`height`	Droppable	Redundant once viewBox + CSS sizing exist (safe inline, risky for email)
`<title>`	Keep	Accessibility name; screen readers announce it
`xmlns`	Keep in files	Required when loaded as an image or opened standalone; droppable inline in HTML
IDs	Minimize carefully	Reference-preserving, but two inlined optimized files can collide on `id="a"`

Does the usage context change the settings?

Yes, and this is where generic advice goes wrong. Inline in HTML: optimize aggressively — the bytes ride in the page itself, width/height can go, and even xmlns is droppable. Watch ID collisions when inlining several files. Via <img> or CSS background: keep xmlns and standalone validity; scripts inside won't run (browsers isolate img-loaded SVGs). Sprites (symbol/defs sheets): optimize each icon first, assemble second — optimizing the sprite afterward can renumber IDs that the use references depend on. Email: keep explicit width and height; several clients ignore CSS sizing and render at intrinsic size otherwise.

When not to optimize

Files under active design revision, for one — re-exporting over optimized files loses nothing but confuses diffs, and editors re-add their cruft anyway, so optimize at build time, not at edit time. Hand-tuned paths for another: an animator's carefully placed coordinates or a font's glyph outlines may rely on precision the optimizer will happily truncate. And remember SVGO is an optimizer, not a sanitizer — it preserves scripts and event handlers, so never inline an SVG from an untrusted source without sanitizing it first, whatever its size.

Optimize an SVG right now

Paste your SVG, pick safe or aggressive, compare the before/after preview, and download the lean version. SVGO runs in your browser; nothing uploads.

SVG Optimizer →

The bottom line

Most SVG bloat is export debris, not drawing. Strip the invisible (metadata, namespaces, empty groups), shrink the visible (precision, relative paths, merged shapes), never touch the viewBox, and match your aggressiveness to the usage context. Our SVG Optimizer runs the real SVGO engine in-browser with previews and verified numbers; for adjacent jobs there's the Image Compressor for raster formats and the Favicon Generator when the icon is destined for a browser tab.