Visualiseur SVG, gratuit

Prévisualisez et inspectez des fichiers SVG avec des informations détaillées.

Vos données ne quittent pas votre appareil
Importer un fichier SVG

ou glisser-déposer

À propos du SVG

Le SVG (Scalable Vector Graphics) est un format XML pour les graphismes vectoriels. Contrairement aux formats matriciels (PNG, JPG), les images SVG s'adaptent parfaitement à toute taille sans perte de qualité. Ils sont légers, accessibles et largement pris en charge par les navigateurs modernes.

Questions fréquentes

Qu'est-ce que le SVG ?

Le SVG (Scalable Vector Graphics) est un format de graphismes 2D qui utilise des courbes et des tracés mathématiques au lieu de pixels. Cela rend les fichiers SVG indépendants de la résolution, ils restent nets à toute taille, des petites icônes aux panneaux d'affichage.

Quelle est la différence entre SVG et PNG ?

Le PNG est matriciel (basé sur les pixels) et a une taille fixe, l'agrandir provoque du flou. Le SVG est vectoriel (basé sur des mathématiques) et s'agrandit à l'infini sans perte. Le SVG est idéal pour les logos, icônes et illustrations. Le PNG convient mieux aux photos et images complexes.

Puis-je modifier le code SVG directement ?

Oui, le SVG est du texte XML, vous pouvez donc l'éditer dans tout éditeur de texte. Vous pouvez changer couleurs, tailles, positions et plus en modifiant les attributs. Utilisez ce visualiseur pour coller votre code et voir les changements instantanément.

Le SVG a remporté la guerre des formats, deux fois

Avant l'existence du SVG, deux formats vectoriels concurrents ont été soumis au W3C début 1998. PGML (Precision Graphics Markup Language), soumis le 10 avril 1998 par Adobe, IBM, Netscape et Sun, était enraciné dans le modèle d'imagerie PostScript d'Adobe. VML (Vector Markup Language), soumis le 13 mai 1998 par Microsoft, Macromedia, Hewlett-Packard, Autodesk et Visio, utilisait une syntaxe proche de ce que Microsoft livrait déjà dans Office 2000 et Internet Explorer 5. Le W3C n'a pas choisi de vainqueur. Il a plutôt formé un groupe de travail SVG présidé par Chris Lilley pour concevoir une norme unique qui supplanterait les deux. Le premier brouillon de travail public du SVG est paru le 11 février 1999.

SVG 1.0 a été publié comme recommandation du W3C le 4 septembre 2001, avec l'éditeur Jon Ferraiolo (Adobe) et des contributeurs d'Adobe, IBM, Sun, Apple, Canon, Corel, Kodak, Macromedia, Microsoft, Netscape, Oracle, Sharp, Quark et Xerox, l'une des plus larges coalitions de fournisseurs de toutes les spécifications du W3C. SVG 1.1 a suivi le 14 janvier 2003 et reste la base de facto du web moderne ; sa deuxième édition (16 août 2011) y a intégré des errata. SVG 1.1 a divisé la spécification en modules et défini trois profils (Full, Basic, Tiny). VML a continué d'être livré dans IE 5 à 9 et était utilisé en interne par Microsoft Office, mais a été déprécié dans IE 9 (mars 2011) au profit du SVG natif et était de fait mort dès IE 11. SVG 2 est un brouillon de travail du W3C depuis 2016 sans date de recommandation en vue ; les navigateurs en livrent les fonctionnalités au coup par coup à mesure que la demande d'interopérabilité se présente.

Ce qui rend le SVG véritablement différent

La prise en charge par les navigateurs est universelle depuis 2011

Le SVG natif est arrivé dans Firefox 1.5 (novembre 2005), Opera 9 (juin 2006), Safari 3.0 (juin 2007), Chrome 1.0 (septembre 2008), et enfin Internet Explorer 9 (mars 2011) : ce qui a été le point d'inflexion. Avant IE 9, les sites devaient livrer des cales (shims) de conversion VML ou le plugin Adobe SVG Viewer pour prendre en charge IE 6 à 8. Safari iOS avait un SVG partiel dès le lancement et une prise en charge complète à partir d'iOS 5 (octobre 2011) ; Android y est parvenu avec Honeycomb 3.0 (février 2011) et ChromeWebView a remplacé le navigateur AOSP vers Android 4.4 (2013). La borne inférieure pratique pour le SVG comme image (<img src="x.svg">) se situe à peu près fin 2011. D'ici 2026, aucun projet web réaliste n'a besoin de prendre en charge des navigateurs sans SVG complet.

