Pourquoi une image compressée grossit, et comment l'éviter

Vous passez une image dans un compresseur ou un convertisseur, et le fichier téléchargé pèse plus lourd que celui de départ. Le plus souvent, ce n'est pas un bug : l'encodeur décrit les pixels qu'il reçoit dans le format demandé, et cette description est parfois plus longue que celle que vous aviez.

En bref : le fichier grossit quand les nouveaux réglages conservent plus de données que l'ancien fichier (un JPEG très compressé réenregistré à une qualité plus élevée), quand une photo compressée avec perte passe dans un format sans perte (JPG vers PNG), quand l'encodeur abandonne une astuce que l'original utilisait (un PNG à palette réenregistré en 32 bits), quand le coût fixe du format pèse plus que l'image elle-même parce qu'elle est minuscule, ou quand le nombre de pixels augmente. Dans nos tests, un JPEG de 135 Ko est devenu un PNG de 2,21 Mo, et une icône de 504 octets a donné un WebP de 1 104 octets. La solution consiste en général à garder l'original, à choisir un autre format ou à baisser la qualité ; chaque section ci-dessous indique laquelle.

Les neuf cas en un coup d'œil

Tous les chiffres viennent d'une seule série de mesures sur notre machine. Les tailles sont en octets exacts ; dans le texte, 1 Ko vaut 1 000 octets.

Comment nous avons testé

Tout a été mesuré le 16 octobre 2026 (UTC) sur un Mac Apple M4 sous macOS 26.6.2.

