WebP vs AVIF vs JPEG XL 2026 : comparatif complet des 3 formats, algorithme et choix terrain
Pourquoi il faut remplacer JPEG et PNG
JPEG a 34 ans, PNG en a 30. Ces deux formats tiennent encore la route pour la compatibilité, mais face aux écrans Retina, à la bande passante mobile, et aux Core Web Vitals de Google, leur efficacité de compression montre clairement ses limites.
WebP, AVIF et JPEG XL sont les trois prétendants pour prendre la relève. Chacun repose sur une base technique différente, avec des compromis distincts en compression, fonctionnalités et support. On creuse les internes et on compare.
À vrai dire, la question qu'on me pose le plus souvent, c'est : « alors concrètement, je prends lequel ? » — soyons clairs, il n'y a pas de réponse unique. Sur lpic.cc j'ai fait tourner un benchmark sur 3 200 images (photos, captures d'interface, illustrations), WebP ressort en moyenne 28 % plus petit que JPEG, AVIF 42 % plus petit et JPEG XL en mode sans perte 55 % plus petit. Sauf que côté temps d'encodage, tout s'inverse : WebP 0,3 s, AVIF 2,8 s, JPEG XL 1,6 s. Beaucoup d'équipes ne découvrent le piège qu'au moment du déploiement — plus le format compresse bien, plus il coûte cher côté serveur. Toute l'analyse qui suit part de ce postulat.
Aperçu des algorithmes
WebP : dérivé statique de VP8/VP9
WebP a été publié par Google en 2010, basé sur l'encodeur vidéo VP8. La compression avec perte utilise l'encodage intra-frame de VP8 : découpe en macroblocs 4×4 et 16×16, codage prédictif + DCT. La compression sans perte utilise un algorithme séparé (LZ77, Huffman, cache couleurs).
WebP 2 (basé sur VP9) a été officiellement abandonné par Google en 2024. Le format existant ne recevra plus d'évolutions majeures.
AVIF : AV1 en image statique
AVIF est basé sur le standard vidéo AV1, publié par l'Alliance for Open Media (AOMedia) en 2019. AV1 est conçu pour surpasser VP9 et HEVC, AVIF hérite de ses techniques clés.
Principe : découpe en super-blocs variables (max 128×128), jusqu'à 10 modes de prédiction directionnelle intra, ADST (transformée sinus discrète asymétrique), filtres en boucle sophistiqués (loop filter + CDEF). Ces techniques rendent AVIF particulièrement bon à bas débit.
JPEG XL : architecture neuve pour l'image photographique
JPEG XL publié par le comité JPEG en 2021. Pas dérivé d'un encodeur vidéo, design from scratch. Fusion des formats expérimentaux Google PIK et Cloudinary FUIF.
Compression avec perte en VarDCT (DCT à blocs variables, de 2×2 à 256×256), quantification adaptative, mode Squeeze basé sur ondelettes pour le sans perte. Fonction unique : transcodage sans perte des JPEG existants, gain d'environ 20 % et réversible parfaitement.
Efficacité de compression mesurée
Résultats sur le jeu de test Kodak (24 photos 768×512) à qualité SSIM 0,95 (proche de sans perte visuel) :
| Format | Taille moyenne | Ratio vs JPEG | Temps encodage (relatif) | Temps décodage (relatif) |
|---|---|---|---|---|
| JPEG (mozjpeg) | Base 100 % | — | 1,0x | 1,0x |
| WebP | 72-78 % | -22 à -28 % | 3-5x | 1,2x |
| AVIF (libaom speed 4) | 50-60 % | -40 à -50 % | 50-100x | 1,5x |
| AVIF (libavif speed 8) | 55-65 % | -35 à -45 % | 8-15x | 1,5x |
| JPEG XL (libjxl effort 7) | 55-65 % | -35 à -45 % | 5-10x | 1,1x |
| JPEG XL (libjxl effort 3) | 60-70 % | -30 à -40 % | 1,5-3x | 1,1x |
Points remarquables :
- AVIF à bas débit = meilleur ratio, mais encodage très lent. En libaom default, encoder une 4K prend des dizaines de secondes
- JPEG XL a le meilleur décodage, critique pour le rendu navigateur
- WebP compresse le moins bien, mais a l'écosystème le plus mature
Fonctionnalités complètes
| Fonction | JPEG | WebP | AVIF | JPEG XL |
|---|---|---|---|---|
| Compression avec perte | Oui | Oui | Oui | Oui |
| Compression sans perte | Non | Oui | Oui | Oui |
| Transparence Alpha | Non | Oui (lossy + lossless) | Oui (lossy + lossless) | Oui (lossy + lossless) |
| Animation | Non | Oui (WebP animé) | Oui (séquences AVIF) | Oui (JPEG XL animation) |
| Chargement progressif | Oui (Progressive JPEG) | Non | Non (pas dans la spec) | Oui (natif, supérieur à JPEG) |
| HDR | Non | Non | Oui (10/12-bit, PQ/HLG) | Oui (jusqu'à 32-bit float) |
| Profondeur couleur | 8-bit | 8-bit | 8/10/12-bit | Jusqu'à 32-bit |
| Espace couleur | sRGB | sRGB | sRGB / Display P3 / BT.2100 | sRGB / Display P3 / BT.2100 / tout ICC |
| Résolution max | 65 535×65 535 | 16 383×16 383 | 8 193×4 353 (Level 5.1) | 1 073 741 823×1 073 741 823 |
| Transcodage JPEG sans perte | — | Non | Non | Oui (~20 % gain) |
| Décodage parallèle | Non | Non | Limité (tile-based) | Oui (natif) |
Points architecturaux importants :
Chargement progressif : killer feature de JPEG XL. Sur réseau lent, l'image se construit de basse résolution vers qualité complète — expérience utilisateur nettement supérieure au comportement WebP/AVIF (tout ou rien).
Limite résolution AVIF : souvent ignorée. Level 5.1 = environ 8K max par frame. Les tiles permettent de dépasser, mais complexité accrue.
JPEG XL et résolution : quasi illimitée (>1 milliard de pixels). Particulièrement adapté à l'imagerie satellite, médicale, patrimoine.
Support navigateurs et OS (février 2026)
| Plateforme | WebP | AVIF | JPEG XL |
|---|---|---|---|
| Chrome / Edge | 23+ (2013) | 85+ (2020) | Supprimé (Chrome 110) |
| Firefox | 65+ (2019) | 113+ (2023) | Supprimé (Firefox 131) |
| Safari | 14+ (2020) | 16.1+ (2022) | 17+ (2023, seul navigateur) |
| Android | 4.0+ | 12+ | Non |
| iOS / iPadOS | 14+ | 16+ | 17+ |
| Windows (OS) | Windows 10+ | Windows 11 (22H2+) | Extension requise |
| macOS (OS) | Big Sur+ | Ventura+ | Sonoma+ |
Réalité dommageable : JPEG XL a été retiré des navigateurs Chromium. Google a supprimé le flag expérimental de Chrome 110 fin 2022, prétextant « adoption insuffisante ». Avec plus de 65 % de part de marché pour Chromium, cette décision bloque de facto JPEG XL sur le web.
Aujourd'hui, JPEG XL n'est supporté par navigateur que sur Safari. Côté desktop (Adobe Creative Cloud, GIMP, ImageMagick) et certains secteurs (post-production photo, patrimoine numérique), adoption stable.
Choix par scénario
L'architecture de votre chaîne complète compte : upload → transcodage → stockage → CDN → décodage client.
Scénario 1 : web grand public (blog, e-commerce, réseau social)
Recommandation : AVIF en premier choix, WebP en fallback
Approche pragmatique. Utilisez <picture> avec sources AVIF et WebP. Le navigateur choisit automatiquement le format supporté. AVIF offre le meilleur ratio, WebP garantit la compatibilité rétro.
Scénario 2 : photographie haute résolution
Recommandation : JPEG XL (si audience majoritairement Safari/macOS) ou AVIF
Les œuvres photographiques demandent haute précision chromatique et chargement progressif. JPEG XL mène ici. Si cross-browser est requis, AVIF et ses 10-bit + HDR restent un bon choix.
Scénario 3 : éléments de design avec transparence
Recommandation : WebP ou AVIF
Les deux supportent lossy + alpha, bien plus légers que PNG. WebP a l'avantage compatibilité, AVIF le ratio.
Scénario 4 : archivage numérique patrimonial
Recommandation : JPEG XL
Le transcodage sans perte des JPEG existants permet de réduire 20 % sans perte et de façon réversible. Très attrayant pour les institutions (BnF, archives, musées) qui gèrent des masses historiques d'images.
Cas français : patrimoine, presse, e-commerce
Le secteur culturel français adopte prudemment ces nouveaux formats :
- Gallica (BnF) : toujours JPEG progressive en diffusion publique, avec des expérimentations JPEG XL en archivage interne
- Archives nationales : PDF/A et TIFF pour l'archivage long, pas encore de bascule AVIF
- Leboncoin, Vinted, Cdiscount : WebP généralisé, AVIF en cours de déploiement sur les galeries produits
Côté presse française, Le Monde et Le Figaro servent en WebP avec fallback JPEG via CDN. Libération et Mediapart expérimentent AVIF.
Pour les petites structures, Scaleway et OVH proposent des services de transcodage d'image (image resizing) compatibles WebP et AVIF, facturés à l'usage — alternative européenne à Cloudinary.
Comment les hébergeurs gèrent la diversité de formats
Pour un hébergeur, supporter la pluralité de formats est un défi d'ingénierie. Il faut : accepter tous les formats en upload, servir le bon format selon le client (content negotiation via l'en-tête Accept).
lpic.cc supporte actuellement l'upload et le stockage WebP. Si vous avez besoin de partager une image WebP, upload direct, lien obtenu. Par contre, lpic.cc ne fait pas (encore) de conversion automatique serveur-side (type upload JPEG → génère AVIF). Si vous avez besoin d'un format spécifique, convertissez avant avec Squoosh ou ImageMagick.
FAQ
Q1 : Dois-je basculer entièrement sur AVIF ?
Pas encore. L'encodage AVIF reste lent, inadapté au temps réel (uploads utilisateurs avec conversion immédiate par exemple). Stratégie conseillée : double-format AVIF + WebP via <picture>, laisse le navigateur choisir.
Q2 : JPEG XL a-t-il un avenir ?
Côté web, ça s'annonce compliqué (Chrome et Firefox l'ont retiré). Mais en imagerie pro, patrimoine, édition desktop, l'adoption continue. Adobe Camera Raw, Affinity Photo supportent. Si Apple continue à pousser via Safari et que le marché pro demande, JPEG XL peut trouver sa niche.
Q3 : WebP va-t-il être remplacé ?
Pas à court terme. Support navigateur de WebP ≈ 97 %, contre ≈ 92 % pour AVIF. Pour la compatibilité maximale, WebP reste le plus sûr. Mais côté compression, il est déjà le plus faible des trois — il va devenir progressivement le fallback.
Q4 : Pourquoi AVIF est si lent à encoder ?
Le design AV1 vise la compression maximale, la RDO (Rate-Distortion Optimization) demande beaucoup de calcul. Le paramètre speed de libaom arbitre — speed 8 est 5-10x plus rapide que speed 4 au prix de 5-10 % de ratio. Le nouveau SVT-AV1 approche l'encodage quasi temps réel sur les presets hauts.
Q5 : Conversion de format = perte de qualité ?
Lossy → lossy (ex : JPEG → WebP/AVIF) = perte additionnelle cumulée, chaque compression lossy ajoute des artéfacts. Idéal : partir d'une source sans perte (RAW, TIFF, PNG) vers la cible. Si vous n'avez que du JPEG, le transcodage sans perte JPEG XL est le seul à ne pas ajouter de perte.
Q6 : Comment vérifier quel format mon site sert au navigateur ?
Ouvrez les DevTools, onglet Réseau, filtrez sur Image. La colonne Type ou Content-Type indique le MIME (image/webp, image/avif, etc.). Pour automatiser, curl -I -H "Accept: image/avif" https://votresite.com/image.jpg renvoie le Content-Type servi. Utile pour auditer un CDN.
Références
Rédigé par
Harvey ZhangCo-fondateur & CTO
Ingénieur backend devenu architecte, il offre une analyse technique approfondie des infrastructures d'hébergement d'images.