WebP vs AVIF vs JPEG : quel format d’image choisir en 2026 ?

TL;DR : AVIF est 20 à 30 % plus petit que WebP, et 30 à 50 % plus petit que JPEG. WebP est environ 25 à 35 % plus petit que JPEG. AVIF encode 5 à 20× plus lentement que WebP, tandis que WebP décode le plus rapidement des trois. Le workflow qui marche en 2026 : servir AVIF en priorité, retomber sur WebP, garder JPEG comme filet de sécurité universel, et laisser le navigateur choisir via l’élément <picture>.

Cette réponse couvre la majorité des lecteurs. La question plus intéressante est de savoir quand ne pas dégainer AVIF. Évitez-le sur des budgets CI serrés, où le temps d’encodage compte plus que les octets gagnés. Mettez-le de côté pour les uploads utilisateurs en temps réel, car l’encodage AVIF côté navigateur reste inégal. Gardez JPEG comme format principal si vous devez supporter iOS 16.0–16.3 ou des versions anciennes d’Edge en production. Partout ailleurs, AVIF gagne sur la taille de fichier, à condition que votre balisage <picture> soit correct et que votre CDN envoie le bon type MIME.

Le reste de ce guide entre dans le détail opérationnel : chiffres de support 2026, benchmark sur photo réelle, arbre de décision par cas d’usage, patterns <picture> à copier-coller, commandes de conversion, et les quatre pièges qui coûtent du temps aux équipes. Si vous voulez simplement convertir une image, notre compresseur d’images gratuit gère JPEG, PNG, WebP et AVIF dans le navigateur, sans rien uploader.

1. Support navigateur 2026 : WebP à 97 %, AVIF à 93 %

Deux ans et demi après le déploiement d’AVIF dans Edge, l’écart de support s’est réduit à quelques pour cent du trafic mondial. La question n’est plus « est-ce supporté » mais « que servir aux 3 % restants ? »

1.1 WebP : le choix par défaut sûr

WebP est arrivé dans Chrome dès 2012, dans Firefox 65 (2019), Edge 18 (2018) et Safari 14 (2020). En mai 2026, caniuse situe le support mondial autour de 97 %. WebP est passé du statut d’« alternative moderne » à celui de « fallback viable ». Si vous ne servez qu’un seul format non-JPEG, c’est WebP.

1.2 AVIF : enfin utilisable comme format principal

AVIF est arrivé dans Chrome 85 (août 2020) et Firefox 93 (octobre 2021). Safari 16.4 l’a activé sur macOS et iOS en mars 2023. Edge a été le retardataire, n’ajoutant le décodage qu’en version 121 (janvier 2024). La couverture mondiale en mai 2026 oscille entre 93 et 95 %.

Une mise en garde mérite d’être signalée : iOS 16.0–16.3 souffre d’un bug de décodage AVIF connu qui peut faire planter Safari sur certaines images. Ces builds restent en circulation sur des appareils bridés par MDM en entreprise, donc AVIF sans fallback WebP ou JPEG fonctionnel constitue un risque réel d’incident. Traitez-le comme « principal avec assurance », pas « principal seul ».

1.3 Matrice de compatibilité rapide

Format	Support mondial (mai 2026)	Limitation clé
JPEG	100 %	Fichiers les plus volumineux ; pas de transparence ; pas de HDR
WebP	~97 %	Pas de HDR ni de couleur 10 bits
AVIF	~93–95 %	Encodage lent ; bug de décodage iOS 16.0–16.3 ; nécessite Edge 121+

2. Différences fondamentales : compression, vitesse, fonctionnalités

2.1 Efficacité de compression sur une photo réelle

Un benchmark à source unique. Une photo de paysage 4000×3000, PNG d’origine d’environ 24 Mo, ré-encodée à qualité perceptuellement équivalente :

Encodage	Taille	Vs JPEG de référence
JPEG q75 (mozjpeg)	~2,1 Mo	0 % (référence)
WebP q75 (libwebp)	~1,4 Mo	33 % de moins
AVIF q60 (libavif, cpu-used 4)	~1,0 Mo	52 % de moins

AVIF q60 est ici visuellement équivalent à JPEG q80 et WebP q75. Les échelles de qualité ne sont pas interchangeables d’un codec à l’autre. Ré-encoder « JPEG q75 vers AVIF q75 » est l’erreur classique du débutant : vous obtenez un AVIF surdimensionné qui ressemble en tout point à la source.

