Convertir SVG en JXL

JPEG XL combine le meilleur du JPEG (bon avec perte pour les photographies) et du PNG (parfaitement sans perte) dans un seul format, avec une efficacité de codage qui dépasse les deux. La plupart des navigateurs actuels le lisent, et un fichier JXL sans perte est en général plus petit qu’un PNG équivalent et nettement plus petit qu’un JPEG à qualité égale sur une photographie.

Pour un SVG, la pertinence dépend du contenu. Un logo avec de longs aplats et peu de couleurs sort en JXL sans perte plus petit que le PNG équivalent. Une illustration complexe avec des dégradés sort en JXL avec perte plus petit que le JPEG à qualité comparable, avec moins d’artefacts. C’est la raison pour laquelle certains pipelines d’images l’adoptent comme format unique.

Le JXL supporte les deux, et le réglage décide. Sans perte, chaque pixel qui sort est exactement le pixel qui est entré, à la même fidélité que le PNG. Avec perte, le défaut 82 (le même que pour JPEG, WebP, AVIF sur ce site) équilibre la taille et la qualité visuelle, avec un mode « effort » plus élevé qui ralentit l’encodage mais gagne quelques pour cent de plus.

Pour un logo ou un dessin à aplats, sans perte est en général le bon choix, parce que le coût en octets par rapport à « avec perte à 82 » est faible et la fidélité est garantie. Pour une illustration photographique ou un dégradé complexe, avec perte à 82 est le défaut sensé, et pousser vers 90–95 aide si les dégradés montrent des paliers.

Le canal alpha passe : sur un dessin de test le pixel de coin du JXL résultant se lit 0,0,0,0, donc un signe détouré se dépose sur n’importe quel fond exactement comme le SVG le faisait. C’est l’un des formats où la transparence est un citoyen de première classe plutôt qu’une exception.

Elle est stockée comme un canal à part entière, ce qui sur un dessin simple est une part visible de la taille totale. Sur un dessin avec un fond complexe, l’alpha ajoute un peu mais pas de manière disproportionnée. Pour les aplats, un JXL sans perte avec alpha finit souvent plus petit que le PNG équivalent.

Le réglage d’échelle décide de la taille à laquelle le SVG est rendu. Le défaut fait 1 024 pixels de large et la hauteur suit les proportions du dessin ; la plage va de 0,1 à 10, ce qui donne de 102 à 10 240 pixels.

L’habitude qui vaut le coup est de trouver la plus grande largeur CSS que l’image occupera et de rendre au double pour les écrans 2×. Un logo affiché à 180 pixels veut un rendu de 360 pixels, pas de 1 024. À des tailles d’utilisation raisonnables le JXL est vraiment petit, ce qui ne change pas le fait que le SVG était plus petit et servait toutes les densités d’un coup.

Le PNG utilise Deflate, qui est bon sur les répétitions et mauvais sur les dégradés. Le JXL utilise un système de prédiction plus sophistiqué qui s’adapte au contenu : pour un dessin à aplats, il trouve des répétitions comme le PNG ; pour un dégradé, il suit la courbe avec une précision qui Deflate ne peut pas atteindre.

Mesuré sur un dessin de test à 1 024 pixels : sans perte, le JXL sort en général 20 à 40 pour cent plus petit que le PNG équivalent, parfois plus. Avec perte à 82, le JXL sort nettement plus petit qu’un PNG (sans perte) à qualité perçue comparable. C’est la migration qu’un pipeline moderne peut faire, à condition que ses destinataires lisent le JXL, ce qui est le cas de tous les navigateurs depuis 2023 environ.

JPEG XL est, comme AVIF, un codec vidéo en mode intra-image : il prédit des blocs à partir de leurs voisins et code le résiduel. Sur une photographie ce résiduel est la texture ; sur un dessin c’est le bord d’un trait, et la qualité par défaut de 82 est réglée pour la première.

Sur un dessin avec de longs aplats et peu de bruit, le résiduel est nul et le codage est extrêmement efficace. Sur un dessin avec du grain ou des dégradés, le résiduel est plus visible et la qualité 82 commence à se voir. Pousser vers 90 ou 95 pour les aplats est le bon réglage, et le surcoût en octets est faible parce que les résidus à coder sont petits.

Tous les grands navigateurs actuels décodent le JXL, et ce depuis plusieurs années. Safari l’a adopté en 2023, Chrome en 2022 via un flag puis activé par défaut, Firefox l’a depuis longtemps. Le support de l’encodage côté navigateur est plus mince, ce qui est la raison pour laquelle cette page existe : produire un JXL côté serveur ou via un pipeline est plus lourd que de le faire dans l’onglet.

Pour un site web, livrer du JXL via `<picture>` avec un repli en PNG ou WebP couvre toutes les bases, parce que les navigateurs qui ne lisent pas le JXL prendront le repli. Le format est jeune comparé au PNG (qui a trente ans) et au JPEG (qui en a trente-deux), mais pour un nouveau projet il vaut la peine d’être considéré comme format par défaut.

Le JXL est plus rapide à encoder que l’AVIF, parce que son algorithme de recherche intra-image est moins exhaustif. Sur un dessin de 1 024 pixels, l’encodage prend environ la moitié du temps d’un AVIF équivalent, ce qui est sensible pour un batch de plusieurs centaines d’images.

Pour un seul fichier, ce n’est rien. Pour un dossier de cent illustrations, c’est une attente perceptible mais tolérable. Comme l’encodeur tourne en WebAssembly dans l’onglet, la charge est sur votre propre processeur, et un appareil mobile sera sensiblement plus lent qu’un ordinateur de bureau.

Pour un logo à deux couleurs, le PNG sans perte est en général plus petit, parce que Deflate sur des aplats parfaits est imbattable et le JXL sans perte a un surcoût d’en-tête. Le JXL gagne quand le contenu a des dégradés, du bruit ou de la complexité que Deflate ne peut pas comprimer.

Pour un asset qui sera affiché à une seule taille sur un site web, un PNG optimisé ou un WebP sont plus universellement compris et souvent plus petits à cette taille. Le JXL brille pour les bibliothèques d’images qui contiennent à la fois des photos et des illustrations, où avoir un seul format simplifie le pipeline.

Déposez le dossier. Chaque dessin est rendu à la même échelle et encodé avec la même qualité, et les résultats reviennent en ZIP. Une échelle et une qualité partagées sont ce qu’une bibliothèque d’images veut en général, parce que la cohérence de l’ensemble se lit mieux que n’importe quel fichier individuellement optimal.

Leurs proportions ne s’accorderont pas à moins que les viewBox sources ne l’aient fait — l’échelle fixe la largeur et la hauteur suit chaque dessin — donc vérifiez les dimensions avant de les câbler dans une grille qui suppose un rapport d’aspect commun. Et gardez les SVG : ce sont les copies maîtresses, et les JXL sont un export qui peut être régénéré à n’importe quelle taille.