La naissance du PNG : comment une guerre des brevets a créé le format sans perte préféré du Web

Ouvrez un fichier PNG dans un éditeur hexadécimal. Les huit premiers octets :

89 50 4E 47 0D 0A 1A 0A

C'est la signature PNG. Chaque décodeur PNG la vérifie. Le premier octet 0x89 est délibérément élevé — il empêche les éditeurs de texte naïfs de traiter le fichier comme de l'ASCII. 50 4E 47 épelle « PNG » en ASCII. 0D 0A est une fin de ligne DOS, 1A est le marqueur de fin de fichier DOS, et 0A est un saut de ligne Unix. Les concepteurs ont intégré ces caractères de fin de ligne pour que les transferts FTP en mode texte corrompent immédiatement le fichier, forçant les utilisateurs à transférer en mode binaire. C'était un petit acte de paranoïa de la part de développeurs qui venaient de voir un format breveté se transformer en arme juridique.

Le PNG est partout aujourd'hui. Il est au cœur des captures d'écran, des ressources d'interface, des diagrammes, des logos et de toute image où les pixels doivent rester identiques après de multiples sauvegardes. Il est plus vieux que Google, plus vieux que l'iPod, et reste le choix par défaut lorsqu'il s'agit de compression sans perte. Mais il n'a jamais été conçu comme un standard. Il a commencé comme une solution temporaire, pas comme un standard.

Le procès qui a forcé la création d'un nouveau format

En janvier 1995, Unisys a annoncé qu'elle ferait respecter son brevet de compression LZW — le brevet américain 4.558.302 — contre les développeurs utilisant le format GIF. Le brevet couvrait l'algorithme de Lempel-Ziv-Welch, la méthode de compression au cœur de chaque encodeur et décodeur GIF.

Le Web reposait sur le GIF en 1995. Bannières animées, logos transparents, arrière-plans en mosaïque — le GIF faisait tout. Puis Unisys a exigé des redevances. Les éditeurs de logiciels commerciaux ont fait face à des frais de licence. Les projets open source étaient confrontés à des menaces existentielles. Le GNU Image Manipulation Program (GIMP) était directement touché. La communauté des développeurs Web était furieuse.

Quelque chose devait remplacer le GIF pour les images statiques. Les exigences étaient claires : aucun brevet, une meilleure compression que le GIF, la prise en charge des vraies couleurs, et un canal alpha correct au lieu de la transparence grossière monochrome du GIF. Il devait aussi être assez simple pour qu'un développeur seul puisse implémenter un décodeur en un week-end.

Le 4 avril 1995, Thomas Boutell a publié une proposition sur le forum Usenet comp.graphics. Il l'a appelée PBF — Portable Bitmap Format. Le nom n'a pas perduré. Au cours des mois suivants, une liste de diffusion s'est formée. Les contributeurs incluaient Tom Lane (chef de l'Independent JPEG Group), Lee Daniel Crocker, Alexander Lehmann, et des dizaines d'autres. D'ici le 1er octobre 1996, la spécification PNG était figée sous le nom de RFC 2083. L'ensemble du processus a pris environ dix-huit mois, de l'idée à la norme. Pour comparaison, le JPEG a pris six ans.

Ce qui existait avant le PNG

En 1995, les options de formats d'image étaient limitées et chacune avait son lot de contraintes :

Le GIF dominait le Web mais était juridiquement toxique. Sa palette de 256 couleurs suffisait pour les icônes et les dessins animés, mais était inutile pour les photographies. Sa transparence était binaire : un pixel était soit totalement opaque, soit totalement transparent. Pas de contours adoucis, pas d'ombres portées.

Le JPEG traitait les photographies de manière brillante mais détruisait les données de façon irréversible. Ouvrir un JPEG, l'éditer, le réenregistrer, et l'image se dégradait. Le JPEG n'avait aussi aucune transparence. Pour les créateurs de sites Web qui avaient besoin d'un logo flottant sur un arrière-plan texturé, le JPEG était inutile.

Le BMP et le PCX étaient non compressés ou à peine compressés. Un BMP de 640 × 480 en 1995 pesait 900 Ko. Sur un modem 28,8 kbps, cela prenait plus de quatre minutes à télécharger.

Le TIFF était puissant et flexible, mais cette flexibilité était sa malédiction. Les fichiers TIFF pouvaient utiliser une douzaine de schémas de compression, d'espaces colorimétriques et de profondeurs de bits différents. Écrire un décodeur TIFF universel était un projet de niveau doctorat, pas une bidouille de week-end.

Le PNG était conçu pour atteindre une cible précise : remplacer le GIF pour les images statiques, surpasser sa compression, ajouter les vraies couleurs et une vraie transparence, et rester libre pour toujours.

Comment le PNG compresse réellement

