SVG-Markup wird geparst, bereinigt und in der Vorschau gezeigt. Das Bereinigen ist der entscheidende Teil: Ein SVG ist ein Dokument und nicht bloß ein Bild, und es kann Skripte, Event-Handler und externe Verweise mitführen, die ausgeführt werden, sobald es in eine Seite eingebettet wird. Alles dieser Art wird entfernt und im Ergebnis benannt, damit Sie genau sehen, was entfernt wurde, statt darauf zu vertrauen, dass etwas entfernt wurde.
Das bereinigte Markup wird anschließend minifiziert — überflüssiger Leerraum, Editor-Metadaten und unnötige Genauigkeit entfallen — und die Ersparnis wird gemeldet. Das zählt, weil aus Designprogrammen exportierte SVGs regelmäßig ein Vielfaches des Markups mitführen, das die Grafik braucht, überwiegend Kommentare und Ebenennamen, die niemand je lesen wird.
Warum ein SVG überhaupt bereinigt werden muss
-
Ein eingebettetes SVG läuft im Kontext Ihrer Seite:
Ein Skript darin hat denselben Zugriff wie jedes andere Skript der Seite. Deshalb ist ein von Nutzern hochgeladenes SVG ein echtes Sicherheitsthema, ein JPEG nicht.
-
Als Bild einzubinden ist sicherer als einzubetten:
Ein per img-Tag referenziertes SVG kann keine Skripte ausführen. Es ins HTML einzubetten schaltet Gestaltung und Animation frei — und eben auch das Risiko.
-
Designprogramme exportieren viel Rauschen:
Ebenennamen, Editor-Metadaten, Koordinaten auf zehn Nachkommastellen. Nichts davon wird gezeichnet, und oft macht es den größten Teil der Datei aus.
-
Prüfen Sie die Vorschau nach dem Minifizieren:
In der überwiegenden Mehrzahl der Fälle ist Minifizieren unbedenklich, aber ein SVG, das auf ungewöhnlicher Struktur beruht, kann sich ändern. Sehen Sie es an, bevor Sie es ausliefern.
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.