Optimiseur SVG, gratuit

Comment ça marche

1. Collez ou importez un SVG : saisissez le balisage SVG directement ou importez un fichier .svg exporté depuis Illustrator, Figma ou Sketch.
2. Configurez les passes d'optimisation : choisissez quelles optimisations appliquer, suppression de commentaires, retrait de métadonnées, simplification des tracés et normalisation du viewBox.
3. Optimisez : l'outil exécute les passes choisies et affiche le pourcentage de réduction de taille.
4. Téléchargez ou copiez : enregistrez le SVG optimisé ou copiez le balisage pour le coller dans votre code.

Pourquoi optimiser vos SVG ?

Les fichiers SVG exportés depuis les outils de design sont pleins de données inutiles, métadonnées d'éditeur, déclarations de style en ligne aux valeurs par défaut, groupes vides, attributs de transformation redondants et commentaires. Ce surplus augmente la taille sans rien changer au rendu. SVGO (l'optimiseur SVG standard de l'industrie utilisé ici) peut généralement réduire la taille de 50 à 80 % tout en préservant un rendu au pixel près. Des SVG plus petits chargent plus vite, s'intègrent plus rapidement en HTML et réduisent la bande passante, particulièrement important pour les systèmes d'icônes qui chargent des dizaines de SVG par page.

Optimisations appliquées

• Commentaires supprimés: commentaires de générateur et d'éditeur retirés
• Métadonnées retirées: éléments title, desc et XMP
• Groupes vides fusionnés: éléments <g> d'enveloppe inutiles retirés
• Tracés simplifiés: commandes de chemin redondantes fusionnées et raccourcies
• Attributs nettoyés: valeurs par défaut et attributs de présentation retirés
• ViewBox normalisé: système de coordonnées cohérent

Brève histoire de SVG et SVGO

Scalable Vector Graphics est né d'une compétition entre deux propositions W3C : Precision Graphics Markup Language (PGML) d'Adobe, IBM, Netscape et Sun, et Vector Markup Language (VML) de Microsoft. Tous deux ont été soumis en 1998 ; le compromis du W3C est devenu SVG, recommandé comme SVG 1.0 en septembre 2001. Internet Explorer a notoirement refusé d'inclure le support SVG jusqu'à IE9 (2011), tandis que Firefox, Safari et Opera l'ont supporté dès le milieu des années 2000. SVG 1.1 est apparu en 2003, avec une seconde édition en 2011. SVG Tiny 1.2 visait les appareils mobiles en 2008. SVG 2 a commencé à être rédigé vers 2016 mais a stagné ; aujourd'hui il reste un Candidate Recommendation Draft (dernière modification en 2018), avec les navigateurs implémentant les morceaux individuellement. L'optimisation est arrivée plus tard. SVGO a été créé par Kir Belevich (svg-go) et publié pour la première fois sur GitHub en octobre 2012, écrit en JavaScript. Il est devenu le standard de facto, intégré dans webpack-loader, Vite, Sketch, les plugins d'export Figma, et l'interface web SVGOMG de Jake Archibald (équipe Chrome) lancée en 2015. SVGO 3 (sorti en 2023) a modernisé le code. Cet outil implémente un sous-ensemble sûr des plugins les plus impactants de SVGO, fonctionnant entièrement dans votre navigateur.

Ce que fait réellement un optimiseur SVG