La compression PNG est un pipeline en deux étapes. Aucune des deux étapes n'est brillante en soi. Ensemble, elles sont étonnamment efficaces.

Étape 1 : le filtrage

Avant toute compression, le PNG fait passer les données brutes de pixels à travers un filtre. Le filtre ne compresse rien. Il réorganise les données pour que l'étape suivante puisse mieux les compresser.

Une image est une grille d'octets. Sur une photographie d'un ciel clair, les pixels adjacents sont presque identiques. Mais le flux d'octets brut stocke quand même 120, 121, 120, 122, 119 pour chaque canal. Les différences sont minuscules : +1, -1, +2, -3. Si l'on stocke les différences au lieu des valeurs absolues, les nombres résultants se regroupent autour de zéro. Ce regroupement est idéal pour les algorithmes de compression.

Le PNG définit cinq types de filtres par ligne de balayage :

L'encodeur essaie les cinq filtres par ligne de balayage et choisit celui qui produit la plus petite sortie après l'étape 2. C'est pourquoi un encodeur PNG peut être lent : il effectue une recherche par force brute sur les combinaisons de filtres. Mais le décodage est rapide — le type de filtre est stocké dans le fichier, donc le décodeur applique simplement l'opération inverse.

Étape 2 : DEFLATE

Après le filtrage, les données sont compressées avec DEFLATE, le même algorithme utilisé par gzip et les fichiers ZIP. DEFLATE est une combinaison de LZ77 (élimination des chaînes dupliquées par fenêtre glissante) et de codage de Huffman (codes préfixés de longueur variable pour les symboles fréquents).

Le résultat : une capture d'écran ou un graphique d'interface typique occupe 3 à 5 fois moins d'espace qu'un BMP non compressé. Une photographie compressée en PNG est généralement 5 à 10 fois plus grande qu'en JPEG, mais chaque pixel est récupérable. La compression est sans perte par construction : aucune donnée n'est rejetée, seules les redondances sont supprimées.

Pour mettre en contexte, une capture d'écran de 1920 × 1080 en RGB brut pèse 6,2 Mo. La même capture d'écran en PNG descend généralement à 800 Ko – 1,5 Mo. La même image en JPEG qualité 90 fait 300–500 Ko, mais la réenregistrer dix fois introduirait des artefacts visibles.

Les fonctionnalités qui comptaient

Le PNG n'était pas qu'un clone du GIF exempt de brevets. Il ajoutait des capacités pour lesquelles les créateurs de sites Web réclamaient depuis 1993.

Vraies couleurs : le PNG prend en charge le RVB 24 bits (16,7 millions de couleurs) et la couleur profonde 48 bits. Aucune limite de palette. Une photographie PNG peut afficher chaque couleur que l'œil humain peut distinguer.

Canal alpha : le PNG prend en charge l'alpha 8 bits — 256 niveaux de transparence par pixel. Une ombre peut s'estomper doucement d'opaque à transparent. Un bouton arrondi peut être anticrénelé sur n'importe quel arrière-plan. Le GIF offrait une transparence 1 bit : une couleur était soit totalement active, soit totalement inactive. La différence visuelle est flagrante.

Entrelacement Adam7 : le PNG peut stocker les pixels dans un ordre entrelacé en 7 passes. Un navigateur rend un aperçu grossier après avoir reçu 1/64 du fichier, puis l'affine progressivement. Contrairement à l'entrelacement ligne par ligne du GIF, Adam7 répartit les détails sur toute l'image dès la première passe. À la troisième passe, l'image est reconnaissable. À la septième, elle est parfaite.

Correction gamma : le PNG stocke une valeur gamma dans ses métadonnées. Une image créée sur un Mac (gamma 1,8) s'affiche correctement sur un PC Windows (gamma 2,2) sans correction colorimétrique manuelle. C'était un problème réel dans les années 1990, lorsque la cohérence entre plateformes était rare.

Sommes de contrôle CRC : chaque chunk PNG porte une somme de contrôle CRC-32. Les téléchargements corrompus sont détectés immédiatement au lieu de produire une image semi-rendue.

Détecter le PNG en lisant la signature du fichier

Ne faites pas confiance à l'extension .png. Lisez les huit premiers octets et vérifiez la signature.

Disposition exacte des octets :

Bytes 0–7:  Signature 89 50 4E 47 0D 0A 1A 0A
Bytes 8–11: Chunk length (big-endian uint32)
Bytes 12–15: Chunk type: "IHDR" (image header)
Bytes 16–19: Image width (big-endian uint32)
Bytes 20–23: Image height (big-endian uint32)
Byte 24:    Bit depth
Byte 25:    Color type
Byte 26:    Compression method (always 0)
Byte 27:    Filter method (always 0)
Byte 28:    Interlace method (0 or 1)

TypeScript dans le navigateur :

