JPEG, PNG, WebP ou AVIF : quel format, et pourquoi

Deux questions, et le format en découle

Question un : l'image est-elle photographique ou à aplats ? Photographique signifie ton continu — peau, ciel, feuillage, bruit de capteur, aucune zone où la valeur saute d'un pixel à l'autre. À aplats signifie l'inverse : captures d'écran, logos, graphiques, schémas, dessin au trait, texte, tout ce qui présente de grandes zones uniformes séparées par des arêtes franches. Ce n'est pas une étiquette stylistique. C'est une description statistique des pixels, et les deux familles de compression ont été bâties pour des statistiques opposées.

Question deux : l'image a-t-elle besoin d'un canal alpha ou d'une animation ? Le JPEG n'a ni l'un ni l'autre et ne les aura jamais. Le PNG a l'alpha et ne s'anime que via APNG, une extension absente de la spécification d'origine. WebP et AVIF ont tous deux l'alpha et s'animent tous deux. S'il faut poser un logo sur un fond inconnu, le JPEG est écarté avant même la discussion sur la taille — un logo JPEG arrive avec un rectangle de fond incrusté.

Ce que la DCT et DEFLATE font réellement aux pixels

Le JPEG découpe l'image en blocs de 8 × 8 et réécrit chaque bloc comme une somme d'ondes cosinus, puis divise ces coefficients par une table de quantification et arrondit. Le détail fin loge dans les coefficients de haute fréquence, précisément ceux que la table divise le plus fort : ils s'arrondissent à zéro et disparaissent. Une photo le tolère car ses hautes fréquences sont largement du bruit. Une arête franche, non : une marche abrupte exige de nombreux termes de haute fréquence, et quand on les supprime la reconstruction dépasse puis sous-passe de part et d'autre de l'arête. C'est le halo, et c'est pourquoi un texte en JPEG paraît flou sur les bords même en haute qualité.

L'effet est mesurable, et strictement local aux arêtes. Dans notre image de test à aplats, nous avons pris une bande de 1040 pixels de large sur 70 de haut autour du titre. Dans l'original, 56 119 pixels de cette bande valent exactement 255,255,255. Après une seule passe JPEG en qualité 75, 6 352 d'entre eux — 11,3 % — ne sont plus blanc pur, avec un écart allant jusqu'à 14 niveaux. Dans une bande blanche vide de 86 400 pixels loin de toute arête, pas un pixel n'a bougé. Le JPEG ne dégrade pas l'image uniformément : il la dégrade exactement là où vit le dessin à aplats.

Le PNG procède à l'inverse. Il prédit chaque pixel à partir de ses voisins, soustrait la prédiction et confie les résidus à DEFLATE — le même algorithme qu'un fichier zip. Une suite de pixels identiques se comprime en presque rien, d'où l'excellent rendement sur une capture d'écran. Une photo n'a pas de suites : chaque pixel diffère légèrement de son voisin, les résidus sont du bruit, et DEFLATE n'a aucune prise. C'est toute l'explication des 2 021 576 octets qu'a exigés notre photo en PNG, contre 311 380 en JPEG.

Les deux mêmes images, quatre encodeurs, mesurés

Sur la photo, le classement est celui que tout le monde attend. PNG 2 021 576 octets, JPEG en qualité 75 311 380, AVIF à la qualité 75 de l'encodeur 174 774, WebP avec perte en qualité 75 105 608. Mais lis la dernière paire avec attention avant de conclure : la qualité 75 d'un codec n'est pas la qualité 75 d'un autre. Ce nombre est un index dans le quantificateur propre à cet encodeur, rien de plus. Ces chiffres disent seulement que ces deux encodeurs, à réglages nominalement identiques, ont atterri sur des points différents de la courbe taille-qualité — pas que le WebP bat l'AVIF. Toute comparaison honnête entre deux codecs fixe d'abord une métrique de qualité puis compare les octets, et c'est un exercice bien plus long que celui de cette page.

La capture à aplats offre le renversement intéressant. PNG 88 693 octets. JPEG au même réglage de qualité 75 : 152 065 octets — 1,71 fois le PNG, tout en jetant des pixels. WebP avec perte : 40 060 octets. WebP sans perte : 36 074 octets, à la fois plus petit que la version avec perte et exact au pixel. Ce n'est pas une anomalie. Le WebP avec perte sous-échantillonne toujours la chrominance en 4:2:0 : le texte coloré et les fins filets colorés perdent la moitié de la résolution couleur horizontale et verticale, et l'encodeur dépense ensuite des bits à reconstruire des arêtes qu'il vient lui-même de flouter. Sur du dessin à aplats, le sans-perte est fréquemment à la fois plus petit et meilleur.

