Le 15 octobre 2026, John Mueller, Search Advocate chez Google, a écrit sur Bluesky que le format d’image JPEG XL n’était « pour l’instant pas pris en charge » dans Google Images ni dans les aperçus de Discover. Son message est intervenu neuf jours après la sortie de Chrome 155, première version du navigateur de Google à afficher ce format par défaut, et deux jours après celle de Firefox 158.
Un site peut donc servir des fichiers .jxl que Chrome, Firefox et Safari affichent, mais que Google n’utilise pour l’instant ni dans sa recherche d’images ni comme vignette dans Discover. Au 25 octobre, la liste des formats acceptés par Google Search s’arrête toujours à AVIF.
Le message de John Mueller
Le message, publié à 15 h 26 (heure de Paris), s’inscrit dans un fil ouvert par Barry Pollard, chargé des relations avec les développeurs dans l’équipe Chrome. John Mueller y écrit : « Si vous espérez voir vos images dans Google Images et en aperçu dans Discover, etc., le JPEG XL n’est pas pris en charge pour l’instant. » Il renvoie à la section « Utiliser des formats d’image compatibles » des bonnes pratiques de SEO pour les images, qui énumère sept formats : BMP, GIF, JPEG, PNG, WebP, SVG et AVIF. Le 21 octobre, il a aussi demandé sur Bluesky un code 503 aux sites mis hors ligne pour corriger les failles PHP2Shell.
La version anglaise de la page sur les images n’a pas changé depuis le 2 mars 2026 ; la page des types de fichiers indexables par Google, révisée le 3 février 2026, cite les mêmes sept formats. Le journal des modifications de Search Central ne mentionne pas JPEG XL : sa dernière entrée, du 23 octobre, porte sur la structure des URL, et celle du 16 octobre sur la page des quotas de l’API d’indexation.
Le magazine allemand Dr. Web a repris l’information le 20 octobre, Search Engine Journal le 21 et Search Engine Roundtable le 23. Michael Dobler, l’éditeur de Dr. Web, résume : « Pour les formats d’image, ce n’est pas le navigateur le plus rapide qui décide du passage, mais le moteur de recherche le plus lent. »
Trois grands navigateurs sur quatre lisent le format
JPEG XL est normalisé par l’ISO et la CEI sous la référence ISO/IEC 18181. Dans leur billet d’annonce du 6 octobre sur le blog Chrome for Developers, Luca Versari, Moritz Firsching et Philip Jägenstedt lui prêtent « une compression 30 à 50 % meilleure que le JPEG » et citent la compression sans perte, le HDR et la conversion sans perte des JPEG existants. Chrome le décode avec jxl-rs, écrit en Rust.
Les notes de version de Firefox 158 affirment que JPEG XL « offre en général une meilleure compression que WebP, JPEG, PNG et GIF ». Le billet de Chrome est plus prudent face à AVIF : il recommande « d’essayer à la fois AVIF et JPEG XL » et situe l’avantage du nouveau format dans les images de haute fidélité, surtout photographiques, et dans la compression sans perte. En SEO technique, le poids des images compte parmi les leviers de vitesse.
Selon webstatus.dev, qui suit la disponibilité des fonctions web dans les navigateurs, Chrome affiche le format depuis sa version 155 (6 octobre 2026), sur ordinateur comme sur Android, Firefox depuis la 158 (13 octobre) et Safari depuis la 17 (18 septembre 2023). Sans Microsoft Edge, JPEG XL reste classé en « disponibilité limitée » (Limited availability) : il n’a pas le label Baseline, réservé aux fonctions disponibles dans les quatre grands navigateurs.
| Navigateur ou service | AVIF | JPEG XL |
|---|---|---|
| Chrome | oui, depuis la version 85 (août 2020) | oui, depuis la version 155 (6 octobre 2026) |
| Firefox | oui, depuis la version 113 (mai 2023) | oui, depuis la version 158 (13 octobre 2026) |
| Safari | oui, depuis la version 16.4 (mars 2023) | oui, depuis la version 17 (septembre 2023) |
| Microsoft Edge | oui, depuis la version 121 (janvier 2024) | non |
| Google Search (Images, Discover) | oui, depuis le 30 août 2024 | non |
| Google Merchant Center | non | non |
L’élément picture comme solution de repli
Dans le même fil, Barry Pollard a rappelé qu’il fallait de toute façon prévoir une solution de repli, le format étant nouveau dans Chrome et Firefox. John Mueller a répondu : « L’élément picture contient un élément img, donc cela fonctionnerait pour n’importe quel moteur de recherche (ou tout autre système qui analyse les pages). » Il dit n’avoir entendu parler d’aucun problème avec cette amélioration progressive, où le navigateur choisit le format le plus récent qu’il sait lire.
La documentation de Google va dans le même sens : le moteur peut trouver l’image placée dans l’attribut src de la balise img, « même s’il s’agit d’un enfant d’autres éléments, comme l’élément <picture> », et Google recommande « de toujours spécifier une URL de remplacement via l’attribut src ». Une page peut ainsi proposer un fichier .jxl dans une balise source et garder un JPEG, un WebP ou un AVIF dans la balise img. Barry Pollard a jugé peu judicieux d’y placer directement un JPEG XL.
La page de Google consacrée à Discover ne nomme aucun format. Elle recommande des images d’au moins 1 200 pixels de large, activées par le paramètre max-image-preview:large, et conseille de désigner la grande image dans la balise og:image ou le balisage schema.org, ce qui « peut influencer l’image choisie comme vignette ». Dr. Web en déduit qu’une balise og:image pointant vers un fichier .jxl prive la page de sa grande vignette.
Les boutiques ont une contrainte supplémentaire. Selon sa fiche d’aide sur l’attribut image_link, Google Merchant Center accepte JPEG, WebP, PNG, GIF, BMP et TIFF, et exige que l’extension du fichier corresponde à son format. JPEG XL n’en fait pas partie, AVIF non plus.
Les fichiers .jxl repérés dans Google Images
Le 23 octobre, le consultant SEO Glenn Gabe a remarqué qu’une recherche filetype:jxl faisait apparaître des fichiers .jxl dans Google Images et s’est demandé si le format fonctionnait parfois sans prise en charge officielle. Barry Pollard a vérifié : aucune des images qu’il a examinées n’était réellement servie en JPEG XL, malgré l’extension. Celle qu’il cite en exemple est un PNG.
Selon lui, les CDN d’images convertissent souvent un fichier dans un format accepté sans changer son extension. John Mueller a ajouté que ces décalages entre extension et format étaient « assez courants » pour les images, puisque le format réel est inscrit dans l’en-tête du fichier, en précisant qu’il parlait d’expérience, sans données. La documentation de Google recommande pourtant que l’extension corresponde au type de fichier.
Une prise en charge sans calendrier
John Mueller a écrit « pour l’instant », mais Google n’a annoncé ni date ni projet d’ajouter JPEG XL à sa liste. Les fichiers .jxl visibles dans Google Images ne prouvent pas que le moteur indexe ce format.
Les 30 à 50 % de gain avancés par Chrome mesurent l’écart avec le JPEG ; le billet ne chiffre pas celui avec WebP ou AVIF. Barry Pollard avait aussi demandé si Google Search tiendrait compte du format choisi par le serveur selon les en-têtes de la requête. La réponse de John Mueller ne porte que sur l’élément picture.
Côté WordPress, le ticket Gutenberg qui demande la prise en charge de JPEG XL, créé le 1er avril 2026, est toujours ouvert. Son auteur, le contributeur WordPress Adam Silverstein, l’a repoussé au-delà de la version 7.1 le 27 juin, puis rattaché le 20 octobre aux travaux de la 7.3 ; le 22, il notait qu’Edge restait le seul grand navigateur sans prise en charge. Dans la version de développement (7.2 bêta au 25 octobre), JPEG XL est absent de la liste des types de fichiers reconnus, qui comprend AVIF et HEIC.
Notre analyse
En octobre, seuls les navigateurs ont changé : Chrome et Firefox ont rejoint Safari, tandis que Google Search, Discover et Merchant Center s’en tiennent à des listes de formats sans JPEG XL. Un site qui passerait ses images en .jxl sans solution de repli les verrait sortir de Google Images et perdrait la grande vignette de Discover, deux sources de trafic pour les éditeurs et les boutiques en ligne.
Le précédent d’AVIF donne un ordre de grandeur. Chrome affichait AVIF depuis août 2020 et Edge, dernier des grands navigateurs à suivre, depuis janvier 2024 ; Google Search a annoncé sa prise en charge le 30 août 2024, quatre ans après Chrome et sept mois après Edge. Dans son billet d’annonce, John Mueller déconseillait déjà de modifier en bloc et à l’aveugle les images d’un site et demandait des redirections côté serveur en cas de changement de nom de fichier. Pour JPEG XL, Edge manque encore.
Le cas le moins visible est celui des sites dont les images passent par un CDN ou une extension d’optimisation qui choisit le format selon le navigateur. Le format servi au robot de Google dépend alors de ces outils, et John Mueller n’a pas répondu sur ce point.
Trois signaux diront si la situation évolue : une entrée sur JPEG XL dans le journal des modifications de Search Central, l’arrivée du format dans Microsoft Edge et son ajout aux types de fichiers reconnus par WordPress. Pour les flux de produits, le repère reste la fiche d’aide de Merchant Center, où AVIF ne figure pas encore.
Sources
- Message de John Mueller et réponses de Barry Pollard et Glenn Gabe, Bluesky, 15 et 23 octobre 2026
- Bonnes pratiques de SEO pour les images, Google Search Central, consulté le 25 octobre 2026
- Shipping JPEG XL in Chrome, Chrome for Developers, 6 octobre 2026
- Firefox 158.0 Release Notes, Mozilla, 13 octobre 2026
- JPEG XL, webstatus.dev, consulté le 25 octobre 2026
- Lien image [image_link], Aide Google Merchant Center, consulté le 25 octobre 2026
- Supporting AVIF in Google Search, Google Search Central, 30 août 2024
- Add JPEG XL (JXL) support, WordPress/Gutenberg sur GitHub, 1er avril 2026, mis à jour le 22 octobre 2026
Image d’en-tête : graphique MACCUS. Données : webstatus.dev, Google Search Central, Chrome for Developers et Mozilla, octobre 2026