• Réduction de la précision décimale. Illustrator exporte les chemins avec 6 chiffres décimaux comme M127.348293. Trois décimales sont visuellement identiques pour les tailles d'icône typiques ; une ou deux suffisent souvent. SVGO utilise 3 décimales par défaut via le plugin cleanupNumericValues. Précision plus basse = fichier plus petit.
• Effondrer les groupes inutiles. Les outils de design enveloppent chaque opération dans des éléments <g> ; beaucoup deviennent vides après simplification. Le plugin collapseGroups fusionne les groupes à enfant unique dans leur parent.
• Supprimer les métadonnées. Illustrator marque chaque export avec des blocs <metadata>...</metadata> contenant des paquets XMP, Inkscape avec des attributs de namespace sodipodi, Figma avec des IDs d'éditeur. Rien de cela n'affecte le rendu. removeMetadata, removeEditorsNSData et removeXMLProcInst s'en occupent.
• Optimisation des commandes de chemin. Convertir les coordonnées absolues en relatives (souvent plus courtes), fusionner les segments de ligne consécutifs (l 5,0 l 0,5 reste à deux ; L 5,0 L 5,5 devient v 5), supprimer les Z inutiles après z. Le plugin convertPathData peut économiser 30-50 % sur les chaînes de chemin.
• Suppression des attributs par défaut. fill="black", stroke="none", stroke-width="1" sont des valeurs par défaut ; SVGO les supprime. Combiné avec mergeStyles, cela réduit souvent les exports avec styles inline de moitié.
• Raccourcissement des couleurs. #ffffff → #fff ; rgb(255,255,255) → #fff ; couleurs nommées (aliceblue) → hex si plus court. Le plugin convertColors.
• Suppression des IDs inutilisés. Les IDs générés par l'éditeur comme id="path-7423" ne sont généralement jamais référencés. Le cleanupIds de SVGO supprime les IDs orphelins et minifie le reste à a, b, c...

Où l'optimisation SVG compte

• Systèmes d'icônes. Une page avec 30 icônes SVG à 2 Ko chacune fait 60 Ko ; optimisées à 800 octets chacune cela économise 36 Ko. Heroicons, Lucide, Phosphor, Feather livrent tous des SVG pré-optimisés ; si vous les avez extraits d'un fichier de design, vous devez le faire vous-même.
• Logos et assets de marque. Les logos livrés aux clients font souvent 50-100 Ko depuis Illustrator ; optimisés ils font 5-10 Ko. Même fidélité visuelle, bande passante moindre, chargement plus rapide. Le SVG du logo Wikipedia est passé de 39 Ko à 11 Ko après une seule passe d'optimisation.
• SVG inline en HTML. Quand vous mettez le SVG en inline (pas de requête HTTP supplémentaire), chaque octet du SVG gonfle la charge HTML qui bloque le parseur du navigateur. Une icône de 200 octets vs 2 Ko compte pour le timing de premier rendu.
• Visualisation de données. D3.js, Observable, la sortie SVG d'ECharts et React-vis produisent de gros SVG avec des milliers d'éléments. Un nuage de points avec 5 000 points fait facilement 500 Ko brut ; optimisé il peut tomber à 150 Ko en restant identique.
• Génération de fontes d'icônes. Les outils comme IcoMoon, Fontello et Fontastic convertissent les SVG en fontes d'icônes. Pré-optimiser les SVG sources garantit une sortie de fonte plus propre et des fichiers de fonte plus petits.
• Assets d'impression et PDF. Intégrer du SVG dans un PDF (via des outils web-to-PDF comme Puppeteer, wkhtmltopdf) signifie que le bloat SVG finit dans le PDF final. Optimisez d'abord.
• SVG sûr pour email. De nombreux clients email (Outlook, certaines apps Gmail) ne rendent pas du tout le SVG ; pour ceux qui le font (Apple Mail, Gmail web), un SVG inline plus petit garde les emails sous le seuil de coupure Gmail de 102 Ko.

Erreurs d'optimisation qui cassent les SVG

