JPEG, PNG, WebP oder AVIF: welches Format und warum

Zwei Fragen, und das Format ergibt sich daraus

Frage eins: Ist das Bild fotografisch oder flächig? Fotografisch heißt Halbton — Haut, Himmel, Laub, Sensorrauschen, keine Stelle, an der der Wert von einem Pixel zum nächsten springt. Flächig heißt das Gegenteil: Screenshots, Logos, Diagramme, Schemata, Strichzeichnung, Text, alles mit großen einheitlichen Flächen und harten Kanten dazwischen. Das ist kein stilistisches Etikett, sondern eine statistische Beschreibung der Pixeldaten — und die beiden Kompressionsfamilien wurden für entgegengesetzte Statistiken gebaut.

Frage zwei: Braucht das Bild einen Alphakanal oder Animation? JPEG hat beides nicht und wird es nie haben. PNG hat Alpha und animiert nur über APNG, eine Erweiterung, die in der ursprünglichen Spezifikation fehlte. WebP und AVIF haben beide Alpha und animieren beide. Soll ein Logo auf einem unbekannten Hintergrund liegen, ist JPEG raus, bevor über Dateigrößen geredet wird — ein JPEG-Logo bringt ein eingebranntes Hintergrundrechteck mit.

Was DCT und DEFLATE mit den Pixeln wirklich machen

JPEG zerlegt das Bild in 8 × 8-Blöcke, schreibt jeden Block als Summe von Kosinuswellen, teilt diese Koeffizienten durch eine Quantisierungstabelle und rundet. Feines Detail steckt in den hochfrequenten Koeffizienten — genau denen, die die Tabelle am stärksten teilt: Sie runden auf null und sind weg. Ein Foto verträgt das, weil seine hohen Frequenzen weitgehend Rauschen sind. Eine harte Kante nicht: Eine abrupte Stufe braucht viele hochfrequente Terme, und wenn man sie löscht, überschwingt und unterschwingt die Rekonstruktion beiderseits der Kante. Das ist Ringing, und deshalb wirkt Text in einem JPEG selbst bei hoher Qualität an den Rändern unscharf.

Der Effekt ist messbar und streng auf Kanten begrenzt. In unserem flächigen Testbild nahmen wir ein Band von 1040 Pixeln Breite und 70 Höhe rund um die Überschrift. In der Vorlage sind 56 119 Pixel dieses Bandes exakt 255,255,255. Nach einem einzigen JPEG-Durchlauf bei Qualität 75 sind 6 352 davon — 11,3 % — nicht mehr reinweiß, mit Abweichungen bis zu 14 Stufen. In einem leeren weißen Band von 86 400 Pixeln fern jeder Kante änderte sich kein einziges Pixel. JPEG verschlechtert das Bild nicht gleichmäßig, sondern genau dort, wo Flächengrafik lebt.

PNG geht umgekehrt vor. Es sagt jedes Pixel aus seinen Nachbarn voraus, zieht die Vorhersage ab und gibt die Reste an DEFLATE — denselben Algorithmus wie in einer Zip-Datei. Eine Folge identischer Pixel komprimiert sich auf fast nichts, weshalb ein Screenshot so gut schrumpft. Ein Foto hat keine Folgen: Jedes Pixel unterscheidet sich leicht vom Nachbarn, die Reste sind Rauschen, und DEFLATE findet keinen Halt. Das ist die vollständige Erklärung für die 2 021 576 Bytes, die unser Foto als PNG brauchte, gegen 311 380 als JPEG.

Dieselben zwei Bilder, vier Encoder, gemessen

Beim Foto ist die Rangfolge die erwartete. PNG 2 021 576 Bytes, JPEG bei Qualität 75 311 380, AVIF bei Encoder-Qualität 75 174 774, verlustbehaftetes WebP bei Qualität 75 105 608. Doch lies das letzte Paar genau, bevor du schließt: Qualität 75 in einem Codec ist nicht Qualität 75 in einem anderen. Die Zahl ist ein Index in den eigenen Quantisierer dieses Encoders, mehr nicht. Diese Werte sagen nur, dass die beiden Encoder bei nominell gleicher Einstellung auf verschiedenen Punkten der Größe-Qualität-Kurve landeten — nicht, dass WebP AVIF schlägt. Ein redlicher Codec-Vergleich fixiert zuerst eine Qualitätsmetrik und vergleicht dann Bytes, und das ist eine deutlich längere Übung als die auf dieser Seite.

Der flächige Screenshot bringt die interessante Umkehrung. PNG 88 693 Bytes. JPEG bei derselben Qualität 75: 152 065 Bytes — das 1,71-Fache des PNG, und dabei wirft es Pixel weg. Verlustbehaftetes WebP: 40 060 Bytes. Verlustfreies WebP: 36 074 Bytes, zugleich kleiner als die verlustbehaftete Variante und pixelgenau. Das ist keine Anomalie. Verlustbehaftetes WebP unterabtastet die Chrominanz immer auf 4:2:0: Farbiger Text und dünne farbige Linien bekommen die halbe horizontale und vertikale Farbauflösung, und der Encoder verbraucht danach Bits, um Kanten zu rekonstruieren, die er selbst weichgezeichnet hat. Bei Flächengrafik ist verlustfrei häufig zugleich kleiner und besser.

