The practical answer: keep the viewBox and all geometry needed for the artwork, remove editor metadata, comments and redundant structure, and reject scripts, event handlers and external resources. Compare the rendered result before and after; an optimised SVG should remain vector SVG.
How SVG differs from raster images
JPEG, PNG and WebP usually store coloured pixels. SVG is XML-based markup describing paths, shapes, text, gradients and transformations. It can scale cleanly because the browser redraws those instructions at the requested size.
SVG optimisation therefore focuses on markup and geometry, not a photographic quality slider. Rasterising an SVG may create a smaller file for one complex illustration, but it removes resolution-independent vector output and is a conversion, not SVG optimisation.
The image-format comparison explains when genuine vector artwork is preferable to a raster delivery format.
Preserve the viewBox and responsive scaling
The viewBox defines the internal coordinate system and visible bounds. Removing or changing it without understanding the artwork can crop shapes or break responsive scaling. The width and height attributes provide an intrinsic display size; CSS can still resize an SVG responsively when the viewBox is correct.
<svg viewBox="0 0 240 80" width="240" height="80" xmlns="http://www.w3.org/2000/svg">
...vector paths...
</svg>Do not delete dimensions mechanically. Decide whether the SVG needs a stable intrinsic ratio, explicit size, or responsive CSS behaviour in its real destination.
What can often be removed safely
| Candidate | Typical decision | Check first |
|---|---|---|
| Editor metadata | Remove when not required downstream | Whether another design tool relies on it |
| Comments | Remove for delivery copies | Whether licences or production notes must remain |
| Whitespace and redundant decimals | Minify carefully | Whether rounding changes geometry |
| Unused definitions or groups | Remove only after reference analysis | IDs, masks, gradients, clips and CSS selectors |
| Repeated attributes | Consolidate when rendering is equivalent | Inheritance and selector behaviour |
Keep an editable master. A delivery-optimised file can be harder for a designer to modify even when it renders identically.
Scripts, event handlers and external resources are security concerns
SVG is a document format, not merely a passive collection of pixels. It can contain script elements, attributes such as onload, links and references to external resources. Untrusted SVG should be treated as active markup and sanitised with a strict allow-list before display or conversion.
- Remove executable script elements.
- Remove event-handler attributes such as
onclickandonload. - Reject external URLs and unexpected resource references.
- Validate namespaces, elements and attributes rather than relying on the file extension.
- Apply an appropriate Content Security Policy as an additional boundary, not as a substitute for sanitisation.
Why complex SVG artwork may not shrink dramatically
A logo made from a few paths may become extremely compact. A traced photograph can contain thousands of points, filters, masks and gradients; its geometry is genuine content rather than removable overhead. Excessive point reduction or decimal rounding can bend curves, create gaps and change alignment.
Simple icon
Removing editor metadata, comments and redundant wrappers can produce a substantial percentage saving.
Detailed map or illustration
Most bytes may be required path data. A modest safe saving is better than visibly damaged geometry.
A safe SVG optimisation workflow
- Keep the editable source and work on a delivery copy.
- Reject malformed or active content before optimisation.
- Preserve the viewBox, referenced definitions and meaningful accessibility data.
- Remove confirmed metadata, comments and structural overhead.
- Render at several sizes and compare edges, fills, masks, text and transparency.
- Confirm the downloaded result is still SVG markup.
Common mistakes include deleting the viewBox, removing IDs that gradients or CSS still reference, rounding coordinates too aggressively, treating external resources as harmless, and calling a raster PNG output an optimised SVG.
If you genuinely need a pixel copy, use Convert Images to create JPG, PNG or WebP output after safe SVG handling.
Frequently asked questions
Does SVG optimisation reduce image quality?
Safe structural cleanup should preserve the rendered artwork. Aggressive coordinate rounding, path simplification or removal of referenced elements can change it, so visual comparison is essential.
Should an SVG optimizer remove the viewBox?
Usually no. The viewBox defines the internal coordinate system and aspect ratio used for responsive scaling; removing it can change sizing or crop artwork.
Can SVG files contain malicious code?
Yes. SVG can include scripts, event handlers and external references. Treat untrusted files as active markup and sanitise them with strict validation.
Why is my optimised SVG only slightly smaller?
Complex paths, filters and gradients may be essential artwork data. Once metadata and redundant structure are removed, there may be little safe overhead left.