Die Geburt von PNG: Wie ein Patentkrieg das bevorzugte verlustfreie Format des Web schuf

Öffnen Sie eine PNG-Datei in einem Hex-Editor. Die ersten acht Bytes:

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

Das ist die PNG-Signatur. Jeder PNG-Decoder prüft sie. Das erste Byte 0x89 ist bewusst hoch gewählt – es verhindert, dass einfache Texteditoren die Datei als ASCII behandeln. 50 4E 47 ergibt in ASCII "PNG". 0D 0A ist ein DOS-Zeilenumbruch, 1A ist der DOS-Ende-der-Datei-Marker, und 0A ist ein Unix-Zeilenvorschub. Die Entwickler verpackten diese Zeilenumbruchzeichen in die Signatur, damit FTP-Übertragungen im Textmodus die Datei sofort beschädigten und Benutzer gezwungen waren, den Binärmodus zu verwenden. Es war ein kleiner Akt der Paranoia von Entwicklern, die gerade gesehen hatten, wie ein patentiertes Format zur juristischen Waffe wurde.

PNG ist heute überall. Es ist das Format hinter Screenshots, UI-Assets, Diagrammen, Logos und jedem Bild, bei dem die Pixel nach wiederholtem Speichern unverändert bleiben müssen. Es ist älter als Google, älter als der iPod, und immer noch die Standardwahl, wenn es auf verlustfreie Kompression ankommt. Doch es war nie als Standard geplant. Es begann als Behelfslösung, nicht als Standard.

Die Klage, die ein neues Format erzwang

Im Januar 1995 kündigte Unisys an, sein LZW-Kompressionspatent – U.S. Patent 4.558.302 – gegen Entwickler durchzusetzen, die das GIF-Format nutzten. Das Patent deckte den Lempel-Ziv-Welch-Algorithmus ab, die Kompressionsmethode im Kern jedes GIF-Encoders und -Decoders.

1995 lief das Web auf GIF. Animierte Banner, transparente Logos, gekachelte Hintergründe – GIF bewältigte alles. Dann verlangte Unisys Lizenzgebühren. Kommerzielle Softwarehersteller sahen sich mit Lizenzkosten konfrontiert. Open-Source-Projekte waren existenziell bedroht. Das GNU Image Manipulation Program (GIMP) war direkt betroffen. Die Web-Entwickler-Community war wütend.

Etwas musste GIF für statische Bilder ersetzen. Die Anforderungen waren klar: keine Patente, bessere Kompression als GIF, Unterstützung für Echtfarbe, und ein echter Alpha-Kanal statt GIFs grober Einfarben-Transparenz. Es musste außerdem einfach genug sein, dass ein einzelner Entwickler an einem Wochenende einen Decoder implementieren konnte.

Am 4. April 1995 postete Thomas Boutell einen Vorschlag in die Usenet-Newsgroup comp.graphics. Er nannte es PBF – Portable Bitmap Format. Der Name hielt sich nicht. In den folgenden Monaten bildete sich eine Mailingliste. Zu den Mitwirkenden gehörten Tom Lane (Leiter der Independent JPEG Group), Lee Daniel Crocker, Alexander Lehmann und Dutzende andere. Bis zum 1. Oktober 1996 war die PNG-Spezifikation als RFC 2083 eingefroren. Der gesamte Prozess dauerte etwa achtzehn Monate von der Idee bis zum Standard. Zum Vergleich: JPEG brauchte sechs Jahre.

Was vor PNG existierte

1995 waren die Optionen für Bildformate begrenzt, und jede hatte Ballast:

GIF beherrschte das Web, war aber rechtlich toxisch. Seine 256-Farben-Palette reichte für Icons und Cartoons, war aber für Fotografien nutzlos. Die Transparenz war binär: Ein Pixel war entweder vollständig deckend oder vollständig transparent. Keine weichen Kanten, keine Schlagschatten.

JPEG bewältigte Fotografien brillant, vernichtete Daten aber irreversibel. Ein JPEG öffnen, bearbeiten, erneut speichern – und das Bild verlor an Qualität. JPEG hatte außerdem gar keine Transparenz. Für Webdesigner, die ein Logo über einen strukturierten Hintergrund legen wollten, war JPEG nutzlos.

BMP und PCX waren unkomprimiert oder kaum komprimiert. Ein 640 × 480-BMP im Jahr 1995 fraß 900 KB. Über ein 28,8-kbps-Modem dauerte der Download mehr als vier Minuten.

