Aller au contenu
DevTools / Compresseur SVG

Compresseur SVG

An SVG exported from a drawing tool carries far more than the artwork. Illustrator, Inkscape, Sketch and Figma all embed their own namespaces, layer names, editor state and generator comments, and a typical icon arrives at three to ten times the size it needs to be. This compressor removes that overhead — metadata, comments, unused ids, default-valued attributes, whitespace and coordinate precision — and reports the raw and gzipped size before and after, because for SVG it is the gzipped figure that actually crosses the network.

Fonctionne entièrement dans votre navigateur — rien n'est envoyé.

ou déposez un fichier ici
Entrée — 1.80 KB
Sortie — 0 B

Optimisations

Generator banners and licensing blocks written as XML comments.

<metadata>, <title>, <desc> and <sodipodi:namedview>.

inkscape, sodipodi, sketch, figma, adobe, RDF and friends.

xml:space, enable-background, version, data-name.

fill-opacity="1", stroke-linecap="butt" and other no-ops.

Groups and defs with no geometry left inside.

Only runs when nothing in the file points at the id.

Whitespace between tags carries no meaning in SVG.

Trims 48.1234567 to the precision below.

Re-indents for reading. Adds bytes back.

Preview

Rien à afficher pour l'instant

Rendered through an <img> element, so embedded scripts cannot run.

SVGZ and every modern HTTP server already gzip SVG; the gzipped figure is what actually crosses the wire.

Comment ça marche

An SVG file is XML, so everything XML allows is legal in it: comments, processing instructions, namespace declarations, metadata elements and arbitrary attributes in foreign namespaces. A renderer ignores nearly all of that. The Inkscape namespace declaration, the sodipodi named-view element, the Adobe generator comment, the layer labels and the RDF metadata block together account for the majority of a typical exported file and affect nothing that is drawn. Removing them is the single largest saving available and it is entirely safe.

Attribute-level cleanup is the second pass. Many attributes are written out at their default value — fill-opacity of 1, stroke-linecap of butt, stroke-width of 1 — and a default value is by definition what the renderer uses when the attribute is absent, so removing it changes nothing. Noise attributes such as xml:space, version and enable-background are either obsolete or never consulted. Unreferenced ids are removed only when nothing in the file points at them, since an id is a target for url(#) references in fills, clips, masks and filters, and deleting a referenced one breaks the graphic.

Coordinate precision is where a file can lose a surprising amount of weight with no visual consequence. A path produced by a vector editor routinely carries six decimal places, so a coordinate reads 48.1234567 when 48.12 would render identically at any size a screen can display. Rounding to two decimals typically halves the length of a path's data attribute. Specifying a precision below two is possible and occasionally useful for a large illustration, but the artefacts become visible on curves at one decimal place or fewer.

Gzip is why the raw percentage understates the real gain. Because SVG is text, HTTP servers compress it, and the redundancy in the verbose form means the compressed size is often closer to the optimised size than the raw figures suggest — a file that shrinks by 70 percent raw may shrink by only 40 percent on the wire. Both numbers are reported so the actual benefit is visible rather than assumed. The one case where raw size is what matters is the asset inlined directly into an HTML document, where no separate compression applies, and there the raw saving is the whole saving.

Cas d'usage courants

  • Strip editor metadata from icons exported from Figma or Illustrator before committing them.
  • Reduce the weight of an inline SVG logo that sits in the critical path of a page load.
  • Clean up an SVG before embedding it in an email template or a PDF pipeline.
  • Check how much of a file's size is real artwork and how much is tooling overhead.
  • Round path coordinates on a map or chart SVG generated programmatically at excessive precision.
  • Produce a compact SVG to paste directly into an HTML or JSX file.

Dernière mise à jour: 2026-10-14 — le corps de l'article est affiché en anglais ; l'interface est traduite.

Questions fréquentes

Will optimising break my SVG?

The default settings preserve everything that affects rendering, and the risky operations are opt-in. Unreferenced ids are removed only after scanning the whole file for url(#), href=# and aria-labelledby references, so a gradient, clip path or filter target is never deleted. Coordinate rounding is visually lossless at two decimal places. The one operation worth reviewing is pretty-printing, which adds bytes back and changes nothing else, and the preview renders the optimised output through an img element so you can compare it against the original before using it.

Why does the gzipped saving look smaller than the raw one?

Because gzip already removes much of the redundancy that the optimiser removes. Verbose markup with repeated attribute names and long namespace URLs compresses very well, so the compressed size of an unoptimised file is often closer to the compressed size of the optimised one than the raw sizes suggest. Since HTTP servers compress SVG automatically, the gzipped comparison is the honest one for a file served over the network. The raw comparison is what matters for SVG inlined directly into HTML, where no compression step is applied.

Is it safe to remove ids?

Only when nothing references them, which is what the reference scan checks. An id in SVG is not just a label: url(#gradient) in a fill, url(#clip) in a clip-path, href="#symbol" in a use element and aria-labelledby for accessibility all point at ids, and removing a referenced one silently breaks the graphic or its accessibility tree. This tool collects all of those references before deciding, and keeps the ids on container elements such as g and defs regardless, since generated code frequently targets them.

Does the preview execute scripts inside the SVG?

No. The optimised output is rendered through an img element, and browsers deliberately do not execute scripts or load external resources inside an SVG referenced that way — it is treated as a static image. That makes the preview safe even for a file of unknown origin. It also means a preview cannot show you what an interactive or animated SVG would do, which is a real limitation if the file contains scripted behaviour, though such files are unusual as assets.

Outils associés