Die Einbahntür — und der Mythos vom Neuspeichern

Der Verlust ist wirklich eine Einbahnstraße. Wir haben unsere PNG-Vorlage in JPEG bei Qualität 75 und zurück in PNG gewandelt: Das zurückgekehrte PNG hat 1 470 130 Bytes gegen 2 021 576 des Originals. Es ist kleiner, weil der JPEG-Durchlauf Detail aus dem Bild geglättet hat, und kein PNG-Encoder bringt es zurück. Ab da ist die Datei verlustfrei, aber sie speichert verlustfrei ein beschädigtes Bild. PNG → JPEG → PNG liefert nie das Original zurück, und die kleinere Datei ist der Beleg dafür, kein Bonus.

Die populäre Fassung — jedes einzelne Neuspeichern verschlimmere den Schaden — erweist sich in der üblichen Formulierung als falsch, und wir haben es gemessen. Denselben JPEG zehnmal bei identischer Qualitätseinstellung neu zu codieren, ohne Zuschnitt, ohne Skalierung und ohne Bearbeitung dazwischen, verschob den mittleren absoluten Pixelfehler von 1,7591 auf 1,7670 Stufen. Das sind acht Tausendstel Stufe über zehn Generationen: Die JPEG-Requantisierung liegt nahe an einem Fixpunkt, solange das 8 × 8-Raster ausgerichtet bleibt und die Quantisierungstabelle gleich bleibt.

Ändert sich zwischen den Speicherungen irgendetwas, setzt die Kumulation sofort ein. Wir wiederholten die Kette mit einem kleinen zentrierten Zuschnitt vor jedem Speichern, was das Bild gegen das 8 × 8-Raster verschiebt. Nach sechs Zyklen war der mittlere absolute Fehler gegen eine Einmalcodierung desselben Zuschnitts von 1,76 auf 2,32 Stufen gestiegen — 32 % mehr Fehler — während die Einmalcodierung desselben Zuschnitts aus der unberührten Vorlage bei rund 1,77 blieb, gleich welcher Zyklus verglichen wurde. Die praktische Regel lautet also nicht „nie neu speichern“: Behalte die verlustfreie Vorlage, bearbeite jedes Mal aus ihr heraus und exportiere JPEG oder WebP als letzten Schritt statt als Arbeitsdatei.

Alpha, Bittiefe und die Obergrenzen, die niemand erwähnt

PNG speichert bis zu 16 Bit pro Kanal; JPEG, wie Browser es umsetzen, 8. WebP ist in beiden Modi 8 Bit, und sein verlustbehafteter Modus ist immer 4:2:0. AVIF erreicht 10 und 12 Bit und kann 4:4:4 codieren — deshalb ist es das einzige der vier, das einen weiten weichen Verlauf ohne Banding bewältigt, und das einzige mit einer echten Antwort auf HDR. Ist dein Bild ein Abendhimmel oder ein weicher Produkthintergrund, ist diese Bittiefe mehr wert als jede Bytezahl in der Tabelle oben.

WebP hat eine harte Obergrenze, die beim ersten Mal überrascht: Der Container codiert Breite und Höhe in 14 Bit, also kann kein WebP 16 383 Pixel je Seite überschreiten. Für ein Webfoto belanglos, für eine gescannte Karte oder ein langes zusammengesetztes Panorama tödlich. AVIF und PNG haben in den Größen, die du erzeugen wirst, keine vergleichbare Grenze. Das sollte man wissen, bevor man eine Pipeline baut, die standardmäßig alles nach WebP wandelt.

Unterstützung und Encoding-Kosten, und die Regel, die daraus folgt

Unterstützung ist nicht mehr der entscheidende Faktor wie vor fünf Jahren. WebP kam längst in Chrome, in Firefox 65 im Januar 2019 und in Safari 14 im September 2020. AVIF kam in Chrome 85 im August 2020, Firefox 93 im Oktober 2021, Safari 16 im September 2022 und schließlich Edge 121 im Januar 2024 — Edge war der letzte große Browser. Jede aktuelle Version jedes großen Browsers decodiert beides. Übrig bleibt ein langer Schwanz alter Betriebssysteme, die ihren Browser nicht mehr aktualisieren können; genau dafür gibt es das picture-Element mit mehreren Quellen und einem JPEG-Rückfall.

