JPEG-, PNG- und WebP-Komprimierung sind unterschiedliche Aufgaben

Die passende Kompressionsstrategie hängt vom Bildformat und von den Eigenschaften ab, die erhalten bleiben müssen. JPEG tauscht meist etwas Wiedergabetreue gegen kleinere Dateien, PNG lässt sich häufig verlustfrei optimieren und WebP kann je nach Quelle und Encoder verlustbehaftete oder verlustfreie Bilddaten enthalten.

Zuletzt fachlich geprüft: 2026-09-19

Kernaussagen

Ein kleineres Bild ist nicht automatisch in jeder Eigenschaft gleichwertig.
Pixelabmessungen, Alpha-Transparenz, Dateiformat und Metadaten sind getrennte Eigenschaften.
Neukodierung entfernt häufig ursprüngliche Metadaten, auch wenn Breite und Höhe gleich bleiben.
Ein verifizierter Kompressor sollte sein eigenes Ergebnis wieder dekodieren oder strukturell prüfen.

JPEG: begrenzte verlustbehaftete Neukompression

JPEG ist für fotografische Inhalte gedacht und arbeitet typischerweise verlustbehaftet. Eine Neukodierung mit niedrigerer Qualität kann Bytes sparen und trotzdem die gleichen Pixelabmessungen behalten, entfernt aber Bildinformation.

Wiederholte JPEG-Kompression kann Artefakte verstärken. Deshalb sollte ein Kompressor mit einer begrenzten Qualitätsstrategie arbeiten und nicht unbegrenzt weiter verschlechtern.

PNG: verlustfreie Pixel mit strukturellen Optimierungen

PNG unterstützt verlustfreie Bilddaten und Alpha-Transparenz. Ein verlustfreier Optimierer kann Scanlines kompakter packen oder bessere Filter wählen, ohne die dekodierten Pixelwerte zu verändern.

Nicht jede PNG-Variante ist gleich einfach sicher zu verarbeiten. Palettenbilder, Interlacing, hohe Bittiefen, Animation und ungewöhnliche Chunks können eigene Regeln benötigen.

WebP: Formatunterstützung und Encoderverhalten zählen

WebP unterstützt verschiedene Kodierungsarten und Transparenz. Browser-native Encoder übernehmen nicht automatisch jede Eigenschaft und jedes Metadatum einer beliebigen Quelldatei.

Ein fokussierter Kompressor muss deshalb unterstützte Varianten definieren, notwendige Abmessungen und Alpha-Eigenschaften bewahren und sicherstellen, dass das Ergebnis tatsächlich WebP ist.

Warum ZAMAZY getrennte Tools verwendet

ZAMAZY verwendet getrennte JPEG-, PNG- und WebP-Kompressoren statt eines generischen Bild-Komprimieren-Buttons. Jedes Tool besitzt eigene Support- und Verifikationsregeln.

JPEG akzeptiert ausdrücklich verlustbehaftete Neukodierung, PNG konzentriert sich auf verlustfreie Pixelerhaltung und WebP wird innerhalb des unterstützten Umfangs auf Format, Abmessungen und Transparenzverhalten geprüft.

Beispiel und Entscheidungshilfe

Ein Foto, ein Screenshot mit kleiner Schrift und ein transparentes Logo setzen unterschiedliche Prioritäten. JPEG kann für Fotos passen, wenn Verluste akzeptabel sind; verlustfreies PNG ist sinnvoll, wenn dekodierte Pixel und Alpha exakt erhalten bleiben müssen. WebP kennt mehrere Modi, doch der ZAMAZY-WebP-Kompressor verwendet eine begrenzte verlustbehaftete Neukodierung, nicht alle Möglichkeiten des Formats.

Wähle den Kompressor für das vorhandene Dateiformat. Diese fokussierten Tools sind weder Formatkonverter noch Größenänderungswerkzeuge. Vergleiche Textkanten, Verläufe, Farben und transparente Ränder im Ergebnis. Identische Breite und Höhe beweisen keine identischen RGB-Pixel. Ein Qualitätswert ist eine Encoder-Einstellung, kein universeller Bildgütewert oder browserübergreifend vergleichbarer Prozentsatz.

Wann dieser Ansatz nicht passt

Erhaltenes Alpha beweist weder den Erhalt von Farbprofilen noch von Animation oder sämtlichen Metadaten. Ein bereits gut komprimiertes Bild kann kein akzeptables kleineres Ergebnis liefern. Werden exakte Pixel, Animation, ein Druckfarbworkflow oder ein anderes Format benötigt, ersetze dies nicht durch verlustbehaftete Kompression allein wegen einer unterstützten Dateiendung.