TIFF war leistungsstark und flexibel, doch genau diese Flexibilität war sein Fluch. TIFF-Dateien konnten ein Dutzend verschiedener Kompressionsverfahren, Farbräume und Bittiefen nutzen. Ein universellen TIFF-Decoder zu schreiben war ein Projekt für eine Doktorarbeit, kein Wochenend-Hack.

PNG wurde darauf ausgelegt, ein enges Ziel zu treffen: GIF für statische Bilder ersetzen, seine Kompression übertreffen, Echtfarbe und echte Transparenz hinzufügen, und für immer frei bleiben.

Wie PNG tatsächlich komprimiert

Die PNG-Kompression ist eine zweistufige Pipeline. Keiner der beiden Schritte ist für sich genommen besonders raffiniert. Zusammen sind sie überraschend effektiv.

Stufe 1: Filterung

Bevor überhaupt Kompression stattfindet, lässt PNG die rohen Pixeldaten durch einen Filter laufen. Der Filter komprimiert nichts. Er ordnet die Daten neu an, damit die nächste Stufe sie besser komprimieren kann.

Ein Bild ist ein Gitter aus Bytes. Auf einer Fotografie eines klaren Himmels sind benachbarte Pixel fast identisch. Doch der rohe Bytestream speichert trotzdem 120, 121, 120, 122, 119 für jeden Kanal. Die Unterschiede sind winzig: +1, -1, +2, -3. Speichert man die Differenzen statt der Absolutwerte, gruppieren sich die resultierenden Zahlen um Null. Diese Gruppierung lieben Kompressionsalgorithmen.

PNG definiert fünf Filtertypen pro Scanline:

Der Encoder probiert alle fünf Filter pro Scanline aus und wählt denjenigen, der nach Stufe 2 die kleinste Ausgabe erzeugt. Deshalb kann ein PNG-Encoder langsam sein: Er führt eine Brute-Force-Suche über Filterkombinationen durch. Das Dekodieren ist jedoch schnell – der Filtertyp ist in der Datei gespeichert, also wendet der Decoder nur die inverse Operation an.

Stufe 2: DEFLATE

Nach der Filterung werden die Daten mit DEFLATE komprimiert, dem gleichen Algorithmus, den gzip und ZIP-Dateien verwenden. DEFLATE ist eine Kombination aus LZ77 (Sliding-Window-Duplikat-Eliminierung) und Huffman-Kodierung (variable Längen-Präfixcodes für häufige Symbole).

Das Ergebnis: Ein typischer Screenshot oder eine UI-Grafik wird 3–5× kleiner als ein unkomprimierter BMP. Ein als PNG komprimiertes Foto ist meist 5–10× größer als JPEG, aber jedes Pixel ist wiederherstellbar. Die Kompression ist konstruktiv verlustfrei: Es werden keine Daten verworfen, nur Redundanzen entfernt.

Zum Vergleich: Ein 1920 × 1080-Screenshot im rohen RGB ist 6,2 MB. Derselbe Screenshot als PNG sinkt typischerweise auf 800 KB – 1,5 MB. Dasselbe Bild als JPEG Qualität 90 ist 300–500 KB, doch zehnmaliges erneutes Speichern würde sichtbare Artefakte einführen.

Die Funktionen, die zählten

PNG war nicht nur ein patentfreier GIF-Klon. Es fügte Fähigkeiten hinzu, nach denen Webdesigner seit 1993 verlangt hatten.

Echtfarbe: PNG unterstützt 24-Bit-RGB (16,7 Millionen Farben) und 48-Bit-Deep-Color. Keine Palettenlimits. Ein PNG-Foto kann jede Farbe darstellen, die das menschliche Auge unterscheiden kann.

Alpha-Kanal: PNG unterstützt 8-Bit-Alpha – 256 Transparenzstufen pro Pixel. Ein Schatten kann sanft von deckend zu transparent verblassen. Ein abgerundeter Button kann gegen jeden Hintergrund Anti-Aliasing betreiben. GIF bot 1-Bit-Transparenz: Eine Farbe war entweder voll an oder voll aus. Der Unterschied ist enorm.

Adam7-Interlacing: PNG kann Pixel in einer 7-Pass-Interlace-Reihenfolge speichern. Ein Browser rendert eine grobe Vorschau nach Empfang von 1/64 der Datei, verfeinert sie dann schrittweise. Im Gegensatz zu GIFs zeilenweisem Interlacing verteilt Adam7 Details über das gesamte Bild vom ersten Pass an. Nach dem dritten Pass ist das Bild erkennbar. Nach dem siebten ist es perfekt.

