Chrome 155 active le JPEG XL, écarté par Google en 2022

Une version qui arrive par vagues

La version stable de Chrome 155 est sortie le 6 octobre, conformément au calendrier du projet. Mais « sortie » ne veut pas dire « installée partout ». Sur ordinateur, Google précise que la version 155.0.8059.39/.40 (Windows, Mac) et 155.0.8059.39 (Linux) sera déployée « dans les jours ou semaines à venir ». Sur Android, elle arrive sur Google Play « dans les prochains jours ». Une partie des utilisateurs n’a donc pas encore le nouveau décodeur.

La demande de livraison déposée le 24 août prévoit une activation « pour tous les utilisateurs », sur les six plateformes de Blink, le moteur d’affichage de Chrome (Windows, Mac, Linux, ChromeOS, Android et la WebView d’Android), animations comprises. Elle a reçu le jour même les trois approbations (« LGTM ») de responsables de l’API qu’exige le processus de Chromium. Le jour de la sortie, Luca Versari, Moritz Firsching et Philip Jägenstedt ont confirmé dans un billet de Google que Chrome livre le décodage du JPEG XL « à partir de Chrome 155 ».

Un format pensé pour succéder au JPEG

JPEG XL est normalisé sous la référence ISO/IEC 18181 par le même comité que le JPEG de 1992. Selon sa page officielle, il sert à la compression avec perte, sans perte, et à la « recompression sans perte » des JPEG existants ; il gère les grands espaces de couleur, la haute dynamique (HDR), la grande profondeur de couleur, l’animation, la transparence et l’affichage progressif, et son implémentation de référence est libre et sans redevance.

Le troisième point est le plus original. Apple, qui l’a adopté dans Safari, l’explique ainsi : un JPEG existant peut être converti en JPEG XL « sans aucune perte de qualité ni de données », pour un fichier plus léger de 20 % en moyenne. Compressé à partir de l’original, le gain annoncé par Apple va jusqu’à 60 % par rapport au JPEG.

Les deux formats modernes que les navigateurs lisent déjà avancent d’autres arguments : Google promet pour son WebP des fichiers 25 à 34 % plus légers que le JPEG, et 26 % plus légers que le PNG en sans perte ; l’AVIF de l’Alliance for Open Media, tiré du format vidéo AV1, gère lui aussi la haute dynamique et l’animation. Ces chiffres de promoteurs ne sont pas mesurés dans les mêmes conditions et ne se comparent pas entre eux.

Pourquoi Google l’avait écarté

L’histoire commence en mars 2021 : Moritz Firsching annonce sur blink-dev l’intention de prototyper le décodage du JPEG XL. Le format reste caché derrière un réglage expérimental. Fin octobre 2022, Google annonce son retrait dans le ticket Chromium du projet, avec quatre arguments que The Register a reproduits : les fonctions expérimentales « ne doivent pas rester indéfiniment », l’intérêt de « l’ensemble de l’écosystème » est insuffisant, le format n’apporte pas « suffisamment d’avantages » sur les formats existants pour être activé par défaut, et sa suppression dans Chrome 110 allège la maintenance.

Ce qui a changé : Safari, Firefox et le Rust

Trois éléments ont retourné la situation. D’abord, le format a trouvé preneur ailleurs : Safari le lit depuis la version 17, en 2023, sur Mac, iPhone, iPad et Apple Watch, y compris dans les vues web des applications iOS. Ensuite, les développeurs l’ont réclamé : la demande de livraison de Chrome juge leur avis « fortement positif » et cite Cloudinary, Shopify et « de nombreux développeurs » qui s’y sont intéressés lors du processus Interop, l’initiative commune des éditeurs de navigateurs pour améliorer la compatibilité entre eux.

Enfin, la sécurité. Les décodeurs d’images traitent des fichiers venus de n’importe quel site, une surface d’attaque classique. Le 21 novembre 2025, Rick Byers a écrit sur blink-dev, au nom des responsables techniques de l’architecture de Chrome, que l’équipe « accueillerait volontiers les contributions visant à intégrer un décodeur JPEG XL performant et sûr en mémoire » dans Chromium, en posant une condition à l’activation par défaut : un engagement de maintenance à long terme. Ce décodeur, c’est jxl-rs, écrit entièrement en Rust, langage conçu pour prévenir les erreurs de gestion de la mémoire, d’où le qualificatif « memory-safe » employé par Google. Chrome l’utilise ; Firefox aussi. Ce décodeur est arrivé dans Chrome 145, en février 2026, derrière un réglage expérimental ; la version 155 l’active pour tous. Safari, lui, emploie toujours le décodeur en C++, selon la demande de Chrome.

