An SVG is a document, not a picture
That is the whole reason this tool sanitises rather than only formatting.
A JPEG is data. A browser decodes it into pixels and nothing in the file can execute. An SVG is XML with a full document model: it can contain <script> elements, event handlers like onload and onclick, and references to external files. When an SVG is inlined into a page, all of that runs in the page's context, with the same access as any other script on the site.
The [msm_tool slug="svg-editor"] strips those and names what it removed, so you can see exactly what was in the file rather than trusting that something was taken out.
Why user uploads are the sharp case
If a site accepts SVG uploads — avatars, logos, illustrations — and serves them inline, an uploaded file can run arbitrary script for every visitor who views it. That is a real vulnerability class, not a theoretical one, and it has affected a number of well-known platforms.
Two defences, and you want both:
- Sanitise on upload. Strip scripts, handlers and external references server-side before the file is stored.
- Serve as an image, not inline. An SVG referenced by an
<img> tag cannot execute scripts. Inlining is what unlocks CSS styling and animation of the contents — and the risk along with it.
If you do not need to style the SVG's internals, use an <img> tag and the problem largely disappears.
What gets removed
- Script elements — the obvious case.
- Event handler attributes —
onload, onclick, onmouseover and the rest. These are easy to overlook because they sit inside otherwise innocent-looking elements.
- External references — a remote stylesheet, image or font. These leak the viewer's IP to a third party and can pull in content you do not control.
- foreignObject content, which allows arbitrary HTML inside an SVG.
Seeing the list is the useful part. An SVG exported from a design tool should contain none of these, so if the report is not empty, that is worth knowing about the file's provenance.
The minification is a separate benefit
Design tools export a remarkable amount of noise: layer names, editor metadata, generator comments, coordinates to ten decimal places, empty groups, unused definitions. On a simple icon this frequently accounts for most of the file.
None of it renders. Removing it commonly halves the size and sometimes does considerably better, which matters for icons that ship inline on every page.
Check the preview after minifying
Minification is safe in the overwhelming majority of cases. The exceptions are SVGs relying on unusual structure — nested groups with transforms that depend on their nesting, IDs referenced from elsewhere in your page, gradients defined in one place and used in another.
Look at the result before shipping it. It takes a second and it catches the rare case where something did depend on the noise.
Coordinate precision
Coordinates at ten decimal places describe a position to a fraction of an atom. Two or three is ample for anything drawn on a screen, and rounding them is usually the single largest saving in an icon file.
The exception is very large viewBoxes, where the same number of decimal places represents a coarser real distance. If a shape looks subtly wrong after minifying, precision is the first thing to check.
A note on the guidance elsewhere
Advice to "just use SVG, it is only an image" is common and wrong in this one respect. SVG is excellent — small, sharp, styleable — and it carries a security surface that raster formats do not. Sanitising anything you did not author yourself is the whole of the mitigation, and it is not onerous.