La porte à sens unique — et le mythe du ré-enregistrement

La perte est réellement à sens unique. Nous avons converti notre original PNG en JPEG qualité 75 puis de nouveau en PNG : le PNG revenu pèse 1 470 130 octets, contre 2 021 576 pour l'original. Il est plus petit parce que la passe JPEG a lissé du détail hors de l'image, et aucun encodeur PNG ne peut le remettre. À partir de là le fichier est sans perte, mais il stocke sans perte une image abîmée. PNG → JPEG → PNG ne rend jamais l'original, et la taille réduite en est la preuve, pas un bonus.

La version populaire — chaque ré-enregistrement aggrave les dégâts — se révèle fausse telle qu'on l'énonce d'ordinaire, et nous l'avons mesuré. Réencoder dix fois le même JPEG au réglage de qualité identique, sans recadrage, sans redimensionnement et sans retouche entre les passes, a fait passer l'erreur absolue moyenne de 1,7591 à 1,7670 niveau. Soit une dérive de huit millièmes de niveau sur dix générations : la requantification JPEG est proche d'un point fixe tant que la grille 8 × 8 reste alignée et que la table de quantification ne change pas.

Change quoi que ce soit entre deux enregistrements et le cumul est immédiat. Nous avons repris la chaîne avec un petit recadrage centré avant chaque enregistrement, ce qui décale l'image par rapport à la grille 8 × 8. Après six cycles, l'erreur absolue moyenne face à un encodage en une passe du même recadrage était passée de 1,76 à 2,32 niveaux — 32 % d'erreur en plus — alors qu'encoder ce même recadrage une seule fois depuis l'original intact restait plat à environ 1,77, quel que soit le cycle comparé. La règle pratique n'est donc pas « ne jamais ré-enregistrer » : garde l'original sans perte, repars de lui à chaque retouche, et exporte en JPEG ou WebP en dernière étape plutôt qu'en fichier de travail.

Alpha, profondeur de bits et les plafonds dont personne ne parle

Le PNG stocke jusqu'à 16 bits par canal ; le JPEG, tel que les navigateurs l'implémentent, 8. Le WebP est en 8 bits dans les deux modes, et son mode avec perte est toujours en 4:2:0. L'AVIF atteint 10 et 12 bits et peut encoder en 4:4:4, ce qui en fait le seul des quatre à traiter un large dégradé doux sans bandes, et le seul à avoir une vraie réponse pour le HDR. Si ton image est un ciel de couchant ou un fond produit tout en douceur, cette profondeur vaut plus que n'importe quelle taille du tableau ci-dessus.

Le WebP porte un plafond dur qui surprend la première fois : le conteneur code la largeur et la hauteur sur 14 bits, donc aucun WebP ne peut dépasser 16 383 pixels de côté. Sans conséquence pour une photo web, rédhibitoire pour une carte numérisée ou un long panorama assemblé. L'AVIF et le PNG n'ont pas de limite comparable aux tailles que tu produiras. Bon à savoir avant de bâtir une chaîne qui convertit tout en WebP par défaut.

Prise en charge, coût d'encodage, et la règle qui en découle

La prise en charge n'est plus le facteur décisif qu'elle était il y a cinq ans. Le WebP est arrivé de longue date dans Chrome, dans Firefox 65 en janvier 2019 et dans Safari 14 en septembre 2020. L'AVIF est arrivé dans Chrome 85 en août 2020, Firefox 93 en octobre 2021, Safari 16 en septembre 2022 et enfin Edge 121 en janvier 2024 — Edge fut le dernier grand navigateur à l'adopter. Toute version actuelle de tout grand navigateur décode les deux. Reste une longue traîne de systèmes anciens qui ne peuvent plus mettre à jour leur navigateur : c'est précisément à cela que sert l'élément picture avec des sources et un repli JPEG.