2.2 Vitesse d’encodage : la taxe de 5 à 20×

AVIF compresse plus fortement parce qu’il fait davantage de travail. Avec libavif au paramètre par défaut cpu-used 4, une image 4000×3000 prend 5 à 20× plus de temps qu’avec libwebp, et environ 50× plus longtemps qu’avec mozjpeg. Ce coût se cumule à travers les builds CI, les démarrages à froid Lambda, et les pipelines qui ré-encodent des milliers d’assets.

Deux soupapes de sécurité existent. cavif --speed 9 (ou libavif cpu-used 9) se rapproche à 3× de libwebp, au prix de fichiers 5 à 8 % plus gros. Et mettez agressivement en cache : un pipeline d’assets adressés par contenu qui saute le ré-encodage des sources inchangées transforme un codec lent en coût ponctuel.

2.3 Profondeur de couleur et HDR

JPEG et WebP plafonnent à sRGB 8 bits. AVIF gère nativement les couleurs 10 et 12 bits, Rec. 2020, DCI-P3 et les fonctions de transfert PQ/HLG. Pour les vignettes vidéo HDR, les galeries photo professionnelles ou les épreuves d’impression côté navigateur, AVIF est aujourd’hui la seule option standardisée.

2.4 Transparence et animation

JPEG n’a ni l’une ni l’autre. WebP et AVIF supportent tous deux l’alpha et l’animation. Pour remplacer un PNG transparent, AVIF encode l’alpha de manière plus compacte : une illustration d’interface qui rétrécit de 30 à 40 % en WebP rétrécit souvent de 50 à 70 % en AVIF.

3. Arbre de décision : quel format pour quel usage

3.1 Sites statiques : blogs, pages marketing, docs

AVIF principal, WebP en fallback, JPEG en filet de sécurité. L’encodage se fait une seule fois en CI, donc la taxe de 5 à 20× se paie en temps de build, pas en temps utilisateur. C’est le cas canonique pour le pattern <picture> à trois sources de la section 4.

3.2 Uploads utilisateurs : avatars, UGC, pièces jointes de formulaire

Compressez en WebP dans le navigateur, puis ré-encodez en AVIF de manière asynchrone côté serveur. canvas.toBlob('image/avif') côté navigateur ne fonctionne aujourd’hui que sur Chrome 99+, donc AVIF ne peut pas être le chemin d’upload. WebP compresse rapidement dans le navigateur et économise de la bande passante sur l’upload lui-même.

Pour une comparaison plus poussée des bibliothèques côté client (Squoosh, browser-image-compression, Compressor.js) et de leur articulation avec Sharp ou Imagemin côté serveur, voyez l’article complémentaire guide compression d’images : navigateur vs Node.js. Le choix du format et l’emplacement du traitement sont orthogonaux ; ce guide couvre l’axe format.

3.3 HDR et photographie haute fidélité

AVIF uniquement. Aucun autre format de l’écosystème web ouvert ne supporte aujourd’hui les couleurs 10 ou 12 bits. Sautez le fallback pour les assets HDR uniquement, ou acceptez que le fallback JPEG soit en SDR.

3.4 Audiences chargées en navigateurs anciens

JPEG principal, WebP optionnel, pas d’AVIF. Les portails gouvernementaux, certains environnements d’entreprise en Asie de l’Est, et les outils B2B avec un long historique d’appareils affichent parfois 5 à 10 % de trafic IE/ancien Edge dans leurs analytics. WebP est désormais sûr ; AVIF ne l’est pas encore.

3.5 Diffusion CDN en temps réel

libvips ou Sharp côté serveur diffusant du WebP en streaming, AVIF généré sur un worker en arrière-plan et servi sur cache hit. Ne bloquez pas la réponse sur l’encodage AVIF. Cloudflare Polish, Vercel Image Optimization et Cloudinary f_auto automatisent ce schéma.

4. Le fallback `<picture>` bien fait

L’élément <picture> existe précisément pour que le navigateur choisisse la meilleure source supportée. Trois couches, listées AVIF en premier, vous donnent le budget en octets optimal sans casser sur les clients anciens.

4.1 La base à trois couches

