PNG vs JPG vs WebP vs AVIF

PNG, JPG, WebP et AVIF compressent les mêmes pixels sous des contrats différents. PNG est sans perte et prend en charge la transparence ; JPG est avec perte, bien plus petit pour les photographies, et n’a pas de canal alpha. WebP et AVIF font les deux, chacun environ un quart plus petit que le précédent. En 2026, les quatre se décodent nativement dans tous les principaux navigateurs.

100 % local

Chaque fichier image répond à la même question — comment stocker ces pixels en moins d’octets ? — avec une stratégie différente. PNG refuse de perdre de l’information et compresse la structure à la place. JPG jette de l’information de manière ordonnée et aveugle à l’œil humain, ce qui lui achète des gains spectaculaires sur les photographies. WebP et AVIF sont la génération moderne : ils font les deux travaux avec de meilleures mathématiques et, en général, des fichiers plus petits.

Les compromis concernent désormais presque entièrement le contenu, plus la compatibilité. WebP est arrivé dans tous les principaux navigateurs en 2020 et AVIF l’a suivi en 2023-2024, si bien qu’en 2026 les quatre formats se décodent nativement partout où cela compte, Safari inclus. Ce qui décide du choix, c’est ce que contient l’image : contours nets ou dégradés, texte ou peau, capture d’écran ou photographie, et si la transparence ou une taille de fichier cible est non négociable.

Ce guide compare les quatre formats précisément sur ces axes, explique pourquoi chacun compresse mal certains contenus, et couvre les métadonnées qui voyagent dans le conteneur. Tout ce qui est lié ici — convertisseur, compresseur, outil de redimensionnement — s’exécute localement dans votre navigateur : tester une hypothèse sur votre propre fichier ne coûte rien et n’envoie rien.

Une fois le format choisi, le moyen le plus rapide de passer à l’action est le convertisseur d’images qui transcode entre PNG, JPG, WebP et AVIF directement dans l’onglet, sans aucun envoi.

Quand l’exigence est un plafond de taille strict plutôt qu’un format, le guide pas à pas sur la compression vers une cible de 100KB montre comment descendre le curseur de qualité jusqu’à une cible exacte, en vérifiant la qualité à l’œil à chaque étape.

Sans perte ou avec perte : la décision dont tout le reste découle

La compression sans perte réorganise les données de façon à reconstruire des pixels identiques au bit près ; la compression avec perte approxime l’image en gardant ce que la vision humaine a le moins de chances de remarquer. La compression sans perte n’est pas plus petite par définition — sur une photographie bruitée, elle peut perdre lourdement — et la compression avec perte n’est pas moche par définition. Chacune gagne sur le contenu pour lequel elle a été conçue ; c’est pourquoi la première question n’est jamais « quel est le meilleur format » mais « que contient l’image ».

Trois caractéristiques du contenu le déterminent. Les photographies et les dégradés doux traversent la compression avec perte sans encombre ; les graphismes à contours nets, le texte et les captures d’écran la punissent d’artefacts de ringing le long de chaque contour. Le bruit pénalise tout format, mais il détruit les ratios sans perte, car le bruit est de l’information maximale. Et la transparence est une exigence impérative qui disqualifie immédiatement JPG.

Format	Compression	Transparence	Contenu typique le mieux adapté
PNG	Sans perte (DEFLATE)	Alpha complet	Captures d’écran, interfaces, logos, dessin au trait
JPG	Avec perte (blocs DCT)	Aucune	Photographies, tons continus
WebP	Avec et sans perte	Alpha complet	Les deux rôles ; solide généraliste
AVIF	Avec et sans perte	Alpha complet	Photos aux tailles les plus réduites ; animation

PNG : pixels exacts, alpha et métadonnées

PNG stocke les pixels sans perte : le décodeur reproduit l’image originale exactement, à chaque fois, voilà pourquoi c’est le choix par défaut pour les captures d’écran, les exports de design et tout ce qui contient du texte. Il compresse en filtrant chaque ligne de balayage par rapport à sa voisine, puis en appliquant la compression générale DEFLATE — la même famille de mathématiques que ZIP. Cette stratégie adore la structure répétée (couleurs unies, interface alignée, bords nets), et c’est pourquoi la capture d’écran nette d’une application se compresse souvent à une fraction de sa taille brute.

