Chrome 155 active JPEG XL par défaut

Chrome 155 décode les images JPEG XL par défaut, a annoncé l'équipe Chrome de Google le 6 octobre 2026. Le décodeur s'appelle jxl-rs et il est écrit en Rust pour la sûreté de la mémoire. Comme Firefox 158 doit suivre le 13 octobre, JPEG XL va bientôt fonctionner dans tous les grands moteurs de navigateur. Cela met fin à un détour de quatre ans pour un format que les développeurs web ne cessaient de réclamer.

Ce que Chrome a livré

JPEG XL, d'extension .jxl, est un format d'image conçu pour remplacer JPEG. Il peut stocker des photos en fichiers plus petits, et il peut aussi réemballer un JPEG existant sans perdre aucune qualité.

L'équipe Chrome énumère les fonctions prises en charge :

• compression avec et sans perte
• HDR, ou High Dynamic Range, pour des hautes lumières plus vives et des ombres plus profondes
• transcodage JPEG sans perte, qui réduit un ancien JPEG et peut le reconvertir en l'original exact
• décodage progressif, qui affiche d'abord une version grossière de l'image et l'affine à mesure que des données arrivent
• animation

Selon CoreWebVitals.io, le format est arrivé pour la première fois dans Chrome 145 en février 2026, derrière un flag à chrome://flags/#enable-jxl-image-format. Chrome 155 supprime le besoin de ce flag.

Pourquoi le décodeur est écrit en Rust

Les décodeurs d'images sont une cible classique pour les attaquants. Un bug dans le code qui décompresse une image peut permettre à une image piégée de prendre le contrôle d'un navigateur. L'équipe Chrome qualifie les décodeurs de « l'une des surfaces d'attaque les plus critiques et les plus ciblées de tout navigateur web moderne ».

Elle a donc choisi jxl-rs, un décodeur écrit de zéro en Rust. Le compilateur de Rust bloque des classes entières de bugs de mémoire que C et C++ autorisent. L'équipe a aussi créé jxl_simd, une couche SIMD inspirée de la bibliothèque Highway de Google. Les instructions SIMD permettent à un processeur de traiter de nombreux pixels à la fois, ce qui garde le code sûr rapide.

L'équipe Chrome affirme que le fuzzing et la revue de code par IA n'ont trouvé aucun bug de sûreté de la mémoire pendant le travail. Le fuzzing consiste à lancer des millions d'entrées aléatoires sur le code.

Les rapports divergent sur la vitesse. CoreWebVitals.io indique que jxl-rs tourne à 15-25 % du décodeur de référence en C++. Fileza chiffre l'écart à 5-10 %.

Pourquoi Chrome a changé d'avis

Chrome avait déjà abandonné JPEG XL. Fileza parle de « la suppression controversée de 2022 ». L'équipe Chrome affirme aujourd'hui avoir répondu à « des retours et des demandes constants de la part des développeurs web ». Elle souligne la popularité du format dans les propositions pour le Interop Project, où les éditeurs de navigateurs s'accordent chaque année sur les écarts à corriger ensemble.

Ce retour fait suite à un long feuilleton. Mozilla a annoncé en août la prise en charge de JPEG XL avec son propre décodeur Rust. jpegxl.info indique désormais que Firefox 158 l'activera par défaut, à la date prévue du 13 octobre 2026.

Navigateur	État de JPEG XL	Source
Chrome 155+	Activé par défaut	Équipe Chrome, jpegxl.info
Chrome 145-154	Derrière un flag	CoreWebVitals.io
Firefox 158	Activé par défaut, prévu le 13 octobre 2026	jpegxl.info
Safari 17+	Pris en charge depuis septembre 2023, sans animation ni décodage progressif	CoreWebVitals.io
Brave Beta 1.98+	Pris en charge, basé sur Chromium 155	jpegxl.info

De combien les fichiers rétrécissent

Les chiffres sur la taille varient. CoreWebVitals.io affirme que les fichiers JPEG XL sont 50-60 % plus petits que JPEG et 10-15 % plus petits qu'AVIF. Cette source comme Fileza situent la recompression JPEG sans perte à environ 20 % de moins.

Tout le monde n'est pas d'accord avec ces comparaisons. Une critique détaillée soutenait en septembre que AVIF bat désormais JPEG XL en compression. Mesurez sur vos propres images avant de désigner un gagnant.

Ce que cela signifie pour les développeurs

• Servez JPEG XL avec un repli. Utilisez l'élément HTML picture avec une source de type image/jxl, ou vérifiez l'en-tête Accept côté serveur. Chrome avant la version 155 et les autres navigateurs sans prise en charge ont toujours besoin de JPEG, WebP ou AVIF.
• Commencez par la recompression JPEG sans perte. C'est le gain le plus sûr. Les JPEG existants rétrécissent d'environ 20 % et peuvent être reconvertis en l'original exact, donc rien n'est perdu si vous changez d'avis.
• Testez l'animation et les images progressives sur Safari. Selon CoreWebVitals.io, Safari n'a ni l'une ni l'autre. Un JXL progressif qui s'affiche bien dans Chrome peut s'y charger d'un coup.
• Mettez à jour votre chaîne d'images. Les CDN, les outils de redimensionnement et les validateurs d'envoi qui rejettent les types MIME inconnus bloqueront les fichiers .jxl. Vérifiez-les avant que les utilisateurs ne commencent à envoyer des fichiers.
• Surveillez Largest Contentful Paint. Des images principales plus petites peuvent améliorer ce score Core Web Vitals, qui mesure le moment où le contenu principal apparaît. Comparez avant et après sur du trafic réel, pas seulement dans un test en laboratoire.

Surveillez la sortie de Firefox 158 le 13 octobre. Si elle arrive à la date prévue, JPEG XL devient un format sur lequel on peut planifier, plutôt qu'une expérience.