Mardi 6 octobre 2026, Chrome 155 est passé en version stable. Dans les notes de version, le décodage natif du JPEG XL (.jxl) n'a droit qu'à une ligne, sans rien à activer. Pourtant, Google avait retiré ce format de Chromium fin 2022. Et Chrome représente, selon les estimations les plus citées, autour de 68 % du trafic web humain : un chiffre issu de mesures de parts de marché et non d'un décompte officiel, donc à prendre comme un ordre de grandeur.
2022 : retiré. 2025 : on en reparle. 2026 : livré
JPEG XL n'est pas un nouveau venu. Le format, standardisé sous la référence ISO/IEC 18181, avait été intégré à Chromium dès 2021, puis retiré fin 2022 et absent des versions grand public à partir de Chrome 110. Motif officiel : un intérêt trop faible de l'écosystème. Les défenseurs du format, eux, y ont toujours vu un argument commode, et le dossier n'a jamais vraiment été fermé.
Le 21 novembre 2025, Rick Byers, responsable architecture chez Chrome, annonce le revirement. Début 2026, un décodeur réécrit en Rust, jxl-rs, est fusionné dans le projet. Chrome 145 le propose en février, mais seulement via une option expérimentale désactivée par défaut. Chrome 155 la retire.
Pourquoi maintenant ? Google n'a pas détaillé tous ses arguments, et seule la partie technique est documentée. Le décodeur de 2021 était en C++ ; celui qui revient est en Rust, un langage conçu pour éviter les erreurs de gestion de la mémoire, source classique de failles. Or les décodeurs d'images comptent parmi les composants les plus exposés d'un navigateur. Il est probable que cette objection de sécurité pesait lourd. Il est aussi plausible que la pression des autres acteurs (Safari décode déjà le JXL depuis 2023, Firefox s'y est engagé) ait compté : ce point, lui, n'est pas confirmé par Google.
Des images plus légères, à condition de mesurer
Sur le papier : 30 à 50 % de compression en plus que le JPEG à qualité perçue comparable, selon Chrome for Developers. À cela s'ajoutent un décodage progressif, qui affiche d'abord une version grossière de l'image puis l'affine, et la prise en charge native du HDR et des grands espaces colorimétriques, là où le JPEG date de 1992.
Pour un site, l'effet attendu se lit surtout sur le LCP (Largest Contentful Paint), l'indicateur des Core Web Vitals qui mesure l'affichage du plus gros élément de la page, souvent une image. Une photo de couverture de 400 Ko qui passe sous les 250 Ko raccourcit mécaniquement le chargement sur mobile. Ce calcul est un exemple, pas une mesure : aucun chiffre de LCP fiable n'a été publié pour l'instant, et le gain réel variera selon le type d'image, l'encodeur et le réglage de qualité. Mieux vaut tester sur ses propres pages.
L'argument que personne ne met en avant : recompresser sans toucher aux pixels
Un fichier JXL peut ré-encoder un JPEG existant avec environ 20 % d'octets en moins, sans aucune dégradation : l'opération est réversible, on retrouve le JPEG d'origine à l'octet près. Pour une photothèque de plusieurs milliers d'images dont les fichiers sources ont disparu, c'est l'argument le plus concret du format. L'AVIF, lui, repart de zéro à chaque conversion, avec une nouvelle perte de qualité. Reste que « aucun concurrent ne fait pareil » serait excessif : certains formats spécialisés le permettent, mais pas sur le web grand public.
Navigateur prêt, ne pas confondre avec écosystème prêt
Le JPEG XL ne remplace pas le JPEG du jour au lendemain, et ne chasse ni l'AVIF ni le WebP. Chrome recommande lui-même de tester les deux : AVIF pour la compression agressive, JPEG XL pour la haute fidélité et le sans perte. « Activé par défaut » ne veut pas non plus dire « partout » : les versions antérieures de Chrome, les parcs de machines figés et les navigateurs sans support continueront de circuler pendant des années. Un site qui servirait du JXL sans repli afficherait des trous.
Le maillon faible : le bouton « exporter »
Côté lecture, le support progresse. Côté écriture, il reste incomplet. Photoshop et Lightroom n'exportent pas encore nativement en JXL. Il faut passer par des outils en ligne de commande : cjxl (l'encodeur de référence de libjxl), ImageMagick 7.1+ ou libvips 8.13+. Un graphiste qui livre des fichiers à un intégrateur n'a donc aucun moyen simple de produire du JXL depuis ses outils habituels. Les extensions de CMS (WordPress, par exemple) et les CDN d'images qui convertissent à la volée sont la voie la plus plausible, mais aucune annonce ferme n'a été faite à ce stade.
En attendant, la méthode raisonnable reste une balise <picture> avec repli JPEG : le navigateur prend le JXL s'il le comprend, le JPEG sinon. Pour commencer, il suffit de convertir les cinq ou dix images les plus lourdes d'un site et de comparer le LCP avant et après.
Ce qu'il reste à surveiller
Le blocage venait du navigateur : il est levé. Deux jalons diront si le format s'installe. Le premier : la mise en production de Firefox, dont l'intention a été confirmée en août 2026 sans date de livraison. Le second : l'arrivée d'un export JXL dans les logiciels de création et les chaînes de publication. On ne sait pas encore si ce second point se comptera en mois ou en années. Le pari de 2022, celui d'un format sans avenir, est en tout cas perdu.