Gammakorrektur: PNG speichert einen Gammawert in seinen Metadaten. Ein auf einem Mac erstelltes Bild (Gamma 1,8) wird korrekt auf einem Windows-PC (Gamma 2,2) angezeigt, ohne manuelle Farbkorrektur. Das war in den 1990ern ein echtes Problem, als plattformübergreifende Konsistenz selten war.

CRC-Prüfsummen: Jeder PNG-Chunk trägt eine CRC-32-Prüfsumme. Beschädigte Downloads werden sofort erkannt, statt ein halb gerendertes Bild zu produzieren.

PNG durch Lesen der Dateisignatur erkennen

Vertrauen Sie nicht der .png-Erweiterung. Lesen Sie die ersten acht Bytes und prüfen Sie die Signatur.

Exaktes Byte-Layout:

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 im Browser:

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"

Einfachere Variante mit der Standardbibliothek:

import imghdr

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

Oder mit 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";
}

Mit 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)

Oder einfach:

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

PNGs Grenzen

PNG ist nicht perfekt. Seine Designentscheidungen waren Kompromisse, und einige davon kosten uns noch heute.

Keine eingebaute Animation: Die PNG Working Group lehnte Animation explizit ab. Sie wollten das Problem statischer Bilder vollständig lösen, bevor sie Komplexität hinzufügten. Das Ergebnis: Animations-GIF überlebte zwei weitere Jahrzehnte. APNG (Animated PNG) wurde schließlich 2004 standardisiert, doch die Browser-Unterstützung blieb bis in die späten 2010er lückenhaft. Selbst heute überwiegen animierte GIFs APNGs um Größenordnungen.

Große Dateigrößen bei Fotografien: Ein 12-MP-Foto als PNG ist typischerweise 15–25 MB. Als JPEG Qualität 90 sind es 3–5 MB. PNGs verlustfreie Kompression kann nicht mit JPEGs DCT-basierter psycho-visueller Reduktion konkurrieren. Für Fotografien ist PNG das falsche Werkzeug.

Kein CMYK-Support: PNG ist RGB-only. Druck-Workflows, die CMYK-Separation erfordern, müssen PNG in TIFF oder JPEG konvertieren. Das war eine bewusste Entscheidung – die Entwickler fokussierten sich auf Bildschirmdarstellung, nicht Druck – doch es limitiert die Nützlichkeit von PNG im professionellen Verlagswesen.

Langsamere Dekodierung als JPEG: PNG-Dekodierung erfordert inverse Filterung pro Scanline und DEFLATE-Dekompression. JPEG-Dekodierung ist hochgradig parallelisierbar und in Hardware stark optimiert. Auf Mobilgeräten kann ein großes PNG 2–3× länger zum Rendern brauchen als ein JPEG gleicher Auflösung, was den Largest Contentful Paint verzögert.

Keine progressive Qualität: Im Gegensatz zu JPEG 2000 oder JPEG XL kann PNG aus einer abgeschnittenen Datei keine niedrigere Qualität erzeugen. Entweder man hat die gesamte Datei, oder man hat nichts. Adam7-Interlacing hilft bei groben Vorschauen, reduziert aber nicht die Gesamtdateigröße.

Warum PNG JPEG nie ersetzt hat

Das ist das häufigste Missverständnis über Bildformate. PNG und JPEG konkurrierten nie um denselben Job.

JPEG ist ein lossy psycho-visueller Kompressor. Er verwirft Daten, die Ihr Auge wahrscheinlich nicht bemerken würde. Er wurde für Continuous-Tone-Fotografien entworfen – Bilder mit sanften Farbverläufen, feiner Textur und natürlicher Beleuchtung. Für diesen Job ist JPEG nach dreiunddreißig Jahren auf der Größe-Qualitäts-Kurve immer noch unschlagbar.

PNG ist ein verlustfreier Datenkompressor. Er bewahrt jedes Bit. Er wurde für Discrete-Tone-Bilder entworfen – Screenshots, UI-Elemente, Diagramme, Logos, Text-Overlays – wo scharfe Kanten und exakte Farben zählen. Für diesen Job ist PNG der Standard.

Beide Formate teilten das Web in klar getrennte Bereiche auf:

PNG wollte JPEG nie ersetzen. Es hat einfach einen anderen Job gefunden.

Wo PNG heute steht

Der Web Almanac 2025 schätzt den Anteil von PNG auf etwa 22 % aller im Web ausgelieferten Bilder. Das ist weniger als zum Höhepunkt – WebP und AVIF nehmen Marktanteile –, aber PNG bleibt das Fallback-Format, das jeder Browser, jeder Bildeditor und jedes Betriebssystem ohne Zögern öffnen kann.

