WebP, PNG ou JPG : quel format pour vos images ?

Compression de chaque format

JPG : avec perte, optimisé pour photos

Le JPG divise l’image en blocs de 8×8, convertit chacun en composantes de fréquence et élimine les détails à haute fréquence que l’œil remarque le moins. Le curseur de qualité règle l’intensité de cette élimination. Cela fonctionne remarquablement bien sur les photographies, dont les détails sont fins et irréguliers et où de petites erreurs se cachent dans le bruit.

Il fonctionne mal sur les contours nets. Une ligne noire sur blanc est une information pure à haute fréquence, précisément ce que le format élimine : le halo caractéristique apparaît donc autour du texte et des contours. Le JPG n’a par ailleurs aucun canal alpha, même limité. Enregistrer une image transparente en JPG remplace définitivement sa transparence par une couleur unie, généralement noire ou blanche.

PNG : sans perte, adapté aux graphismes uniformes

PNG ne supprime jamais les données des pixels. Il prédit chaque pixel à partir de ses voisins, stocke les petites différences et soumet le résultat à DEFLATE. Les longues séries de pixels identiques ou presque identiques se compressent jusqu’à presque rien ; c’est pourquoi les graphismes à couleurs uniformes, les captures d’interface, les dessins au trait et le pixel art se réduisent si bien.

Le format a deux modes qu’il faut distinguer. PNG truecolor stocke une couleur complète sur 24 bits et un alpha facultatif. PNG indexé (PNG-8) stocke un indice dans une table de 256 couleurs maximum : un octet par pixel au lieu de quatre. Pour des graphiques réellement peu colorés, la palette réduit énormément le fichier sans perte. Souvent négligée, elle explique pourquoi PNG bat parfois WebP.

WebP : les deux, dans un même conteneur

WebP possède deux modes distincts qui partagent la même extension de fichier. WebP avec perte utilise une prédiction par blocs issue du codage vidéo : les fichiers sont généralement 20–30% plus petits que JPG à qualité perçue comparable. WebP sans perte utilise un autre schéma avec une prédiction plus sophistiquée que PNG et donne généralement une taille de 20–30% inférieure à celle d’un PNG en couleurs vraies.

Point essentiel : les deux modes prennent en charge l’alpha. C’est le véritable avantage du WebP : auparavant, une image transparente devait être un PNG, donc sans perte, donc volumineux. Le WebP avec perte et alpha permet de compresser une photo détourée comme une photo ordinaire.

La comparaison en un coup d’œil

Choisir selon le contenu de l'image

Photographies, sans transparence

Le WebP avec perte à une qualité de 80 est la solution raisonnable la plus légère, avec le JPG à 80 comme repli compatible. Les deux conviennent ; le WebP est généralement un quart plus petit. Une diffusion négociée selon le contenu <picture> un élément servant WebP avec un JPG de secours vous offre les deux, même si en 2026 cette solution de secours est surtout une précaution supplémentaire.

Graphiques plats, logos, pixel art et captures d'interface

PNG, en essayant le mode indexé. C’est ici que la règle « WebP pour tout » échoue le plus nettement. Un logo de douze couleurs stocké en PNG indexé peut peser quelques kilooctets ; le même logo en WebP avec perte à qualité 80 est souvent plus volumineux, car cet encodage utilise des bits pour décrire des détails par blocs qu’une palette encode gratuitement, tout en ajoutant des artefacts aux zones parfaitement uniformes. WebP sans perte est compétitif et gagne parfois, mais la différence est assez faible pour justifier d’exporter les deux et de les comparer.

Sprites et tout contenu nécessitant de l’alpha

PNG. C’est le format que tous les moteurs de jeu, éditeurs et chaînes de traitement d’assets lisent sans difficulté. Il est sans perte, donc les modifications répétées ne cumulent pas de dégradation, et les sprites sont assez petits pour que la taille du fichier soit rarement une contrainte. WebP sans perte est un format de distribution raisonnable si votre moteur le prend en charge ; conservez dans tous les cas le PNG comme copie de travail. Jamais JPG : sans alpha, votre sprite soigneusement détouré arrive entouré d’un rectangle blanc.