La querelle du « sans perte »

Le mode sans perte du JPEG XL se décode beaucoup plus lentement que celui du WebP, selon une mesure publiée pendant l’examen de la demande ; l’ampleur de l’écart est discutée, et Chrome a livré quand même : Philip Jägenstedt, qui suit la demande côté Chromium, compte sur une adoption lente pour optimiser. Le 25 août, sur le fil de blink-dev, un participant, Sergey Davidoff, a publié sa mesure : sur une image d’environ 100 mégapixels, le décodage d’un JPEG XL sans perte serait 30 fois plus lent que celui d’un WebP sans perte, pour un fichier 10 % plus petit. Il redoute que les réseaux de diffusion de contenus (CDN) adoptent ce mode pour économiser de la bande passante, et en reportent le coût sur la batterie des téléphones. Sa proposition : livrer d’abord le seul mode avec perte.

Luca Versari, l’un des contacts de la demande, a objecté que Safari livre déjà le mode sans perte, et que séparer les deux fragmenterait le web ; que l’outil de mesure décodait l’image deux fois, et qu’un réglage de l’encodeur double la vitesse sans gonfler le fichier ; enfin, que le WebP ne couvre pas tout, notamment les images à plus de 8 bits par canal. Sergey Davidoff a ramené son écart à 15 fois en théorie, mais en a mesuré 20 sur son portable, comme avec la bibliothèque de référence en C++, libjxl, et a maintenu son objection.

Philip Jägenstedt a jugé le risque « réel », mais estimé que l’adoption serait lente, laissant « le temps d’optimiser » : l’usage mesuré du format part de zéro. Côté Mozilla, Timothy Nikkel a indiqué que, dans ses mesures, jxl-rs était « légèrement devant Safari (qui utilise libjxl en C++) » sur sa machine, en comptant le décodage multithread (réparti sur plusieurs cœurs du processeur) en cours d’intégration ; face aux autres décodeurs de Firefox, il s’en approchait sur les grandes images, mais montrait « un écart plus important sur les petites ». Sur ce même fil, Jake Archibald s’attend à ce que les sites soucieux de performance n’emploient guère le mode sans perte, qui resterait marginal.

Le mode avec perte n’échappe pas entièrement à la discussion. Sergey Davidoff en tient le bénéfice pour « clairement démontré ». Mais Jake Archibald, dans son message du 8 septembre, se dit surtout inquiet de voir la plupart des développeurs supposer que le JPEG XL avec perte produit des fichiers plus petits et se décode plus vite que l’AVIF « à la qualité du web », « alors que ni l’un ni l’autre ne semble vrai ».

Edge suit dès le 8 octobre, Firefox le 13

Mozilla a publié sa propre intention de livrer le même jour que Google, le 24 août, avec le même décodeur jxl-rs. Prévue d’abord pour Firefox 157, l’activation par défaut a été repoussée le 3 septembre à Firefox 158, le temps de finir le travail restant. Firefox 158 est sorti le 13 octobre : selon ses notes de version, il « prend désormais en charge le format d’image JPEG XL ». Avec Safari, les trois grands moteurs du web lisent donc le format. Microsoft, dont le navigateur Edge repose sur Chromium, l’a déjà intégré : selon les notes d’Edge 155, version publiée le 8 octobre, Edge « prend désormais en charge le décodage des images JPEG XL ».

Sources : WebKit, Chrome Releases (ordinateur, Android), Microsoft et Mozilla (notes de Firefox 158).

Pour les lecteurs, rien à faire ; pour les sites, un format de plus

Côté lecteur, il n’y a rien à régler : le format s’active avec la mise à jour, et un site qui sert du JPEG XL s’affiche normalement. Ces sites restent rares pour l’instant.

Pour les éditeurs, la méthode recommandée par Apple consiste à proposer le JPEG XL dans une balise <picture>, avec une image classique de repli pour les navigateurs qui ne le lisent pas. L’intérêt le plus immédiat tient à la recompression des JPEG déjà en ligne, sans perte de qualité. Le choix du mode sans perte, lui, mérite d’être pesé au vu du débat sur le coût du décodage.

Les citations en anglais sont traduites par la rédaction.