• Encodeurs du navigateur : Google Chrome 155.0.8059.85 en mode headless. Nous avons chargé browser-image-compression 2.0.2, la bibliothèque qui fait tourner notre compresseur d'images, dans une page locale vierge, avec les réglages par défaut du compresseur : qualité 0,8, taille cible de 1 Mo, côté long limité à 1920 px, format d'origine conservé, EXIF supprimées et jusqu'à 30 passes de nouvelle tentative. Les cas de conversion reprennent les appels canvas de nos pages de conversion : dessiner l'image, remplir le fond en blanc pour le JPG, puis canvas.toBlob à la qualité par défaut du convertisseur, 90 %. Nous n'avons pas cliqué dans le site lui-même : le code exécuté est le même, mais la page autour était une page de test.
• Autres encodeurs : sharp 0.35.5 sous Node v26.12.0 (libvips 8.18.7, mozjpeg, libwebp 1.6.0, libaom 3.15.1, libimagequant 2.4.1, libpng 1.6.58) et upng-js 2.1.0, l'encodeur PNG/APNG qu'appelle notre convertisseur GIF vers APNG.
• Images : une photo de paysage CC0 de Bonnie Moreland (Wikimedia Commons), prise en sortie de notre compresseur lors d'un banc d'essai précédent (1920 x 1280, 250 382 octets), ainsi qu'une version réencodée par mozjpeg en qualité 70 (135 151 octets) ; l'image de test Kodak kodim04 (PNG 512 x 768, mise à disposition par Kodak sans restriction d'usage) ; une capture d'écran de notre propre page /compress (PNG 1440 x 900) ; le « NEW LOGO R » d'Enzy Cell, sous CC0 (Wikimedia Commons), et une version à palette de ce logo ; une icône 32 x 32 et un GIF de 12 images que nous avons dessinés pour ce test ; enfin une vignette de 320 px de large découpée dans kodim04.

Chaque chiffre correspond à une seule mesure. L'encodeur PNG du navigateur ne produit pas exactement les mêmes octets d'une fois sur l'autre : attendez-vous à de petits écarts si vous refaites l'essai. Nous développons ImgCompress.app, et la page À propos indique qui gère le site. Une IA a aidé à rédiger le texte, et nous avons vérifié chaque chiffre dans les fichiers de sortie bruts.

Pourquoi un JPEG recompressé devient-il plus lourd ?

Parce que « qualité 80 » ne correspond pas à un taux de compression fixe. C'est un réglage propre à un encodeur, et deux encodeurs, ou deux valeurs de qualité, ne gardent pas la même quantité de détails.

Notre JPEG de test de 135 Ko avait été produit par mozjpeg en qualité 70, un réglage pensé pour obtenir de petits fichiers. Réenregistré en qualité 80 par l'encodeur intégré de Chrome, il est passé à 168 Ko, soit 24 % de plus. Le navigateur a décodé le JPEG en pixels bruts, y compris les blocs et le bruit de compression laissés par mozjpeg, puis a encodé ces pixels avec une quantification plus fine que l'original. Rien de ce qui avait été perdu ne revient : le nouveau fichier consacre simplement plus d'octets à la même image, défauts compris.

La version moins compressée de la même photo, à 250 382 octets, s'est comportée autrement. Chrome en qualité 80 a donné 250 670 octets, seulement 288 octets de plus. Réenregistrer avec l'encodeur et le réglage qui avaient produit le fichier retombe presque exactement sur la taille d'origine.

Ce que fait notre compresseur dans ce cas

Notre compresseur vérifie le premier résultat. Dans browser-image-compression, si la sortie est plus lourde que la source (ou dépasse la taille cible), il réencode à 0,95 fois la qualité précédente (0,85 pour le PNG) et recommence jusqu'à passer sous les deux limites ou jusqu'à épuisement des passes. Dans cette boucle, les dimensions ne diminuent que si le fichier dépasse la taille cible : une petite photo garde donc sa définition.

Pour le fichier de 250 Ko, une passe supplémentaire en qualité 0,76 l'a ramené à 240 546 octets, soit 3,9 % de moins. Pour le fichier mozjpeg de 135 Ko, il a fallu sept passes, jusqu'à la qualité 0,56, pour arriver à 134 643 octets. Soit 508 octets gagnés au prix d'une qualité nettement plus basse, sur un fichier déjà compressé. Quand la carte de résultat annonce un gain de quelques pour cent ou moins, gardez l'original.

Si le résultat n'est toujours pas plus léger et que le format n'a pas changé, le compresseur vous rend le fichier d'origine : il ne vous donne jamais un fichier plus lourd dans le même format.

Le fonctionnement des valeurs de qualité est détaillé dans notre guide de la compression JPEG.

Pourquoi mon PNG est-il bien plus lourd après conversion depuis un JPG ?

Le PNG est sans perte. Il stocke chaque pixel exactement, et une photo JPEG décodée contient énormément de pixels légèrement différents de leurs voisins : grain, bruit du capteur et le léger motif de blocs de 8 x 8 que laisse la compression JPEG. Un format sans perte doit conserver tout cela.

Plus le JPEG était compressé, plus le saut a été important dans notre test : le fichier de départ était plus petit, alors que le PNG devait stocker le même nombre de pixels. Convertir en PNG ne répare pas non plus les dégâts du JPEG. Vous gardez le même flou et les mêmes blocs, désormais stockés sans perte.

Passez de JPG à PNG quand c'est bien le PNG qu'il vous faut : un logiciel qui n'accepte que le PNG, une copie maîtresse que vous retoucherez souvent, un formulaire qui refuse le JPG. Si le but est d'alléger le fichier, restez en JPG ou passez plutôt au WebP ou à l'AVIF.

Pourquoi mon PNG a-t-il grossi après un nouvel enregistrement ?

Deux mécanismes du navigateur jouent contre vous.

D'abord, l'encodeur PNG du canvas de Chrome a compacté les données bien moins efficacement que le fichier qu'il avait reçu. Réenregistrée via canvas.toBlob, la photo kodim04 est passée de 637 432 à 846 413 octets, 33 % de plus, avec exactement les mêmes pixels. Même un réenregistrement sans perte soigné ne gagne pas à coup sûr : sharp avec libpng au niveau de compression 9 a produit 638 304 octets, 872 octets de plus que le fichier de départ.

Ensuite, un canvas garde toute image en RGBA 32 bits, et c'est ce que Chrome a écrit. Un PNG à palette stocke chaque pixel comme un index dans une petite table de couleurs ; c'est ainsi que des outils comme TinyPNG ou pngquant obtiennent des fichiers légers. Notre version à palette du logo pesait 45 525 octets. Dessinée sur un canvas puis réenregistrée, elle est montée à 170 429 octets, 3,7 fois plus, parce que la table de couleurs avait disparu et que chaque pixel était stocké en entier.

Notre compresseur n'utilise pas un simple canvas.toBlob pour le PNG. browser-image-compression transmet les pixels à UPNG avec une limite de couleurs égale à 4096 fois la qualité, soit 3 276 couleurs avec la valeur par défaut de 0,8. Résultats de la même série :

Cette étape réduit le nombre de couleurs, elle n'est donc pas sans perte : la photo est passée de 31 716 couleurs distinctes à 3 277, et la capture d'écran de 2 002 à 1 314. Sur un PNG à palette déjà optimisé, il ne reste presque rien à gagner : le recompresser, avec notre outil comme avec un autre, ne sert pas à grand-chose.

Faut-il enregistrer une capture d'écran en JPG ?

En général, non. Le JPEG est conçu pour les détails progressifs d'une photo, alors qu'une capture d'écran se compose d'aplats et de contours nets autour du texte. Chrome a enregistré notre JPG avec un sous-échantillonnage de la chrominance en 4:2:0, qui stocke la couleur à la moitié de la résolution de la luminosité, horizontalement comme verticalement ; c'est sur le texte en couleur et les fines lignes colorées que cela se voit en premier. Sur notre recadrage agrandi 2x en qualité 90, la différence avec le PNG était difficile à repérer, mais le fichier était quand même plus lourd.

Si un site exige du JPG, la conversion PNG vers JPG à 80 % est passée sous la taille du PNG dans notre test, ce que 90 % n'a pas fait. Là où le WebP est accepté, PNG vers WebP convient mieux aux captures d'écran. Le PNG à palette a donné le plus petit fichier de tous ; comme nous ne proposons pas de mode palette à 256 couleurs, passez par un outil comme pngquant ou Squoosh si vous tenez à gagner les 50 derniers Ko. Pour comparer ces deux formats en détail, voir WebP ou PNG.

Pourquoi un WebP ou un AVIF sort-il plus lourd que l'original ?

Il y a deux raisons distinctes, apparues dans deux tests différents.

Convertir un JPEG déjà compressé à une qualité élevée

À qualité visuelle égale, WebP et AVIF sont souvent plus légers que le JPEG. Mais cette comparaison suppose une source propre. En partant d'un JPEG, le nouvel encodeur doit reproduire les défauts du JPEG comme s'il s'agissait de détails.

Le JPEG de 250 Ko est passé de 250 382 à 269 556 octets en WebP qualité 90, soit 7,7 % de plus. La valeur de qualité compte davantage que le format. Avec JPG vers WebP, baissez le curseur sous les 90 % par défaut et comparez les tailles, ou essayez JPG vers AVIF. Notre dossier sur l'AVIF explique ce que l'AVIF fait subir aux textures fines.

Les très petites images et le coût fixe du format

Chaque format a des coûts fixes, comme les en-têtes et, pour le WebP avec perte et transparence, un canal alpha stocké à part. Ils pèsent lourd quand l'image entière fait 504 octets.

Le WebP sans perte a bien battu le PNG de 140 octets, mais la plupart des options ont alourdi l'icône, y compris les deux réglages AVIF. Pour les icônes et les petits éléments d'interface, gardez le PNG, ou passez au SVG si vous avez la source vectorielle. Dans nos tests, WebP et AVIF ont fait gagner des octets sur les photos, pas sur l'icône.

Agrandir l'image ou garder les métadonnées ajoute-t-il des octets ?

Agrandir ajoute des octets sans ajouter de détails. Notre vignette de 320 x 480 pesait 28 034 octets. Réenregistrée à sa taille en qualité 80, elle faisait 28 513 octets ; agrandie d'abord en 640 x 960, elle montait à 62 114 octets, 2,2 fois plus, pour une image plus floue. Notre compresseur n'agrandit jamais, car ses 1920 px sont un plafond. Un outil de redimensionnement, lui, agrandit si vous saisissez des valeurs plus grandes : vérifiez les dimensions cibles dans le redimensionneur d'images avant d'exporter. L'article Redimensionner sans perdre en qualité explique pourquoi un agrandissement ne récupère aucun détail.

Les métadonnées ont peu pesé dans notre test. La vignette contenait un profil colorimétrique Display P3 de 480 octets et des balises EXIF de 258 octets, environ 2,6 % de ses 28 290 octets. Notre compresseur supprime les EXIF par défaut et ne les garde que si vous activez « Conserver les EXIF ». Les fichiers d'appareil photo peuvent contenir des blocs plus gros, comme des aperçus intégrés : sur de petits exports issus d'un appareil ou d'un téléphone, supprimer les EXIF peut donc compter davantage. Cela retire aussi la position GPS.

Que se passe-t-il quand on convertit un GIF ?

Le GIF est ancien, mais pour une courte animation à quelques couleurs en aplat, il reste compact : il stocke des index de palette et peut n'enregistrer que la partie de chaque image qui a changé. Nous avons dessiné une animation de 12 images en 240 x 240, un point qui traverse un fond uni :

Aucune de ces sorties n'a beaucoup changé la taille. Ce résultat ne vaut que pour une petite animation en aplats : nous n'avons pas testé de longs GIF aux images photographiques, où la limite de 256 couleurs et le tramage coûtent plus cher au GIF. Pour une courte animation en aplats, garder le GIF est un choix raisonnable ; s'il doit être plus léger, commencez par le compresseur de GIF.

Ce que font nos outils quand le résultat est plus lourd

Tous les traitements décrits ici se font dans votre navigateur : sur notre site, l'image n'est pas envoyée sur un serveur. Voici le comportement de chaque outil quand la sortie grossit :

• Compresseur, format d'origine conservé : il recommence à une qualité plus basse tant que le fichier dépasse la source, puis vous rend l'original s'il n'est toujours pas plus léger.
• Compresseur, format modifié : vous recevez le fichier converti même s'il est plus lourd. La carte de résultat affiche les deux tailles, et le pourcentage n'apparaît que si le fichier a diminué : comparez donc les deux valeurs.
• Convertisseurs : ils encodent une seule fois à la valeur du curseur (90 % par défaut pour les sorties avec perte), sans vérifier la taille. Une conversion vise le format, la taille peut donc monter comme descendre.
• Taille cible : tant que le fichier dépasse votre cible, chaque passe baisse la qualité et, sauf si « Forcer la résolution d'origine » est activé, réduit largeur et hauteur de 5 %. L'outil s'arrête après 30 passes ; une cible non atteinte est signalée sur la carte.

Avant de recompresser ou de convertir : la liste de contrôle

1. Le fichier est-il déjà optimisé ? S'il sort d'un CDN, d'un CMS ou d'un outil comme TinyPNG, une seconde passe rapporte en général peu ; la nôtre a gagné 3,9 % et 0,4 %. Gardez l'original quand le gain est aussi faible.
2. Faites-vous passer une photo en PNG ? Seulement si le PNG est imposé. Nos deux JPEG ont été multipliés par 10,7 et 16,4.
3. S'agit-il d'une capture d'écran ou d'un visuel en aplats ? Gardez le PNG ou passez au WebP. Dans notre test, le JPG à 90 % pesait plus que le PNG.
4. Pèse-t-il moins de quelques Ko ? Laissez les icônes en PNG ou en SVG. Les en-têtes WebP et AVIF peuvent peser plus que les pixels.
5. Les dimensions en pixels ont-elles augmenté ? Vérifiez la taille de sortie avant d'enregistrer. L'agrandissement a doublé le poids de notre vignette.
6. Le convertisseur est-il réglé sur 90 % ? Pour JPG vers WebP, essayez entre 75 et 80 % et comparez.
7. Avez-vous besoin des métadonnées ? Supprimez les EXIF des petites images publiées ; gardez-les sur les photos que vous archivez.

Si vous voulez seulement un fichier plus léger dans le même format, commencez par le compresseur et comparez les tailles avant et après sur la carte de résultat avant de télécharger.