C'est le coût d'encodage qui contraint désormais. Sur la même machine et la même photo 1600 × 900, meilleur de cinq exécutions : WebP 287 ms, AVIF 1 163 ms, JPEG 119 ms. L'AVIF a pris quatre fois plus longtemps que le WebP, et près de dix fois plus longtemps que le JPEG produit par le même outil. Des encodeurs différents sont en jeu — cwebp pour le WebP, le cadre image du système pour l'AVIF et le JPEG — donc traite le ratio exact comme indicatif, non universel. La direction, elle, ne fait pas de doute : l'AVIF est du codage intra AV1, il explore un espace bien plus vaste et il est lent par construction. Sur un lot de cent mille images, c'est une vraie ligne budgétaire, et c'est pourquoi beaucoup d'équipes s'arrêtent au WebP.

La règle qui en découle tient en trois lignes. Photo sans transparence : WebP ou AVIF, avec le JPEG derrière pour les clients anciens. Capture d'écran, logo, graphique, tout ce qui est à aplats : WebP sans perte d'abord, PNG en repli sûr, et jamais de JPEG. Tout ce qui exige l'alpha ou l'animation : WebP ou AVIF, ou PNG si la palette est réduite et que le sans-perte compte plus que les octets.

Questions fréquentes

Le WebP est-il toujours plus petit que le JPEG ?

Non. C'est généralement vrai sur les photos, et sur la nôtre il était 66 % plus petit à réglage nominalement identique — mais ces réglages ne sont pas comparables entre codecs, et un JPEG déjà fortement compressé peut grossir en passant au WebP, car l'encodeur doit désormais reproduire les blocs du JPEG comme s'il s'agissait de détail. Mesure toujours sur tes propres images plutôt que de croire un pourcentage d'accroche.

Convertir un vieux JPEG en WebP ou AVIF restaure-t-il la qualité ?

Non. Le détail jeté par le JPEG n'est plus dans le fichier, donc rien en aval ne peut le récupérer. La conversion reste utile pour économiser de la bande passante, et un bon encodeur n'ajoutera pas beaucoup de dégâts, mais le plafond est fixé par le JPEG de départ. Si le raw ou le PNG d'origine existe encore, réexporte depuis lui — cela ne coûte rien de plus et le résultat est réellement meilleur.

Faut-il encore publier du JPEG ?

Comme repli à l'intérieur d'un élément picture, oui — cela coûte un fichier de plus et couvre tout appareil jamais construit. Comme format principal pour du travail neuf, il n'existe plus de cas photographique où le JPEG l'emporte en taille à qualité égale, ni aucun cas à aplats où il l'emporte tout court. Il reste aussi la chose la plus sûre à remettre à quelqu'un qui l'ouvrira dans un logiciel inconnu, d'où sa persistance dans les pièces jointes et chez l'imprimeur.

PNG-8 ou PNG-24 pour un logo ?

Le PNG-8 stocke une palette indexée d'au plus 256 couleurs et devient nettement plus petit quand le dessin a réellement peu de couleurs — c'est le cas de la plupart des logos plats. Le PNG-24 stocke la couleur pleine et ne sert qu'aux dégradés ou aux ombres douces. Vérifie le résultat plutôt que l'étiquette : si la version palette est visuellement identique, garde-la. Et compare les deux au WebP sans perte, qui a battu le PNG de 59 % sur notre image de test à aplats.

L'AVIF vaut-il le temps d'encodage supplémentaire ?

Cela dépend entièrement du rapport entre nombre d'encodages et nombre de livraisons. Une image d'accueil encodée une fois et servie un million de fois : encode-la en AVIF et accepte la seconde de plus. Du contenu uploadé par les utilisateurs et encodé à la volée : quatre fois le CPU par image est un coût d'exploitation sérieux, et le WebP est le choix pragmatique. L'AVIF gagne aussi sa place sur les larges dégradés doux, où ses modes 10 et 12 bits évitent des bandes que les formats 8 bits ne peuvent pas éviter.

Pourquoi le WebP sans perte a-t-il battu le WebP avec perte sur la capture ?

Parce que le codage avec perte est le mauvais outil pour ces données. La capture est faite surtout de longues suites de pixels identiques, que le mode sans perte encode presque gratuitement, tandis que le mode avec perte sous-échantillonne d'abord la couleur puis dépense des bits à décrire les arêtes qu'il a floutées. Nous avons mesuré 36 074 octets sans perte contre 40 060 avec perte — plus petit et exact au pixel. Si ton image est à aplats, essaie le sans-perte avant de toucher au curseur de qualité.