Le SVG n'est pas qu'un format d'image, c'est un type de document exécutable

C'est la chose la plus importante à comprendre au sujet de la sécurité du SVG. Un SVG malveillant peut inclure des blocs <script>, des gestionnaires d'événements (onload, onclick, onmouseover), ou des liens <a xlink:href="javascript:...">. Lorsqu'un tel SVG est chargé dans un contexte actif (via <object>, <iframe>, une navigation du navigateur vers une URL .svg, ou via une insertion innerHTML), le navigateur exécute le script. Les sites qui autorisent l'intégration de SVG téléversés de cette façon peuvent subir une attaque XSS de la part des personnes qui les téléversent.

La balise <img> est la voie sûre. Lorsqu'un SVG est chargé via <img src="x.svg"> ou comme background-image CSS, les navigateurs exécutent le SVG dans un mode bac à sable, scripts désactivés et sans récupération externe. Les scripts à l'intérieur ne s'exécutent pas, les récupérations externes sont bloquées, et le SVG ne peut pas interagir avec la page parente. Le CSS à l'intérieur du SVG s'affiche, mais tout ce qui pourrait avoir des effets de bord est désactivé. C'est la façon recommandée d'utiliser le SVG aujourd'hui.

Pour la défense côté serveur, l'OWASP recommande d'assainir les SVG téléversés avec DOMPurify (DOMPurify.sanitize(svg, {USE_PROFILES: {svg: true}})), svg-sanitizer (PHP), sanitize-svg (Node) ou Bleach (Python), en supprimant <script>, <foreignObject> et tous les gestionnaires on*, et en rejetant les valeurs xlink:href qui commencent par javascript: ou data:. Définir une Content-Security-Policy stricte sur la page qui affiche le SVG de l'utilisateur et servir les SVG téléchargés avec Content-Disposition: attachment sont des précautions supplémentaires (ceinture et bretelles). Cette visionneuse est purement côté client et le SVG ne quitte jamais votre appareil, mais si vous intégrez du SVG fourni par l'utilisateur sur un site public, assainissez-le.

SVG, PNG, JPG, WebP ou AVIF : lequel utiliser et quand

WebP (Google, 2010) et AVIF (AOMedia, 2019) sont des formats raster modernes qui concurrencent le PNG et le JPG, pas le SVG : ils ne sont pas vectoriels. Le point faible du SVG, ce sont les photographies et les images en tons continus : représenter chaque pixel comme une primitive vectorielle gonfle le fichier bien au-delà d'un JPEG. Pour les cas des icônes et des logos, le SVG reste inégalé.

Optimiser votre SVG avec SVGO

Un SVG typique exporté depuis Adobe Illustrator, Sketch, Figma ou Inkscape comporte une surcharge énorme : des métadonnées propres à l'éditeur (<sodipodi:namedview>, <inkscape:groupmode>), des noms de calques et des hiérarchies de groupes par défaut, une précision excessive dans les coordonnées de tracé (d="M 12.000023 18.999991 ..."), des attributs de style en ligne qui pourraient être des classes CSS, des blocs de commentaires identifiant l'éditeur.