<picture>
  <source srcset="/img/hero.avif" type="image/avif" />
  <source srcset="/img/hero.webp" type="image/webp" />
  <img src="/img/hero.jpg"
       width="1200" height="800"
       alt="Paysage de montagne au coucher du soleil"
       loading="lazy" decoding="async" />
</picture>

Trois points à retenir. Le navigateur parcourt les éléments <source> de haut en bas et choisit le premier dont il comprend le type ; tout le reste est ignoré, pas téléchargé. La balise <img> est l’élément effectivement rendu et hérite des attributs (alt, sizes, classes) quel que soit le <source> retenu. Enfin, width/height sur l’<img> ne sont pas optionnels en 2026 : ils réservent l’espace et empêchent le Cumulative Layout Shift.

Pour les images au-dessus de la ligne de flottaison, remplacez loading="lazy" par loading="eager" fetchpriority="high". Mettre l’image LCP en lazy-loading reste l’un des pièges Core Web Vitals les plus courants.

4.2 Responsive et format combinés : le pattern complet

Quand vous avez aussi besoin de résolutions responsives, répétez srcset à l’intérieur de chaque <source> :

<picture>
  <source type="image/avif"
          srcset="/img/hero-800.avif 800w,
                  /img/hero-1600.avif 1600w,
                  /img/hero-2400.avif 2400w"
          sizes="(min-width: 1024px) 1600px, 100vw" />
  <source type="image/webp"
          srcset="/img/hero-800.webp 800w,
                  /img/hero-1600.webp 1600w,
                  /img/hero-2400.webp 2400w"
          sizes="(min-width: 1024px) 1600px, 100vw" />
  <img src="/img/hero-1600.jpg"
       width="1600" height="900"
       alt="Paysage de montagne au coucher du soleil"
       loading="lazy" decoding="async" />
</picture>

Oui, cela fait neuf fichiers générés par image. Une étape de build est non négociable à cette échelle ; la section 5.3 couvre les outils à brancher.

4.3 Négociation côté serveur via `Accept` comme alternative

