Choisir ses formats d'image pour le Web en 2026 : l'empire JPEG, l'ascension d'AVIF et l'exil de JPEG XL

Prenez une photo de 12 MP (4000 × 3000 pixels) et exportez-la de six façons. PNG : 24 Mo. JPEG en qualité 90 : 3,4 Mo. WebP à qualité visuelle équivalente : environ 2,4 Mo. AVIF à qualité visuelle équivalente : environ 1,7 Mo. GIF, ramené par tramage à son plafond de 256 couleurs : 6 Mo, avec du banding visible partout. SVG n'est pas dans la liste : il décrit des dessins, et une photographie n'en est pas un.

La même image à l'écran, un facteur 14 sur le disque. Cet écart relève de l'ingénierie, pas du goût. Chaque format est un paquet de décisions prises une année précise, sous des contraintes précises, et ces décisions se retrouvent encore aujourd'hui dans le poids de vos pages.

Voici la version décisionnelle de cette expérience : ce que chaque format fait réellement à vos pixels, quels navigateurs le décodent mi-2026, ce que le Web sert vraiment, et à la fin un tableau que vous pourrez coller tel quel dans le wiki de votre équipe.

Les prétendants, un par un

JPEG (1992). Le mécanisme : découper l'image en blocs de 8 × 8, transformer chaque bloc en fréquences avec la transformée en cosinus discrète, puis quantifier les détails fins vers zéro selon un modèle de la vision humaine. Points forts : il se décode sur tous les appareils fabriqués depuis le milieu des années 90, encode vite, et excelle sur les photos à tons continus. Points faibles : pas de transparence, pas d'animation, du ringing visible autour des contours nets et du texte, et une qualité qui se dégrade à chaque réenregistrement. Convient aux photographies, et à tout ce qui doit s'ouvrir absolument partout.

PNG (1996). Le mécanisme : intégralement sans perte. Chaque ligne de balayage est filtrée par un prédicteur, puis compactée avec DEFLATE, la même combinaison LZ77 plus Huffman qu'au cœur de gzip. Points forts : sortie exacte au pixel près, canal alpha complet, support universel. Le point faible, ce sont les photos : le bruit du capteur met le prédicteur en échec, et une photo de 12 MP se compresse tout au plus à 1,5:1 par rapport aux pixels bruts. Convient aux captures d'écran, aux copies d'interface, aux diagrammes, et à tout ce qui contient du texte ou de la couleur unie.

GIF (1987). Le mécanisme : compression LZW sur une palette d'au plus 256 couleurs, avec plusieurs images regroupées dans un seul fichier. Son seul point fort restant, c'est une animation qui tourne partout, y compris dans les clients mail qui ne prennent pas en charge les formats modernes. Les points faibles, c'est tout le reste : 256 couleurs, une transparence sur un seul bit, et des fichiers bien plus lourds que la vidéo équivalente. Convient aux mèmes et aux petites boucles d'interface.

SVG (2001). Le mécanisme : aucun, au sens raster du terme. SVG est du XML qui décrit des formes, des tracés et des dégradés, et le moteur de rendu dessine les pixels à la résolution dont l'écran a besoin. Points forts : indépendance vis-à-vis de la résolution, taille minuscule pour les graphismes géométriques, stylable en CSS. Points faibles : ça ne fonctionne que pour un contenu réellement vectoriel, et un fichier pathologique avec des milliers de nœuds et des filtres lourds peut coûter plus cher qu'un bitmap. Convient aux logos, icônes, graphiques et diagrammes.

WebP (2010). Le mécanisme : le mode avec perte emprunte la prédiction intra-image du codec vidéo VP8, et le mode sans perte utilise la prédiction spatiale plus des références arrière à la LZ77. Points forts : les deux modes dans un seul format, l'alpha en mode avec perte, l'animation, et des fichiers 25 à 34 % plus petits que JPEG à qualité équivalente dans l'étude de Google elle-même. Points faibles : une limite stricte de 16383 × 16383 pixels et un encodeur plus gourmand en CPU que libjpeg. Convient à presque tout, et c'est pour cela qu'il est devenu la voie de mise à niveau par défaut de JPEG, PNG et GIF sur le Web.