async function isPng(file: File): Promise<boolean> {
  const buffer = await file.slice(0, 8).arrayBuffer()
  const bytes = new Uint8Array(buffer)

  const signature = [0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a]
  return bytes.length === 8 && bytes.every((b, i) => b === signature[i])
}

Python

def is_png(path: str) -> bool:
    with open(path, "rb") as f:
        header = f.read(8)

    return header == b"\x89PNG\r\n\x1a\n"

Option de plus haut niveau avec la bibliothèque standard :

import imghdr

if imghdr.what("image.png") == "png":
    pass

Ou avec Pillow :

from PIL import Image

try:
    with Image.open("image.png") as img:
        is_png = img.format == "PNG"
except Exception:
    is_png = False

Go

func isPng(path string) bool {
	f, err := os.Open(path)
	if err != nil {
		return false
	}
	defer f.Close()

	buf := make([]byte, 8)
	if _, err := f.Read(buf); err != nil {
		return false
	}

	return bytes.Equal(buf, []byte{0x89, 0x50, 0x4e, 0x47, 0x0d, 0x0a, 0x1a, 0x0a})
}

PHP

function isPng(string $path): bool {
    $header = file_get_contents($path, false, null, 0, 8);
    return $header === "\x89PNG\r\n\x1a\n";
}

Avec fileinfo :

$finfo = new finfo(FILEINFO_MIME_TYPE);
$mime = $finfo->file('image.png');
// image/png

ImageMagick CLI

magick identify -verbose image.png | grep "Format:"
# Format: PNG (Portable Network Graphics)

Ou simplement :

file image.png
# image.png: PNG image data, 1200 x 675, 8-bit/color RGBA, non-interlaced

Les limites du PNG

Le PNG n'est pas parfait. Ses choix de conception étaient des compromis, et certains de ces compromis nous coûtent encore aujourd'hui.

Pas d'animation intégrée : le PNG Working Group a explicitement rejeté l'animation. Ils voulaient résoudre complètement le problème des images statiques avant d'ajouter de la complexité. Le résultat : le GIF animé a survécu deux décennies de plus. L'APNG (Animated PNG) a finalement été normalisé en 2004, mais la prise en charge par les navigateurs est restée incomplète jusqu'à la fin des années 2010. Même aujourd'hui, les GIFs animés dominent largement les APNG.

Tailles de fichiers importantes pour les photographies : une photo de 12 MP en PNG fait généralement 15–25 Mo. En JPEG qualité 90, cela fait 3–5 Mo. La compression sans perte du PNG ne peut pas rivaliser avec la réduction psycho-visuelle basée sur la DCT du JPEG. Pour les photographies, le PNG est le mauvais outil.

Pas de prise en charge CMJN : le PNG est limité au RVB. Les flux de travail d'impression qui nécessitent une séparation CMJN doivent convertir le PNG en TIFF ou JPEG. C'était un choix délibéré — les concepteurs se sont concentrés sur l'affichage écran, pas l'impression — mais cela limite l'utilité du PNG dans l'édition professionnelle.

Décodage plus lent que le JPEG : le décodage PNG nécessite un filtrage inverse par ligne de balayage et une décompression DEFLATE. Le décodage JPEG est hautement parallélisable et fortement optimisé dans le matériel. Sur les appareils mobiles, un PNG volumineux peut prendre 2 à 3 fois plus de temps à s'afficher qu'un JPEG de résolution équivalente, retardant le Largest Contentful Paint.

Pas de qualité progressive : contrairement au JPEG 2000 ou au JPEG XL, le PNG ne peut pas produire un aperçu de qualité inférieure à partir d'un fichier tronqué. Soit vous avez le fichier entier, soit vous n'avez rien. L'entrelacement Adam7 aide pour les aperçus grossiers, mais il ne réduit pas la taille totale du fichier.

Pourquoi le PNG n'a jamais remplacé le JPEG

C'est le malentendu le plus courant à propos des formats d'image. Le PNG et le JPEG n'ont jamais été en compétition pour le même emploi.

Le JPEG est un compresseur psycho-visuel avec perte. Il jette des données que vos yeux n'auraient probablement pas remarquées. Il a été conçu pour les photographies en tons continus — des images avec des dégradés doux, une texture fine et un éclairage naturel. Pour ce travail, le JPEG reste imbattable sur le rapport taille-qualité après trente-trois ans.

Le PNG est un compresseur de données sans perte. Il préserve chaque bit. Il a été conçu pour les images en tons discrets — captures d'écran, éléments d'interface, diagrammes, logos, superpositions de texte — où les contours nets et les couleurs exactes comptent. Pour ce travail, le PNG est la norme.

Les deux formats se sont partagé le Web en territoires bien distincts :

Le PNG n'a jamais cherché à remplacer le JPEG. Il a simplement trouvé un autre rôle.