La même stratégie explique pourquoi PNG peine sur les photographies : la texture organique est proche du hasard, les filtres ne peuvent pas la prédire, et le fichier enfle. PNG embarque aussi un alpha 8 bits complet, si bien que les logos aux bords adoucis sur n’importe quel fond restent nets, et son conteneur laisse la place à des métadonnées riches — blocs EXIF compris — ce qui redevient important dans la dernière section de ce guide.

JPG : avec perte, minuscule pour les photos, allergique aux contours

JPG découpe l’image en blocs de 8 par 8 pixels, transforme chacun en données de fréquences (la transformée en cosinus discrète) et jette les fréquences auxquelles l’œil est le moins sensible. Le réglage de qualité est le curseur de l’abandon : à 80-90, une photographie semble quasiment intacte pour une fraction de sa taille brute, et en dessous d’environ 50, ce sont les blocs eux-mêmes qui deviennent visibles sous la forme des artefacts de blocs caractéristiques du format.

Deux conséquences de cette conception comptent en pratique. D’abord, jamais de transparence — le format n’a pas de canal alpha, et un fichier que vous voulez détourer en transparent arrivera avec un fond incrusté. Ensuite, les contours nets souffrent : une bordure d’interface d'1 pixel ou un petit texte répartit son énergie sur plusieurs blocs 8×8, et la reconstruction l’étale en bruit moustique et en images fantômes. Le sous-échantillonnage de la chrominance (moyennage du détail de couleur à demi-résolution) ajoute encore du flou sur le texte rouge et bleu. Gardez JPG pour ce pour quoi il a été conçu : les photographies en tons continus.

WebP et AVIF : le duo moderne

WebP, de Google, fait les deux travaux : un mode avec perte fondé sur les mêmes idées de codage prédictif que la compression vidéo (VP8), et un mode sans perte distinct qui bat généralement PNG d’environ un quart. Ses photos avec perte se retrouvent environ 25-35% plus petites que JPG à qualité visuelle comparable, et contrairement à JPG il prend en charge l’alpha dans les deux modes — une image photographique avec une vraie transparence tient enfin dans un petit fichier.

AVIF, construit sur le codec vidéo AV1, est la frontière actuelle : le codage intra plus des outils de prédiction plus riches le rendent environ 20% plus petit que WebP sur un contenu typique, avec un traitement nettement meilleur des dégradés qui créent des bandes dans les autres formats, et il prend en charge les profondeurs de 8 bits et plus, l’animation et l’alpha. Les coûts sont réels pourtant : l’encodage est considérablement plus lent (des secondes au lieu de millisecondes à effort élevé), et la prise en charge par l’outillage est plus mince. C’est le format à choisir quand les octets sont la contrainte bloquante et pas le temps d’encodage.

Face à JPG à qualité similaire	Gain typique	Réserve
WebP (avec perte)	≈ 25-35% plus petit	Le mode sans perte est un codec distinct ; il se compare à PNG à la place
AVIF (avec perte)	≈ 20% plus petit que WebP	Encodage bien plus lent ; outillage moins fourni
WebP (sans perte)	≈ 25% plus petit que PNG	Ne perd nulle part face à PNG — même garantie sans perte

Prise en charge par les navigateurs en 2026

La question de la compatibilité est réglée. WebP est universel depuis que Safari 14 l’a intégré en 2020 ; AVIF est arrivé dans Chrome 85 et Firefox 93 en 2020-2021, puis dans Safari 16.4 en 2023, offrant une couverture evergreen complète jusqu’aux versions 2024-2025. Le WebP animé et l’AVIF animé se décodent aussi partout dans les navigateurs actuels.

Les réserves restantes touchent les marges, pas le courant principal : les très vieilles versions de Safari (iOS 13 et antérieures) n’ont pas WebP, certains fichiers AVIF utilisant des profils exotiques à haute profondeur de bits ou 12 bits se décodent dans moins de moteurs, et la prise en charge d’AVIF dans les logiciels hors navigateur — aperçus de l’OS, anciens outils de design, pipelines CMS — accuse encore du retard sur sa prise en charge dans les navigateurs. Servir de l’AVIF avec un repli WebP ou JPG via l’élément picture reste le schéma défensif pour tout contenu fourni par l’utilisateur.

Format	Présent partout depuis	Repli encore utile pour
PNG, JPG	Les années 1990	Jamais — réellement universel
WebP	2020 (Safari 14 était le dernier récalcitrant)	iOS 13 et antérieur, intégrations anciennes
AVIF	2023 (Safari 16.4 était le dernier grand moteur)	Safari plus ancien, visionneuses hors navigateur, pipelines CMS