AVIF (2019). Le mécanisme : des images fixes issues du codec vidéo AV1, encapsulées dans un conteneur HEIF. Points forts : la meilleure compression avec perte qu'on puisse diffuser dans un navigateur, environ 50 % plus petit que JPEG à qualité équivalente dans les tests de Netflix de 2020, plus la couleur 10 bits et 12 bits, le HDR, l'alpha et l'animation. Points faibles : l'encodage est réellement lent, il n'y a pas de rendu progressif (l'image apparaît d'un coup ou pas du tout), et les réglages de qualité très bas étalent la texture, là où JPEG se contente de blocs visibles mais francs. Convient aux photographies et aux images héro, là où la taille des fichiers compte le plus.

HEIC (2015). Le mécanisme : des images fixes HEVC, là encore dans un conteneur HEIF. Points forts : une compression dans la cour d'AV1, et le format de capture par défaut de tous les iPhone depuis 2017. Le point faible est juridique plutôt que technique : HEVC est empêtré dans des pools de brevets, et tous les éditeurs de navigateurs, sauf Apple, ont refusé de payer. Il a sa place dans les pellicules photo, pas sur le Web.

JPEG XL (2021). Le mécanisme : deux moteurs sous un même toit, VarDCT pour le travail avec perte et un mode modulaire pour le sans perte, plus une astuce qu'aucun autre format ne possède. Il peut recompresser un JPEG existant sans perte, à environ 80 % de sa taille d'origine, pixels identiques au bit près inclus. Points forts : décodage progressif, excellents ratios sans perte, photographie haute fidélité. Le point faible, c'est l'adoption, qui tient surtout à la politique des navigateurs, abordée plus bas. Convient aux pipelines photo et aux archives, et sur les appareils Apple, au Web.

Le support navigateur, mi-2026

Les versions où chaque format s'est activé par défaut, d'après les données de caniuse :

Trois détails de ce tableau méritent d'être soulignés. AVIF sur iOS est techniquement arrivé avec Safari 16.0, mais sans l'animation ; c'est la 16.4 qui apporte le support complet, sur macOS comme sur iOS. Edge a livré AVIF des années après Chrome, alors même qu'Edge est du Chromium, parce que Microsoft a gardé le décodeur désactivé plus longtemps que Google. Et la ligne JPEG XL cache une histoire singulière, qui a droit à sa propre section plus bas.

La couverture mondiale, d'après les chiffres 2026 de caniuse : WebP tourne autour de 97 %, AVIF autour de 93 à 94 %. JPEG et PNG sont à 100 % en pratique, et cela ne devrait pas changer.

La hiérarchie de la compatibilité

Regroupés par portée, les formats se répartissent en cinq niveaux.

Le premier niveau, c'est le socle universel : JPEG, PNG, GIF et SVG. Ils se décodent dans tous les navigateurs, tous les clients mail, tous les aperçus de système d'exploitation, et tous les kiosques vieux de dix ans. Si un fichier doit absolument s'ouvrir, il part dans l'un de ces quatre formats.

Le deuxième niveau, c'est WebP, tout seul. Le dernier grand récalcitrant était Safari, et Safari 14 a comblé l'écart en septembre 2020. Ce qui reste, ce sont les installations d'Internet Explorer et les WebViews Android antiques. Pour un site web, par opposition à un e-mail, WebP est une valeur sûre par défaut depuis environ cinq ans.