SVGO (SVG Optimizer), écrit à l'origine par Kir Belevich en 2012, est l'outil de référence du secteur. C'est un outil en ligne de commande Node.js doté d'environ 50 plugins gérant des optimisations individuelles : removeComments, removeMetadata, removeEditorsNSData, convertColors (transformant rgb(255,0,0) en #f00), convertPathData (réduisant les commandes de tracé et supprimant la précision redondante), mergePaths, cleanupNumericValues (arrondissant à une précision configurable, 3 décimales par défaut). La compression typique donne des fichiers de 30 à 70 % plus petits pour des SVG faits main issus d'outils de conception, atteignant parfois 80 % sur les exports d'Inkscape à cause des lourdes métadonnées de l'éditeur. SVGOMG (svgomg.net) est l'interface web de SVGO, par Jake Archibald (Google), et la version graphique la plus utilisée.

Le paysage des bibliothèques d'icônes

Les bibliothèques d'icônes SVG dominent la pile web moderne. Les grands jeux que vous croiserez sont Heroicons (Tailwind Labs, environ 280 icônes, MIT), Lucide (un fork de Feather, environ 1 400 icônes), Bootstrap Icons (environ 2 000), Material Symbols (Google, environ 3 000 réparties sur plusieurs graisses), Font Awesome 6 (environ 30 000 gratuites + Pro), Phosphor Icons (environ 9 000 réparties sur six graisses) et Tabler Icons (environ 5 200). L'agrégateur Iconify héberge plus de 200 000 icônes open source de plus de 150 jeux d'icônes derrière une seule API ; un développeur peut écrire <iconify-icon icon="mdi:home"></iconify-icon> et le framework récupère uniquement le SVG de cette icône à la demande. Le passage des polices d'icônes (l'ère de Font Awesome 4 / Glyphicons) aux icônes SVG s'est produit vers 2017-2019, porté par l'accessibilité, la recolorabilité et l'élimination du FOUT (flash de texte non stylé où la police d'icônes n'avait pas encore chargé).

Plus de questions

Quelle est la différence entre viewBox et width/height ?

viewBox="0 0 100 100" définit le système de coordonnées utilisateur interne du SVG ; son canevas « naturel » fait 100×100 unités, quelle que soit la taille de pixel rendue. width et height définissent la taille d'affichage rendue. Les deux étant présents, le SVG met le viewBox à l'échelle pour qu'il tienne dans la boîte rendue. preserveAspectRatio (par défaut xMidYMid meet) contrôle la façon dont la mise à l'échelle gère les écarts de rapport d'aspect : meet préserve le rapport et centre, none étire, slice rogne pour remplir. Ne définir que viewBox et laisser le CSS contrôler width et height est la meilleure pratique moderne pour les systèmes d'icônes.

Pourquoi mes icônes SVG paraissent-elles floues à l'écran ?

Presque toujours l'une de trois causes : (1) le SVG est rendu dans une taille de pixel fixe qui ne correspond pas au rapport d'aspect du viewBox, donc le navigateur l'étire ; (2) le SVG a été exporté depuis un outil de conception avec des coordonnées sous-pixel (« M 12.5 7.5 L ... »), et l'anticrénelage du navigateur fait de son mieux avec des bords non entiers ; ou (3) preserveAspectRatio="none" a été défini, ce qui laisse le SVG s'étirer arbitrairement. Corrigez en veillant à ce que le conteneur rendu corresponde au rapport du viewBox, en alignant les coordonnées sur des entiers dans les options d'export de votre outil de conception, et en évitant preserveAspectRatio="none" sauf si vous voulez spécifiquement un étirement.

Puis-je utiliser un SVG comme favicon ?

Oui. <link rel="icon" type="image/svg+xml" href="icon.svg"> est pris en charge dans Chrome 80+, Firefox 41+ et Safari 14+. Un schéma courant consiste à livrer un favicon SVG pour les navigateurs modernes et un repli ICO (<link rel="icon" sizes="any" href="favicon.ico">) pour les clients plus anciens. Les favicons SVG peuvent aussi utiliser des requêtes média prefers-color-scheme à l'intérieur du SVG pour basculer automatiquement entre les variantes de thème clair et sombre.

L'attribut d d'un tracé est-il vraiment un mini-langage ?

Oui, et apprendre la douzaine de commandes est ce qui se rapproche le plus d'apprendre à lire un SVG à la main. Les commandes sont : M/m (aller à, absolu/relatif), L/l (ligne vers), H/h (ligne horizontale), V/v (ligne verticale), C/c (Bézier cubique à deux points de contrôle), S/s (cubique lissée, reflète le point de contrôle précédent), Q/q (Bézier quadratique), T/t (quadratique lissée), A/a (arc elliptique, le plus complexe), et Z/z (fermer le tracé). Un d d'icône typique comme M5 12h14M12 5l7 7-7 7 signifie « aller à (5,12), ligne horizontale de 14 unités, aller à (12,5), ligne 7 à droite 7 en bas, ligne 7 à gauche 7 en bas », c'est-à-dire une flèche pointant vers la droite.

Outils associés