Der eigentliche Engpass sind stattdessen die Encoding-Kosten. Auf derselben Maschine und demselben 1600 × 900-Foto, bester von fünf Läufen: WebP 287 ms, AVIF 1 163 ms, JPEG 119 ms. AVIF brauchte viermal so lange wie WebP und fast zehnmal so lange wie das vom selben Werkzeug erzeugte JPEG. Es waren verschiedene Encoder beteiligt — cwebp für WebP, das System-Bildframework für AVIF und JPEG — behandle das genaue Verhältnis also als Hinweis, nicht als Allgemeingültigkeit. An der Richtung besteht kein Zweifel: AVIF ist AV1-Intracodierung, durchsucht einen viel größeren Raum und ist konstruktionsbedingt langsam. Bei hunderttausend Bildern ist das ein echter Budgetposten, und genau deshalb bleiben viele Teams bei WebP.

Die Regel, die daraus folgt, passt in drei Zeilen. Foto ohne Transparenz: WebP oder AVIF, dahinter JPEG für alte Clients. Screenshot, Logo, Diagramm, alles Flächige: zuerst verlustfreies WebP, PNG als sicherer Rückfall, und nie JPEG. Alles mit Alpha oder Animation: WebP oder AVIF, oder PNG, wenn die Palette klein ist und Verlustfreiheit mehr zählt als Bytes.

Häufige Fragen

Ist WebP immer kleiner als JPEG?

Nein. Bei Fotos meist ja, und bei unserem war es bei nominell gleicher Einstellung 66 % kleiner — doch diese Einstellungen sind zwischen Codecs nicht vergleichbar, und ein bereits stark komprimiertes JPEG kann beim Umwandeln nach WebP wachsen, weil der Encoder nun die Blockartefakte des JPEG wie Bilddetail reproduzieren muss. Miss immer an deinen eigenen Bildern statt einer Schlagzeilenprozentzahl zu vertrauen.

Stellt die Umwandlung eines alten JPEG nach WebP oder AVIF die Qualität wieder her?

Kann sie nicht. Das von JPEG verworfene Detail ist nicht in der Datei, also kann es nachgelagert niemand zurückholen. Die Umwandlung lohnt sich dennoch für die Bandbreite, und ein guter Encoder fügt kaum neuen Schaden hinzu — die Obergrenze setzt aber das Ausgangs-JPEG. Existiert das Raw oder das PNG noch, exportiere lieber daraus neu: Es kostet nichts extra und das Ergebnis ist wirklich besser.

Sollte ich überhaupt noch JPEG veröffentlichen?

Als Rückfallebene innerhalb eines picture-Elements ja — es kostet eine zusätzliche Datei und deckt jedes je gebaute Gerät ab. Als Primärformat für neue Arbeit gibt es keinen fotografischen Fall mehr, in dem JPEG bei gleicher Qualität in der Größe gewinnt, und keinen flächigen Fall, in dem es überhaupt gewinnt. Es bleibt außerdem das Sicherste, was man jemandem gibt, der es in unbekannter Software öffnet — weshalb E-Mail-Anhänge und Druckereien weiter darauf setzen.

PNG-8 oder PNG-24 für ein Logo?

PNG-8 speichert eine indizierte Palette von höchstens 256 Farben und ist deutlich kleiner, wenn die Grafik wirklich wenige Farben hat — bei den meisten flachen Logos ist das so. PNG-24 speichert Vollfarbe und wird nur für Verläufe oder weiche Schatten gebraucht. Prüfe das Ergebnis statt des Etiketts: Sieht die Palettenfassung identisch aus, behalte sie. Und vergleiche beide mit verlustfreiem WebP, das PNG bei unserem flächigen Testbild um 59 % schlug.

Lohnt AVIF die zusätzliche Encoding-Zeit?

Das hängt vollständig davon ab, wie oft eine Datei codiert und wie oft sie ausgeliefert wird. Ein Hero-Bild, einmal codiert und millionenfach ausgeliefert: nimm AVIF und die zusätzliche Sekunde. Nutzerhochgeladene Inhalte, die bei Anfrage codiert werden: die vierfache CPU pro Bild ist ein ernsthafter Betriebskostenposten, und WebP ist die pragmatische Wahl. AVIF verdient sich seinen Platz außerdem bei weiten weichen Verläufen, wo seine 10- und 12-Bit-Modi Banding vermeiden, das 8-Bit-Formate nicht vermeiden können.

Warum schlug verlustfreies WebP das verlustbehaftete beim Screenshot?

Weil verlustbehaftete Codierung für diese Daten das falsche Werkzeug ist. Der Screenshot besteht überwiegend aus langen Folgen identischer Pixel, die der verlustfreie Modus fast umsonst codiert, während der verlustbehaftete Modus zuerst die Farbe unterabtastet und dann Bits dafür ausgibt, die selbst weichgezeichneten Kanten zu beschreiben. Wir maßen 36 074 Bytes verlustfrei gegen 40 060 verlustbehaftet — kleiner und pixelgenau. Ist dein Bild flächig, probiere verlustfrei, bevor du zum Qualitätsregler greifst.