Le troisième niveau, c'est AVIF. Chrome l'a eu en 2020, Firefox en 2021, Safari en 2022 (support complet en mars 2023 avec la 16.4), et Edge l'a activé par défaut en janvier 2024. Depuis début 2024, tous les grands moteurs décodent AVIF nativement. Les quelques pour cent restants, ce sont les vieux iPhone et les parcs Windows non administrés, et c'est précisément à ça que servent les fallbacks.

Le quatrième niveau, c'est JPEG XL, bloqué. Apple le livre nativement depuis Safari 17 en septembre 2023. Google a retiré le décodeur expérimental de Chromium fin 2022, avec effet dans Chrome 110 en février 2023, puis a fait marche arrière et fusionné un décodeur écrit en Rust (jxl-rs), livré dans Chrome 145 en février 2026, toujours derrière un flag. Firefox a un décodeur derrière un flag depuis des années. Le support de JPEG XL mi-2026 signifie donc tous les utilisateurs Apple, plus la fraction infime des utilisateurs de Chrome et Firefox qui activent des flags, un groupe trop restreint pour servir de base.

Le cinquième niveau, c'est HEIC : Safari 17 sur les plateformes Apple, et rien d'autre nulle part. Ce n'est pas vraiment un niveau, plutôt un écosystème à fournisseur unique.

Ce que le Web sert réellement

Le support n'est pas l'usage. Le Web Almanac de l'HTTP Archive explore des millions de pages réelles et compte ce qu'elles servent, et l'édition 2024 (la dernière avec des données média complètes) se lit comme un glacier en mouvement. JPEG restait le format le plus courant avec 32 % de toutes les images, mais c'est huit points entiers de moins que les 40 % de 2022. WebP en a récupéré trois pour atteindre 12 %. SVG en a gagné environ deux. AVIF a atteint environ 1 %, ce qui ressemble à une erreur d'arrondi jusqu'à ce qu'on le lise en relatif : presque un facteur 4 de croissance en deux ans. ICO a conservé 1,3 %, presque uniquement des favicons. Et GIF, 37 ans, a d'une certaine façon gagné un point.

Pourquoi est-ce si lent ? Trois frictions font l'essentiel du travail. La mise en cache CDN : les images vivent en périphérie de réseau, indexées par URL, et changer de format signifie invalider les caches et réencoder des bibliothèques entières. Les vieux appareils : le tableau de support affiche 97 %, mais les 3 % manquants se concentrent dans les téléphones Android bas de gamme et les parcs d'entreprise, et certains sites ne peuvent pas se permettre de perdre une seule vente à cause d'une image cassée. L'inertie des outils : le CMS génère des vignettes JPEG parce qu'il l'a toujours fait, l'outil de design exporte en PNG parce que c'est le gros bouton, et changer la valeur par défaut veut dire toucher à un pipeline de build dont personne n'est responsable.

Il y a aussi le coût d'encodage. L'avantage de compression d'AVIF se paie en CPU au moment de l'encodage, et c'est pourquoi les CDN d'images le facturent, et pourquoi les équipes avisées pré-génèrent l'AVIF au moment du build ou de l'upload plutôt qu'à la volée.

Où tout cela se dirige

