PNG vs. JPG: wann man was nutzt

Kurzfassung. Nutzt PNG für Screenshots, Logos und alles mit scharfen Kanten oder Transparenz, weil es verlustfrei ist und einen Alphakanal unterstützt. Nutzt JPG für Fotografien, weil seine verlustbehaftete DCT-Kompression 5- bis 10-mal kleinere Dateien ohne wahrnehmbaren Qualitätsverlust erzeugt.

Zwei Bildformate, beide über 30 Jahre alt, beide noch allgegenwärtig, beide in unterschiedlichen Situationen richtig. Die Faustregel ist einfach: PNG für Screenshots, Logos, alles mit scharfen Kanten oder Transparenz; JPG für Fotografien. Die Begründung dahinter ist interessanter als die Regel selbst.

Die wichtigsten Unterschiede

Warum verlustbehaftete Kompression bei Fotografien gewinnt

JPGs Kompressionsalgorithmus – die diskrete Kosinustransformation (DCT), gefolgt von Chroma-Subsampling und Huffman-Kodierung – ist um das menschliche Sehsystem herum konstruiert. Der Algorithmus verwirft Information, die das Auge kaum sehen kann:

• Chroma-Subsampling. Das menschliche Sehen ist weit empfindlicher für Helligkeit (Luma) als für Farbe (Chroma). JPG speichert Farbe in halber Auflösung der Helligkeit, was bei normaler Betrachtung unsichtbar ist.
• Frequenzbereichs-Quantisierung. Fotografien enthalten viel hochfrequentes Rauschen (feine Verläufe, Textur, Sensorkorn). Die DCT zerlegt das Bild in Frequenzbänder; JPG quantisiert die hochfrequenten Bänder aggressiv. Ihr verliert Detail, das ihr ohnehin nicht bewusst gesehen habt.

Für ein 4K-Foto sieht JPG bei Qualität 85 für die meisten Betrachter ununterscheidbar vom verlustfreien Original aus, bei einem Zehntel der Dateigröße. Dieses Verhältnis ist unschlagbar.

Warum verlustbehaftete Kompression bei Screenshots und Logos versagt

Flache Bereiche und scharfe Kanten sind genau die falsche Art von Inhalt für JPGs Frequenzbereichs-Mathematik. Der Algorithmus führt Ringing-Artefakte um harte Kanten ein (sichtbar als schwache Halos nahe Text), und das Chroma-Subsampling, das sich in einem Foto schön versteckt, wird zu offensichtlichen Farbverschiebungs-Schlieren neben einer gesättigten Markenfarbe.

PNGs DEFLATE-Kompression hingegen ist exakt. Eine 24-Bit-Farbe wird als 24-Bit-Farbe gespeichert. Flache Bereiche komprimieren wunderbar, weil die Lauflängenkodierung die Wiederholung erkennt; scharfe Kanten bleiben scharf. Ein typischer UI-Screenshot in PNG ist kleiner als derselbe Screenshot als JPG, weil die Bytes, die ein Foto hätte, von den Läufen dominiert werden, die PNG zum Frühstück verspeist.

Die Transparenzfrage

JPG hat keinen Alphakanal. Ein „transparentes JPG“ existiert nicht; das Format kann physisch keines speichern. Wenn etwas auf einem nicht-rechteckigen Hintergrund liegen soll – Logos, Icons, Sticker-artige Freisteller, alles Geschichtete – ist PNG das einzige der beiden, das funktioniert.

Der Behelf, den manche versuchen, ist, den JPG-Hintergrund an die Zielhintergrundfarbe anzupassen. Das funktioniert für ein bestimmtes Ziel und bricht in dem Moment, in dem das Asset wiederverwendet wird. Macht es nicht. Nutzt PNG oder, besser, ein Vektorformat wie SVG.

Wann weder PNG noch JPG die richtige Antwort ist

Drei Fälle:

1. Vektorgrafiken. Logos, Icons, Illustrationen sollten wenn möglich als SVG ausgeliefert werden. Vektoren skalieren auf jede Auflösung, bleiben auf jedem Display scharf und komprimieren meist auf wenige hundert Bytes. PNG legt euch auf eine Auflösung fest.
2. Moderne Web-Fotografien. Nutzt WebP (oder AVIF, wo unterstützt). Beide Formate erzeugen 25–50 % kleinere Dateien als JPG bei gleicher Bildqualität, und beide unterstützen Alpha. Unser JPG-zu-WebP-Konverter und PNG-zu-WebP-Konverter erledigen den Wechsel im Browser. Fallt mit<picture> auf JPG zurück für den kleinen Anteil an Clients, die WebP nicht unterstützen.
3. Inline-UI-Bilder. Manchmal ist die richtige Antwort, ganz auf eine separate Datei zu verzichten. Unser Bild-zu-Base64-Tool kodiert jedes Bild als Data-URI, die ihr direkt in HTML, CSS oder JSON einfügen könnt. Nützlich, wenn das Bild klein ist (unter ~10 KB) und eine separate HTTP-Anfrage den kritischen Renderpfad verlangsamen würde.

Der Entscheidungsbaum

1. Braucht es Transparenz? → PNG (oder SVG, falls Vektor).
2. Ist es eine Fotografie oder fotoähnlich? → JPG, oder WebP fürs Web.
3. Ist es ein Screenshot, eine UI-Aufnahme oder eine Flachfarbgrafik? → PNG.
4. Ist es unter 10 KB und wird einmal genutzt? → Base64 inline.
5. Ist es ein Logo oder Icon? → SVG. PNG als Fallback.

Das deckt etwa 95 % der Fälle ab. Die 5 % werden meist gelöst, indem man beide Formate ausprobiert und die Dateigrößen vergleicht – kein Algorithmus ist Magie, und die richtige Antwort hängt vom konkreten Inhalt ab.

Zahlen-Fakten

• Maximale Abmessungen: PNG bis 2³¹−1 × 2³¹−1 px (theoretisch); JPG begrenzt auf 65.535 × 65.535 px (16-Bit-Feld).
• Bittiefe: PNG unterstützt 1/2/4/8/16 Bit pro Kanal + Alpha; JPG ist fest auf 8 Bit pro Kanal, 3 Kanäle (kein Alpha). 12-Bit-JPG existiert, wird in Browsern aber selten unterstützt.
• Farbtiefe-Vorteil: 16-Bit-PNG = 281 Billionen Farben vs. JPGs 16,7 Millionen – nur für HDR-Quellen und Verlaufs-Banding-Arbeit relevant.
• Typisches Dateigrößenverhältnis (4K-Foto bei Qualität 85): PNG ~12 MB vs. JPG ~1,5 MB – etwa 8-fach.
• Typisches Dateigrößenverhältnis (UI-Screenshot, flache Farbe): PNG ~80 KB vs. JPG ~180 KB – PNG rund 2-mal kleiner.
• JPG-Qualität vs. Wahrnehmung: q=95 ist auf den meisten Inhalten visuell verlustfrei; q=80 ist der Sweetspot fürs Web; q=60 zeigt bei Gesichtern und Verläufen erste Artefakte.
• Chroma-Subsampling 4:2:0: speichert Chroma in Viertelauflösung, spart ~50 % Dateigröße mit minimalem Wahrnehmungseinbruch bei Fotos, aber sichtbarem Ringing bei Text.
• PNG-Kompressionsstufen: 0–9 in libpng; Stufe 9 erzeugt ~5–15 % kleinere Dateien als Stufe 6, dauert aber ~3- bis 5-mal länger. oxipng und zopflipng können weitere 10–20 % herausholen.
• Generationsverlust: 10-mal bei q=85 neu gespeichertes JPG verliert ~3 dB PSNR gegenüber dem Original; PNG ist verlustfrei, also Generationsverlust = 0.
• APNG-Dateigröße vs. GIF: typischerweise 50–70 % kleiner als äquivalentes GIF bei höherer Farbtiefe.

Entscheidungsmatrix

Quellen

• W3C / ISO 15948 – Portable Network Graphics (PNG) Specification, Third Edition – w3.org/TR/png.
• ITU-T T.81 (ISO/IEC 10918-1) – Information technology – Digital compression and coding of continuous-tone still images (JPEG-Kernspezifikation) – itu.int.
• Wallace, G.K. – The JPEG Still Picture Compression Standard, Communications of the ACM, April 1991 – die originale peer-reviewte JPEG-Arbeit.