Redaktionelles Beispiel, kein Benchmark. Ergänzung geprüft am: 2026-09-19

Quellen und Aussagegrenzen

Die Quellen erläutern Formate und Verfahren. Sie zertifizieren ZAMAZY nicht; für ZAMAZY gelten die Fakten und Grenzen auf der jeweiligen Toolseite.

MDN: Image file type and format guide — Formatabwägungen; Formatfähigkeiten bedeuten nicht automatisch Tool-Unterstützung.
W3C: PNG Specification, Third Edition — PNG-Pixel, Alpha und Chunks; keine Zusage für jede PNG-Variante.
Google: WebP Container Specification — WebP-Modi, Alpha, Animation und Metadatencontainer.
MDN: HTMLCanvasElement.toBlob() — Ausgabeformat und Qualitätsparameter; keine zertifizierte Metadatenentfernung.

Eigene Herstelleruntersuchung: verlustfreie PNG-Erhaltung

Status: verifiziert. ZAMAZY hat drei fest definierte, vollständig synthetische PNG-Dateien mit der unveränderten PNG-Engine verarbeitet und das Ergebnis anschließend erneut dekodiert und strukturell verglichen.

Dies ist eine eigene Herstelleruntersuchung, keine unabhängige Zertifizierung. Die bewusst einfach komprimierbaren Testdateien wurden mit zlib-Kompressionsstufe 0 erzeugt und sind deshalb kein typischer Kompressionsbenchmark.

Diagramm des PNG-Nachweises: synthetische PNGs werden mit der echten ZAMAZY-PNG-Engine verarbeitet, erneut dekodiert und auf Scanlines, Chunks und Alpha verglichen. — Ablauf der reproduzierbaren Untersuchung. Die Medien zeigen ausschließlich synthetische Testdaten.

Beobachtete Ergebnisse der drei synthetischen PNG-Fälle
Fixture	Abmessungen	Eingang	Ausgang	Geprüfte Erhaltung
`rgb-flat-v1`	256 × 64	49.284 B	252 B	Scanlines identisch; Nicht-IDAT-Chunks identisch; zweiter Durchlauf ohne kleinere Ausgabe abgelehnt
`rgba-pattern-v1`	64 × 32	8.292 B	4.700 B	Scanlines identisch; Nicht-IDAT-Chunks identisch; Alpha identisch; zweiter Durchlauf ohne kleinere Ausgabe abgelehnt
`gray-metadata-v1`	64 × 32	2.199 B	158 B	Scanlines identisch; Nicht-IDAT-Chunks identisch; zweiter Durchlauf ohne kleinere Ausgabe abgelehnt

Negativfälle

In der verifizierten Umgebung wurden abgeschnittene zlib-Daten, eine ungültige Adler-32-Prüfsumme und zusätzliche Daten hinter dem zlib-Stream jeweils abgelehnt.

truncated-zlib: abgelehnt
invalid-adler32: abgelehnt
trailing-zlib-data: abgelehnt

Methode und Aussagegrenzen

Die Prüfung verglich die dekodierten Scanlines, Geometrie und alle Nicht-IDAT-Chunks vor und nach der Optimierung; beim RGBA-Fall wurde Alpha ausdrücklich mitgeprüft. Die separate Kontroll-Dekompression nutzte Node-zlib und ist keine unabhängige externe Prüfinstanz.

Der Nachweis gilt nur für die dokumentierten Fixtures und die angegebene Engine-Version. Er beweist weder alle PNG-Varianten noch Browser-Netzwerkverhalten, Geräteunterstützung, typische Kompressionsraten oder die Sicherheit beliebiger Nutzerdaten.

Studie png-preservation-v1 · geprüft am2026-09-18 · Node 22.22.3 / zlib 1.3.1-e00f703 / linux x64 ·Engine-Commit a12415a3a19f

Häufige Fragen

Ist PNG immer größer als JPEG?

Nein. Das hängt vom Bild ab. Fotos lassen sich häufig besser als JPEG komprimieren, während flächige Grafiken, textartige Bilder und Transparenz von PNG profitieren können.

Ist ein Bild verlustfrei, wenn die Abmessungen gleich bleiben?

Nein. Breite und Höhe können identisch bleiben, während JPEG oder verlustbehaftetes WebP Bildinformation bei der Kodierung entfernt.

Warum verschwinden Metadaten nach der Bildkompression?

Browser-Neukodierung erzeugt häufig einen neuen Bildstream, statt die ursprünglichen Container-Metadaten zu kopieren. EXIF, GPS und andere Metadaten brauchen deshalb explizite Erhaltungslogik.