Si votre CDN le supporte, la négociation de contenu réduit le balisage à une simple balise <img>. Le navigateur envoie Accept: image/avif,image/webp,image/apng,*/* et le CDN répond avec le meilleur format supporté à la même URL.

Cloudflare Polish, Vercel Image Optimization, Cloudinary f_auto et CloudFront avec Lambda@Edge implémentent tous cela. Le compromis : moins de HTML et une seule URL par image, mais verrouillage CDN et débogage local plus difficile. Une répartition utile : négociation CDN pour les pages marketing, <picture> explicite pour l’UI produit, là où le comportement déterministe compte.

5. Comment convertir des images entre formats

5.1 Dans le navigateur, sans upload

Le chemin le plus rapide pour un cas isolé ou un petit lot reste le navigateur seul. Déposez un JPEG dans le compresseur d’images gratuit, choisissez WebP ou AVIF en sortie, et le fichier ne quitte jamais votre machine. L’entrée AVIF est supportée partout ; la sortie AVIF utilise l’encodage navigateur natif sur Chrome 85+ et retombe automatiquement sur WebP pour les navigateurs qui ne savent pas encore encoder l’AVIF.

5.2 Ligne de commande pour les pipelines de build

Pour un pipeline de production, vous voulez une sortie déterministe et des builds reproductibles. Ces trois commandes sont opérationnelles :

# AVIF : cavif (Rust, installation facile via cargo ou brew)
cavif --quality 60 --speed 4 input.jpg -o output.avif

# WebP : cwebp (libwebp officiel de Google)
cwebp -q 75 -m 6 input.jpg -o output.webp

# Les deux, plus le redimensionnement, via libvips (le plus rapide en lot)
vips webpsave input.jpg output.webp[Q=75,effort=6]
vips heifsave input.jpg output.avif[Q=60,compression=av1,effort=4]

cavif --speed va de 0 (le plus lent, le plus petit) à 10 (le plus rapide, le plus gros). La valeur 4 par défaut convient aux builds nocturnes ; montez à 9 pour les previews de PR où la vitesse l’emporte sur les octets.

5.3 Intégration au pipeline de build

La plupart des frameworks de sites statiques encapsulent déjà ces encodeurs. Choisissez celui qui correspond à votre stack :

// Next.js — next.config.js
module.exports = {
  images: {
    formats: ['image/avif', 'image/webp'],
    deviceSizes: [640, 828, 1080, 1200, 1920, 2400],
  },
};

// Astro — astro.config.mjs
import { defineConfig } from 'astro/config';
export default defineConfig({
  image: {
    service: { entrypoint: 'astro/assets/services/sharp' },
  },
});

// Programmatique — Sharp (Node.js)
import sharp from 'sharp';

await sharp('input.jpg')
  .resize({ width: 1600 })
  .avif({ quality: 60, effort: 4 })
  .toFile('output.avif');

await sharp('input.jpg')
  .resize({ width: 1600 })
  .webp({ quality: 75, effort: 6 })
  .toFile('output.webp');

Pour les tout petits assets (icônes de moins d’environ 5 Ko, avatars en ligne, en-têtes d’e-mail), sautez complètement le réseau et inlinez en data URI via encodage Base64. Cela échange une requête HTTP contre quelques octets supplémentaires de HTML, généralement gagnant en dessous de ~5 Ko.

Si vous hésitez entre des bibliothèques de compression côté client et côté Node (Sharp vs Squoosh vs browser-image-compression), le guide compression d’images : navigateur vs Node.js approfondit les benchmarks et les compromis.

6. Pièges et idées reçues

6.1 « AVIF gagne toujours » : sauf pour les captures d’écran et le line art

Les forces d’AVIF concernent les photographies en tons continus. Sur les captures d’écran avec du texte net, les copies d’interface et le pixel art, WebP produit souvent des fichiers plus petits à qualité équivalente. Le déblocage d’AVIF peut introduire un banding subtil sur les aplats de couleur. Lancez les conversions dans les deux sens et choisissez le gagnant par classe d’asset.

6.2 « Le WebP lossless remplace parfaitement le PNG transparent » : proche, pas identique

Le WebP lossless est véritablement plus petit que PNG, typiquement d’environ 26 %. La nuance : « lossless » s’applique à l’image compressée, mais l’encodeur peut tout de même altérer l’arrondi du canal alpha dans les régions à fort gradient. Pour une reproduction au pixel près (imagerie médicale, assets d’archives, tout ce qui est légalement tenu de correspondre à la source), conservez PNG. Pour tout le reste, le WebP lossless est un gain net.

6.3 « Il suffit d’uploader des fichiers .avif » : votre CDN ne sait peut-être pas ce que c’est

Les vieilles configs nginx et Apache sont antérieures à AVIF. Si /etc/nginx/mime.types ne liste pas image/avif avif;, nginx sert l’AVIF en application/octet-stream. Le navigateur voit le mauvais Content-Type, refuse de rendre l’image et retombe silencieusement sur JPEG, ce qui réduit à néant toute l’optimisation. Faites un curl sur l’URL de votre asset après le déploiement et vérifiez l’en-tête Content-Type. Cinq secondes de paranoïa épargnent une semaine de « pourquoi AVIF est cassé en prod ».

6.4 Le crash AVIF d’iOS 16.0–16.3

Certains fichiers AVIF déclenchent un crash de décodage Safari sur iOS 16.0–16.3. Le bug est corrigé en 16.4 (mars 2023), mais les MDM d’entreprise et les mises à jour OEM lentes maintiennent en vie les appareils plus anciens. Mitigation : ne livrez jamais d’AVIF sans une source WebP fonctionnelle dans le même <picture>, et ne définissez jamais un AVIF directement comme src d’<img>. Suivre les patterns de la section 4 vous protège déjà.

7. Antisèche 2026

Scénario	Principal	Fallback	Encodeur
Pages marketing statiques	AVIF q60	WebP q75 + JPEG q80	cavif + cwebp en CI
Articles de blog et docs	WebP q75	JPEG q80	compresseur d’images gratuit (manuel) ou Sharp (build)
Uploads utilisateurs	WebP (côté client)	JPEG (navigateur sans encodage WebP)	browser-image-compression + Sharp côté serveur pour AVIF
HDR / photographie pro	AVIF 10 bits q70	(aucun — abandonner le fallback SDR ou sauter AVIF complètement)	cavif + libavif mode HEIF
Diffusion CDN en temps réel	Négocié (AVIF ou WebP)	JPEG	Cloudflare Polish, Cloudinary `f_auto`, Vercel Image

Deux rappels avant la mise en production. Définissez toujours width et height sur l’<img> pour prévenir le CLS. Vérifiez toujours l’en-tête Content-Type de production sur au moins une réponse AVIF : une config MIME cassée tue silencieusement l’AVIF en production plus souvent que tout autre échec de cette liste.

FAQ

Ai-je encore besoin d’un fallback JPEG en 2026 ?

Oui. AVIF atteint environ 93 % des utilisateurs mondiaux et WebP environ 97 %. Cela laisse une population réduite mais bien réelle (vieux Edge, Firefox antérieur à 93, iOS avant 16.4, plus la zone du bug iOS 16.0–16.3) qui a besoin de JPEG. N’abandonnez JPEG que si vos analytics montrent un trafic effectivement nul depuis ces navigateurs et que vous pouvez le prouver.

Comment garder des builds CI rapides quand l’encodage AVIF est lent ?

Trois leviers. Utilisez cavif --speed 6 ou plus (4 par défaut) pour échanger ~5 % de taille contre ~3× de vitesse. Parallélisez sur plusieurs cœurs avec GNU parallel ou le pool de workers de votre outil de build. Et mettez en cache par hash de contenu pour que les images sources inchangées sautent complètement l’encodeur. Combinés, ces leviers ramènent généralement le temps de build AVIF en dessous de l’ancienne baseline mono-thread de WebP.

Le décodage WebP est-il vraiment plus rapide que celui d’AVIF ?

Oui. libwebp décode environ 2 à 3× plus vite que libavif, et l’écart se creuse sur le mobile bas de gamme. Si votre goulot d’étranglement de performance est le décodage (une longue galerie d’images sur un téléphone Android d’entrée de gamme, par exemple) plutôt que le réseau, WebP est le meilleur format principal. Pour l’essentiel du trafic web, les économies réseau dominent, et AVIF reste globalement gagnant.

Les utilisateurs d’iPhone peuvent-ils voir l’AVIF ?

Les iPhones tournant sur iOS 16.4 (mars 2023) ou plus récent supportent nativement AVIF dans Safari. Les appareils sur iOS 16.0–16.3 ont un bug de décodage documenté qui peut faire planter Safari sur certains fichiers AVIF ; les versions iOS antérieures ne supportent pas du tout AVIF. Livrez toujours un fallback WebP ou JPEG dans <picture> pour que les utilisateurs concernés voient quelque chose.

Faut-il utiliser `<picture>` ou la négociation par en-tête Accept ?

Les petits projets bénéficient d’un balisage <picture> explicite : le comportement est déterministe, vous pouvez déboguer en local, et cela ajoute peut-être 80 octets de HTML par image. Les sites à fort trafic gagnent avec la négociation Accept côté CDN : une URL par image, mises à niveau de format automatiques, et chaque format mis en cache séparément par le CDN. Un hybride courant consiste à utiliser <picture> pour l’UI applicative et la négociation CDN pour les assets marketing.

Pourquoi mon PNG est-il devenu plus gros après conversion en WebP ?

Presque toujours parce que le PNG source était déjà agressivement optimisé par pngquant, oxipng ou ZopfliPNG, et que l’encodeur Canvas du navigateur ne peut pas rivaliser avec ces outils. Ré-encodez depuis l’original (export Photoshop, master de l’outil de design, RAW) plutôt que depuis le PNG optimisé. Si le PNG optimisé est votre seule source, l’original est déjà quasi optimal : laissez-le tranquille.

AVIF supporte-t-il la transparence ?

Oui. AVIF supporte un canal alpha complet de 8 à 12 bits, et son encodage alpha est généralement plus compact que celui de WebP. Une illustration PNG transparente convertie en AVIF rétrécit typiquement de 50 à 70 %, contre 30 à 40 % en WebP. AVIF reste le remplaçant le plus solide du PNG transparent dans tout contexte qui n’exige pas une sortie lossless au pixel près.

Les navigateurs peuvent-ils encoder AVIF nativement via toBlob(‘image/avif’) ?

Seul Chrome 99+ pour le moment. Safari et Firefox savent décoder AVIF mais ne peuvent pas l’encoder via les API Canvas en mai 2026. Pour l’encodage AVIF côté client, il vous faut aujourd’hui des bibliothèques WebAssembly comme libavif-wasm ou jsquash, qui ajoutent 1 à 2 Mo de payload. La plupart des stacks de production compressent en WebP dans le navigateur et délèguent la génération AVIF à un worker côté serveur.