Convertisseur SVG en data URI

C'est l'image entière écrite sous forme d'URL. La chaîne commence par data:image/svg+xml, et le reste est le code lui-même, échappé pour survivre dans une URL. Comme l'illustration voyage dans la référence, un navigateur qui a déjà la feuille de style a déjà l'image : pas de seconde requête, pas d'attente d'une connexion pour une icône de 600 octets.

L'encodage URL, dans presque tous les cas. Le SVG est du texte, donc le Base64 n'apporte rien : il transforme trois octets en quatre, pour un surcoût fixe d'un tiers quel que soit le contenu. L'encodage pourcent ne coûte deux octets de plus que pour la poignée de caractères qui doivent être échappés, et finit généralement entre 10 et 25 % au-dessus de la source. Il reste aussi lisible dans un diff et se compresse mieux, car gzip et brotli voient encore les noms de balises répétés que le Base64 brouille. Gardez le Base64 pour les chaînes de traitement qui réécrivent ou échappent deux fois les signes pourcentage.

Presque toujours l'espace de noms. Quand vous écrivez un élément svg directement dans une page HTML, l'analyseur sait déjà de quoi il s'agit. Une data URI est chargée comme un document autonome, donc le fichier doit le déclarer lui-même avec xmlns="http://www.w3.org/2000/svg" sur l'élément racine. Sans lui, le navigateur n'analyse rien et ne dessine rien, sans le moindre message. L'autre cause fréquente est un # brut dans une couleur de remplissage : non échappé, il transforme le reste de l'URI en identifiant de fragment.

Parce que le document encodé décide de sa propre géométrie. Sans viewBox ni width ou height, le navigateur se rabat sur un cadre de 300 sur 150. Avec width et height mais sans viewBox, la forme est figée à cette taille et refuse de se redimensionner. Avec un viewBox seul, elle se redimensionne librement, ce que l'on veut généralement pour un fond ; associez-le à background-size, ou à des width et height explicites sur la balise img.

Non. Le SVG encodé est un document distinct, et rien de la page hôte n'y pénètre : currentColor est résolu par rapport à la propriété color de ce document (noir, sauf si le code la définit), et les propriétés personnalisées ne sont pas héritées à travers cette frontière. Trois façons de contourner le problème : modifier le remplissage dans le code avant l'encodage et garder une URI par couleur, piloter la forme avec mask-image pour que la couleur visible vienne de background-color, ou placer l'élément svg directement dans le HTML, où le CSS de la page peut le styler.

Non, et cette limitation est voulue, ce n'est pas un bug. Un SVG chargé via url() ou une balise img fonctionne en mode restreint : aucun script ne s'exécute et aucune ressource externe n'est récupérée, qu'il s'agisse d'une police web, d'une image matricielle liée ou d'une feuille de style. Convertissez le texte en tracés avant l'encodage, et intégrez toute image matricielle sous forme de data URI imbriquée dans le code.

Pas en pratique dans les navigateurs actuels : Chrome, Firefox et Safari acceptent tous des data URI dans les feuilles de style bien au-delà d'un mégaoctet. Le fameux chiffre de 32 KB est une limite d'Internet Explorer 8 qui n'a plus d'importance depuis des années. Les vraies contraintes sont ailleurs : les minificateurs et les source maps deviennent difficiles à manier, certains champs de CMS tronquent les valeurs longues, et chaque kilooctet est retéléchargé avec le fichier qui le contient. Considérez 4 KB comme confortable et 32 KB comme le seuil à partir duquel un fichier séparé est la meilleure décision technique.

Quatre choses : les commentaires, la déclaration XML, les espaces vides entre les balises et les sauts de ligne que les logiciels d'export laissent entre les attributs. Elle ne supprime jamais un attribut, n'arrondit jamais une coordonnée, ne fusionne jamais un tracé et ne renomme jamais un id, et elle laisse intactes les données textuelles dans text, tspan, textPath, title, desc, style et script. Un document qui demande xml:space="preserve" conserve aussi tous les espaces entre ses balises, même si les commentaires et la déclaration XML sont tout de même supprimés. L'étape est donc sûre mais modeste. Pour de vraies réductions, passez d'abord le fichier dans SVGO et collez le résultat ici.