WebP (Google, 2010) unterstützt sowohl lossy- als auch lossless-Modi, plus Animation und Transparenz. Ein lossless WebP ist typischerweise 20–30 % kleiner als ein entsprechendes PNG. Die Browser-Unterstützung ist seit 2020 universell. Für neue Projekte ist WebP lossless in den meisten Fällen der pragmatische Ersatz für PNG.

AVIF (AOM, 2019) erreicht eine noch bessere Kompression, doch sein lossless-Modus ist langsamer zu encodieren und decodieren als PNG. AVIF fehlt außerdem die volle Browser-Unterstützung für einige fortgeschrittene PNG-Features wie 16-Bit-Kanäle und eingebettete Gammakorrektur.

SVG beherrscht den Icon- und Logo-Bereich für einfache Vektorgrafiken, doch rasterisierte komplexe Grafiken brauchen weiterhin PNG.

Die praktische Realität: PNG verschwindet nicht. Es ist die sichere Standardeinstellung, das Format, in das man exportiert, wenn man garantieren muss, dass der Empfänger die Datei öffnen kann. Es ist das QWERTY der Bildformate – nicht optimal, aber universell verstanden.

Die Zukunft von PNG

PNG ist ein abgeschlossener Standard. Die Spezifikation hat sich seit 2003 nicht mehr bedeutend verändert. Diese Stabilität ist ein Vorteil, kein Nachteil. Sie können ein 1997 erstelltes PNG in jedem modernen Browser öffnen, und es wird identisch gerendert.

Doch das Ökosystem um PNG entwickelt sich weiter:

APNG gewinnt an Boden. Safari unterstützt es seit 2014. Chrome und Firefox folgten. Discord, Slack und Twitter rendern APNGs nativ. Für kurze UI-Animationen – Lade-Spinner, Reaktions-Emojis, Statusanzeigen – ersetzt APNG animiertes GIF durch kleinere Dateien und bessere Farbtreue.

PNG-Optimierungstools werden besser. oxipng, pngcrush und zopfli können durch Brute-Forcing besserer Filterkombinationen und DEFLATE-Parameter weitere 10–30 % der PNG-Dateigröße einsparen. Für stark frequentierte Sites ist es Standardpraxis, jedes PNG mit oxipng zu optimieren.

PNG als Container: Einige moderne Workflows betten ICC-Farbprofile, EXIF-Metadaten und sogar XMP-Daten in PNG-Chunks ein. PNG ist zu einem leichtgewichtigen Archivformat geworden – nicht so reichhaltig wie TIFF, aber weit portabler.

Die langfristige Perspektive: PNG wird noch Jahre mit WebP, AVIF und JPEG XL koexistieren. Es füllt eine Nische, die kein anderes Format vollständig besitzt: verlustfrei, patentfrei, universell unterstützt, und einfach genug, dass ein einzelner Entwickler in einer Woche einen Decoder aus der Spezifikation schreiben kann. Diese Kombination ist schwer zu verdrängen.

Das Fazit

PNG entstand, weil Entwickler es satt hatten. Ein Patentprozess bedrohte das offene Web, und eine Gruppe von Entwicklern baute in ihrer Freizeit eine Alternative. Sie wollten keinen Standard für dreißig Jahre schaffen. Sie wollten ein Problem lösen: Wie bringt man ein transparentes Logo auf eine Webseite, ohne Lizenzgebühren zu zahlen.

Das Ergebnis war viel besser, als jemand erwartet hatte. PNG brachte dem Web Echtfarbgrafiken, sanfte Transparenz und eine robuste Dateiintegrität. Es bewies, dass offene Standards, entwickelt von Freiwilligen, proprietären Formaten großer Unternehmen überlegen sein können.

Es ist nicht das kleinste Format. Es ist nicht das schnellste zu decodieren. Es beherrscht Animation nicht gut, und für Fotografien ist es ungeeignet. Aber wenn Sie sicherstellen müssen, dass jedes gespeicherte Pixel genau der ist, den Sie zurückbekommen – dann greifen Sie immer noch zu PNG.

Nicht jedes Bild beginnt als PNG. Haben Sie JPGs, die Transparenz oder verlustfreie Bearbeitung erfordern, konvertieren Sie sie einfach im Browser — ohne extra Software, ohne dass Daten Ihr Gerät verlassen. JPG zu PNG arbeitet lokal. Wo bei Web-Projekten jede Kilobyte zählt, bringt JPG zu WebP die Dateigröße runter, ohne etwas an der Bildqualität zu ändern. Und für Favicon-Icons macht JPG zu ICO aus Fotos passende ICO-Dateien.