EXIF : les métadonnées vivent dans le conteneur, pas dans les pixels

Un fichier image, c’est deux choses : des données de pixels, et un conteneur autour qui peut porter des métadonnées — des blocs EXIF consignant le modèle d’appareil photo, l’exposition, l’orientation, les horodatages et souvent les coordonnées GPS. Une propriété cruciale s’ensuit : les métadonnées appartiennent au fichier, pas à l’image. Copiez un JPG et l’EXIF voyage avec lui ; réencodez la même photo en WebP ou AVIF et le nouveau conteneur démarre vide, sauf si un outil copie délibérément les anciennes métadonnées.

Cela a deux facettes pratiques. Confidentialité : une photo partagée directement depuis l’appareil photo peut publier votre position, voilà pourquoi la suppression des métadonnées est une fonctionnalité de tout convertisseur digne de ce nom — le réencodage est la suppression fiable. Flux de travail : l’orientation et les horodatages peuvent être utiles, donc si un pipeline en a besoin, il faut demander à l’outil de préserver l’EXIF au lieu de le présumer. Dans tous les cas, la décision vit dans le conteneur, et la conversion est le moment où elle se prend.

Questions fréquentes

Mes images sont-elles envoyées quand je les compresse ou les convertis ici ?

Non. Le décodage, le réencodage et le redimensionnement s’exécutent tous dans votre navigateur avec ses propres codecs d’images ; le fichier ne quitte jamais l’onglet. Vérifiez-le dans les DevTools : ouvrez le panneau Network, convertissez une image et regardez la liste des requêtes rester vide. La Content-Security-Policy du site interdit aussi les connexions sortantes depuis les scripts de la page.

Quel format utiliser pour les captures d’écran et les captures d’interface ?

PNG, ou WebP en mode sans perte si la taille compte. Les captures d’écran sont pleines de contours nets, de texte et d’aplats — du contenu que la compression sans perte écrase et que la compression avec perte étale. Une capture d’écran en JPG montre des artefacts de ringing autour de chaque glyphe et de chaque bord de bouton ; le PNG de la même capture est de toute façon généralement plus petit, car son contenu est hautement prévisible.

Pourquoi mon PNG est-il plus gros que le JPG de la même photo ?

Parce que les photographies sont presque aléatoires pour un codec sans perte. PNG doit reconstruire chaque pixel exactement, et la texture organique, le bruit du capteur et le grain déjouent ses prédicteurs, si bien qu’il stocke presque tout à un coût élevé. JPG jette à la place les parties imperceptibles. La même photo peut facilement être cinq à dix fois plus grosse en PNG qu’en un bon JPG ou WebP.

La conversion d’une image supprime-t-elle ses données EXIF ?

Réencoder vers un format différent démarre un nouveau conteneur, donc l’EXIF ne survit pas par défaut — ce qui supprime au passage les données GPS et d’appareil photo. Dans un même format, certains outils copient les métadonnées, si bien que la suppression n’arrive jamais par hasard. Si la confidentialité compte, convertissez une fois et vérifiez les propriétés du résultat ; si l’orientation compte, assurez-vous que l’outil la préserve ou l’incruste.

AVIF est-il toujours plus petit que WebP ?

Non — en moyenne environ 20% plus petit à qualité similaire, mais l’écart est large. AVIF prend le plus d’avance sur les photographies et les dégradés ; des graphismes simples en aplats peuvent se compresser à des tailles presque identiques, et une poignée d’images inversent même le classement. Le temps d’encodage est l’autre coût : AVIF à effort élevé prend des ordres de grandeur plus de temps, ce qui compte dans les pipelines de build.

Quel réglage de qualité utiliser pour des images avec perte ?

Pour les photographies, commencez vers 75-85 : en dessous, les blocs et le flou apparaissent vite ; au-dessus d’environ 90, vous payez de vrais octets pour des différences invisibles à l’œil. Les graphismes avec du texte et des contours tolèrent mal la compression avec perte à n’importe quel réglage ; préférez donc le sans perte. Jugez à l’œil sur votre propre contenu à un zoom de 100% — les réglages interagissent avec la résolution et le contenu, pas seulement entre eux.

Équipe ToolsByUs · Comment nous vérifions nos outils