AVIF est le pari le plus sûr pour les prochaines années. Il est libre de droits par conception (l'Alliance for Open Media a été fondée en 2015 par Amazon, Cisco, Google, Intel, Microsoft, Mozilla et Netflix, explicitement pour échapper aux pools de brevets à la HEVC), il gère le avec perte et le sans perte dans une seule spécification, il transporte le HDR, et il a franchi le seuil de support à partir duquel une chaîne de fallback ne coûte presque rien. Les vrais coûts, ce sont le temps d'encodage et l'absence de décodage progressif. La pré-génération résout le premier ; le second est un compromis acceptable.

JPEG XL méritait un meilleur sort que celui qu'il a connu. Sur le plan technique, c'est le format le plus complet jamais standardisé : décodage progressif, meilleur mode sans perte, photographie à haute profondeur de bits, et recompression sans perte de tout le corpus JPEG existant. Google l'a retiré de Chromium en invoquant un intérêt insuffisant de l'écosystème, et la demande de rétablissement est devenue l'un des tickets les plus étoilés de l'histoire du tracker Chromium. Trois ans plus tard, Google est revenu sur sa décision, mais la fenêtre d'adoption s'était entre-temps en grande partie refermée. Pendant l'exil de JPEG XL, AVIF a récupéré les intégrations CDN, les plugins de CMS et les cases cochées par défaut. JPEG XL vivra comme le favori des archivistes et comme citoyen de première classe sur les appareils Apple. Il avait les arguments techniques pour l'adoption grand public, et il l'a manquée quand même.

HEIC ne deviendra pas un format du Web. La raison n'a rien à voir avec la qualité. Le décodage HEVC exige des licences de brevets que les éditeurs de navigateurs gratuits refusent de payer depuis dix ans, et le Web repose sur des technologies libres de droits. Un format que trois des quatre grands moteurs refusent de décoder n'est pas un format du Web ; c'est un problème d'export qu'on résout à la frontière.

La technique de transition, elle, est bien établie, et elle prend deux formes. La négociation de contenu côté serveur : le navigateur envoie un en-tête Accept qui liste ce qu'il sait décoder, et le serveur ou le CDN choisit la meilleure variante pour la même URL. Côté client : l'élément <picture>, qui liste les candidats et laisse le navigateur prendre le premier qu'il comprend :

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="Team photo" width="1600" height="900" />
</picture>

Le <img> en bas est le fallback universel, donc rien ne casse, nulle part. C'est comme ça qu'on sert de l'AVIF aux 93 % et du JPEG au reste sans maintenir deux sites.

Le tableau de décision

Une courte note sur les favicons, car la ligne du tableau laisse de côté certains détails. Les navigateurs modernes acceptent les favicons PNG et même SVG, mais ICO reste le seul format que comprennent tous les crawlers, lecteurs RSS et onglets de navigateurs antiques, et un fichier ICO peut regrouper plusieurs tailles dans un seul conteneur. Si votre logo vit actuellement dans un autre format, JPG vers ICO, WebP vers ICO et PNG vers ICO produisent un ICO multi-tailles correct directement dans votre navigateur.

Convertir entre les formats

La plupart des corvées de conversion découlent des sections ci-dessus. La plus courante, de loin, consiste à sortir le HEIC d'un iPhone pour le mettre dans quelque chose que le reste du monde peut ouvrir. HEIC vers JPG est le bon réflexe pour partager, puisque HEIC est déjà avec perte et que JPEG empêche les dégâts de s'aggraver. HEIC vers PNG fige l'état actuel pour l'édition, et HEIC vers WebP se justifie quand la destination est un site web.

Reste ensuite le triangle JPEG, PNG, WebP. Faire entrer un JPEG dans un workflow de design : JPG vers PNG, pas parce qu'il gagnerait en qualité (c'est impossible) mais parce qu'il arrêtera d'en perdre. L'alléger pour le Web : JPG vers WebP. Dans l'autre sens, pour les logiciels plus anciens : WebP vers JPG et WebP vers PNG. Une capture PNG qui part vers une galerie photo : PNG vers JPG, ou PNG vers WebP quand on veut des fichiers plus petits en gardant la transparence. Si vous héritez de scans BMP non compressés, BMP vers JPG, BMP vers PNG et BMP vers WebP valent tous mieux que des reliques de plusieurs mégaoctets envoyées par e-mail. Même les documents arrivent à la même bifurcation : PDF vers JPG pour les pages photographiques, PDF vers PNG quand le texte doit rester net, et PDF vers WebP quand la page part vers le Web.

Chacun de ces outils exécute la conversion localement dans votre navigateur : le fichier ne quitte jamais votre appareil.

Les formats changent sans cesse. La règle, non : adaptez le codec au contenu, et convertissez quand le contenu change de rôle.