• Supprimer des IDs qui sont référencés. Les SVG utilisent souvent <defs> avec des IDs référencés via url(#gradient-1) dans fill ou stroke. Une suppression agressive d'IDs casse les dégradés, masques, clip paths, filtres. Utilisez un outil qui suit les références, pas une regex aveugle.
• Supprimer les attributs width/height aveuglément. Cela supprime le ratio d'aspect naturel. Le résultat : <img src="icon.svg"> s'étire pour remplir son conteneur sans taille intrinsèque, causant du CLS (Cumulative Layout Shift). Gardez au minimum viewBox ; idéalement gardez aussi width/height.
• Réduction décimale trop agressive. Réduire à 0 décimale sur de petites icônes rend les chemins visiblement dentelés. 3 décimales est un défaut sûr ; descendez à 1 seulement pour les icônes plus grandes que 64×64 ou où la perfection au pixel n'est pas requise.
• Supprimer xmlns lors de l'inlining. Les fichiers SVG autonomes ont besoin de xmlns="http://www.w3.org/2000/svg". Le SVG inline en HTML n'en a pas besoin (le parseur HTML5 le gère), mais si vous pourriez extraire le SVG vers un fichier plus tard, gardez le xmlns. La confusion ici casse le rendu SVG de Safari.
• Remplacer currentColor par un fill codé en dur. fill="currentColor" est un hook CSS puissant : l'icône hérite de la couleur du texte. Les optimiseurs agressifs le remplacent par la valeur calculée, cassant le mode sombre et les systèmes d'icônes thématisés.
• Fusionner les chemins qui devraient rester séparés. Certaines animations ciblent des IDs de chemins spécifiques ; certains outils d'accessibilité s'appuient sur plusieurs éléments <path> avec du texte <title> individuel. Le plugin mergePaths détruit ceux-ci. Désactivez-le pour les SVG animés ou accessibles.
• Supprimer les <title> et <desc> accessibles. Les SVG utilisés comme images autonomes ou dans des balises <img> ont besoin de <title> pour les lecteurs d'écran (similaire au texte alt). Une suppression agressive des métadonnées enlève cela. Soit gardez les titres, soit ajoutez aria-label sur l'élément SVG inline.

Autres questions fréquemment posées

Combien l'optimisation SVG peut-elle vraiment économiser ?

Cela dépend fortement de la source. Les exports Adobe Illustrator rétrécissent souvent de 60-80 % au premier passage, principalement par suppression de métadonnées, namespaces d'éditeur et réduction de précision décimale. Les exports Figma sont plus propres prêts à l'emploi (typiquement 20-40 % d'économies). Le SVG écrit à la main par un développeur ? Souvent 5-15 %, car il n'y a pas grand-chose à supprimer. Le logo Wikipedia, cas extrême de bloat Illustrator, est passé de 39 Ko à 11 Ko. Une icône 24×24 typique de Figma passe de 1,4 Ko à 0,6 Ko.

Quand devrais-je inliner le SVG vs l'utiliser comme fichier externe ?

Inline (<svg>...</svg> en HTML) pour les petites icônes (sous 2 Ko), le contenu critique au-dessus de la ligne de flottaison, et partout où vous avez besoin de CSS pour styliser le SVG (par exemple currentColor, états hover, mode sombre). Fichier externe (<img src="icon.svg"> ou background-image CSS) pour les icônes identiques réutilisées (le navigateur met en cache), les illustrations plus grandes, le contenu qui n'a pas besoin de thématisation CSS. Sprite SVG (fichier unique avec plusieurs éléments <symbol>, référencés par <use>) était le pattern de système d'icônes de 2014-2019, désormais largement supplanté par les composants inline-svg dans React/Vue/Svelte.

Y a-t-il des risques de sécurité dans les SVG non optimisés ?

Oui. Le SVG peut intégrer des balises <script> et des gestionnaires d'événements onload, onclick ; les SVG uploadés par les utilisateurs sont un vecteur XSS. Le SVG peut référencer des ressources externes via <image href="...">, fuitant l'IP du spectateur. Les fontes SVG (dépréciées mais encore analysables) avaient historiquement des dépassements de tampon. Un bon optimiseur supprime les <script> et gestionnaires d'événements dans le cadre du nettoyage ; si vous acceptez les uploads SVG d'utilisateurs, passez-les par un sanitiseur durci (DOMPurify avec profil SVG) avant de servir.

Puis-je optimiser le SVG en ligne de commande ?

Oui. npx svgo input.svg -o output.svg utilise la bibliothèque canonique SVGO. Configurez les plugins via svgo.config.js. Intégrations CI : imagemin-svgo dans webpack, vite-plugin-svgo, GitHub Action antfu/svg-opt. Pour l'optimisation par lot : svgo -f ./icons -o ./icons-optimised. L'outil navigateur ici est plus rapide pour les actions ponctuelles et fonctionne sans Node installé.

Mon SVG est-il envoyé à un serveur quand j'optimise ici ?

Non. L'optimisation s'exécute entièrement dans votre navigateur via JavaScript sur le markup SVG que vous collez. Ouvrez l'onglet Network dans DevTools pendant l'optimisation ; vous verrez zéro requête sortante. Sûr pour les logos propriétaires, les designs d'icônes non publiés, les SVG d'entreprise internes, et tout ce qui est sous NDA.

Outils associés