Photographies avec transparence

C’est le domaine privilégié du WebP avec perte, qui comble une vraie lacune. Une photo de produit détourée sur fond transparent peut peser 800KB en PNG ; en WebP avec alpha à qualité 80, elle peut descendre sous 100KB sans différence visible. PNG est le seul secours si nécessaire, plusieurs fois plus gros.

Deux exemples à connaître

Des nombres concrets éclairent les compromis. Deux optimisations réelles :

• Carte sociale PNG de 606KB recodée en JPG de 81KB. La carte avait un fond photographique avec texte superposé, exporté en PNG parce que c’est le défaut de la plupart des outils de conception. PNG convient mal aux photos, donc le fichier était énorme ; en JPG qualité 82, la différence visible est nulle à la taille d’affichage réelle. Un changement de menu a réduit la taille de 87%.
• La taille des images d’arrière-plan des pages a baissé d’environ 57% après conversion de PNG en WebP. Ces images étaient grandes, douces et riches en dégradés, sans bord net ni transparence : exactement le contenu que la compression avec perte traite le mieux. Même résultat visuel, moins de la moitié des octets.

Les deux gains viennent du choix d’un format adapté au contenu plutôt que d’une règle générale. Faites le même test sur un ensemble d’icônes en aplats et le PNG gagnerait dans les deux cas.

L’exception des images sociales

Un endroit où il faut volontairement éviter le WebP : les images Open Graph et les cartes Twitter. Ces URL sont récupérées par des robots d’exploration et d’aperçu de liens — Slack, Discord, iMessage, WhatsApp, LinkedIn, lecteurs RSS, navigateurs intégrés et de nombreux outils internes — pas par les navigateurs modernes décrits dans les statistiques de compatibilité WebP.

La prise en charge dans ce groupe est nettement moins bonne, avec un échec particulièrement gênant : au lieu d’une erreur visible, le lien s’affiche sans aucune image et vous ne le découvrez que des semaines plus tard quand quelqu’un le signale. Utiliser JPG coûte peut-être 30% d’octets en plus sur un fichier chargé par l’infrastructure, pas par des utilisateurs aux connexions facturées.

La même prudence vaut pour l’e-mail. Les clients de messagerie ont leurs propres contraintes de compatibilité et plusieurs ne prennent toujours pas en charge WebP. Les pièces jointes et images destinées aux e-mails doivent être en JPG ou PNG.

Une procédure de décision

1. La transparence est-elle nécessaire ? Sinon, passez à l'étape 3. Si oui, excluez JPG.
2. L'image transparente est-elle photographique ? Contenu photographique avec alpha → WebP avec perte. Graphismes uniformes ou sprites avec alpha → PNG.
3. Est-ce une photographie ? Oui → WebP avec perte, ou JPG si la compatibilité compte. Non → continuez.
4. Couleurs plates et bords nets ? Exportez PNG de palette et WebP sans perte, comparez et livrez le plus petit.
5. Carte sociale, e-mail ou flux inconnu ? Ignorez toutes les recommandations ci-dessus et utilisez JPG ou PNG.

L’étape 4 est celle que l’on saute. Exporter deux fichiers et comparer leur nombre d’octets prend quinze secondes et est plus fiable que n’importe quelle règle générale, car la réponse dépend vraiment de l’image.

Notre Découpeur de planches de sprites exporte en PNG, JPG ou WebP avec un réglage de qualité pour les formats avec perte : vous pouvez donc découper une planche une fois et essayer deux formats sans quitter la page. Pour les sprites, PNG reste le choix sûr par défaut : le format d’exportation compte bien davantage pour les ressources web finales que pour les images intermédiaires.

Questions fréquentes