Où en est le PNG aujourd'hui

Le Web Almanac 2025 estime la part du PNG à environ 22 % de toutes les images servies sur le Web. C'est en baisse par rapport à son pic — le WebP et l'AVIF grignotent des parts de marché — mais le PNG reste le format de secours que chaque navigateur, chaque éditeur d'images et chaque système d'exploitation peut ouvrir sans hésitation.

WebP (Google, 2010) prend en charge les modes avec perte et sans perte, plus l'animation et la transparence. Un WebP sans perte est généralement 20 à 30 % plus petit qu'un PNG équivalent. La prise en charge par les navigateurs est universelle depuis 2020. Pour les nouveaux projets, le WebP sans perte est le remplacement pragmatique du PNG dans la plupart des cas.

AVIF (AOM, 2019) atteint une compression encore meilleure, mais son mode sans perte est plus lent à encoder et décoder que le PNG. L'AVIF manque aussi de la prise en charge complète par les navigateurs pour certaines fonctionnalités PNG avancées comme les canaux 16 bits et la correction gamma intégrée.

SVG domine l'espace des icônes et logos pour les graphiques vectoriels simples, mais les graphiques complexes rasterisés ont encore besoin du PNG.

La réalité pratique : le PNG ne disparaît pas. C'est le choix sûr par défaut, le format vers lequel on exporte lorsqu'on doit garantir que le destinataire peut ouvrir le fichier. C'est le QWERTY des formats d'image — pas optimal, mais universellement compris.

L'avenir du PNG

Le PNG est une norme terminée. La spécification n'a pas changé de manière significative depuis 2003. Cette stabilité est un atout, pas un défaut. Vous pouvez ouvrir un PNG créé en 1997 dans n'importe quel navigateur moderne et il s'affichera de manière identique.

Mais l'écosystème autour du PNG continue d'évoluer :

L'APNG gagne du terrain. Safari le prend en charge depuis 2014. Chrome et Firefox ont suivi. Discord, Slack et Twitter affichent tous les APNG nativement. Pour les courtes animations d'interface — indicateurs de chargement, émojis de réaction, indicateurs d'état — l'APNG remplace le GIF animé par des fichiers plus petits et une meilleure fidélité colorimétrique.

Les outils d'optimisation PNG continuent de s'améliorer. oxipng, pngcrush et zopfli peuvent économiser encore 10 à 30 % sur les tailles de fichiers PNG en forçant brutalement de meilleures combinaisons de filtres et paramètres DEFLATE. Pour les sites à fort trafic, faire passer chaque PNG par oxipng est une pratique standard.

Le PNG comme conteneur : certains flux de travail modernes intègrent des profils de couleur ICC, des métadonnées EXIF, et même des données XMP dans les chunks PNG. Le PNG est devenu un format d'archivage léger — pas aussi riche que le TIFF, mais bien plus portable.

La perspective à long terme : le PNG coexistera avec le WebP, l'AVIF et le JPEG XL pendant des années. Il occupe une niche qu'aucun autre format ne possède complètement : sans perte, exempt de brevets, universellement pris en charge, et assez simple pour qu'un développeur seul puisse écrire un décodeur à partir de la spécification en une semaine. Cette combinaison est difficile à détrôner.

Le bilan

Le PNG est né parce que les développeurs en avaient assez. Un procès en contrefaçon de brevet menaçait le Web ouvert, et un groupe de développeurs a construit une alternative sur leur temps libre. Ils ne cherchaient pas à créer une norme qui dure trente ans. Ils cherchaient à résoudre un problème : comment placer un logo transparent sur une page Web sans payer de frais de licence.

Le résultat était bien meilleur que ce que quiconque aurait pu espérer. Le PNG a offert au Web des graphismes en vraies couleurs, une transparence douce et une intégrité de fichier robuste. Il a prouvé que les normes ouvertes, construites par des bénévoles, pouvaient surpasser les formats propriétaires soutenus par de grandes entreprises.

Ce n'est pas le format le plus compact. Ce n'est pas le plus rapide à décoder. Il ne gère pas bien l'animation, et il est inadapté aux photographies. Mais lorsque vous devez être sûr que chaque pixel enregistré est celui que vous récupérerez — le PNG reste l'outil auquel vous faites appel.

Toutes les images ne commencent pas en PNG. Si vous avez des JPG qui ont besoin de transparence ou d'un traitement sans perte, vous pouvez les convertir directement dans votre navigateur — aucun logiciel à installer, aucune donnée ne quitte votre appareil. JPG vers PNG s'en charge en local. Pour les projets web où le poids du fichier compte, JPG vers WebP allège les fichiers sans toucher à la qualité. Et lorsque vous avez besoin d'icônes favicon, JPG vers ICO transforme vos photos en fichiers ICO à plusieurs tailles.