PNG in WebP umwandeln
Screenshots, Logos und Grafiken liegen oft als PNG vor und sind dabei größer als nötig. Dieses Werkzeug kodiert dein PNG in WebP und, wenn es eine Grafik ist, zusätzlich verlustfrei als optimiertes PNG — und gibt das kleinere Ergebnis aus, das dein Qualitätsziel hält. Ein transparenter Hintergrund bleibt erhalten. Gerechnet wird in deinem Browser, gemessen gegen deine Vorlage.
Bild hierher ziehen
oder aus der Zwischenablage einfügen (Strg+V / ⌘V)
JPEG, PNG oder WebP · Das Bild bleibt auf deinem Gerät
Eigene Messreihe: 7 PNG-Vorlagen
Der Testkorpus enthält 7 PNG-Vorlagen. Bei Qualitätsziel SSIM ≥ 0,98 gibt das Werkzeug 7 davon als WebP aus; keine bleibt PNG. Über alle 7 zusammen sinkt die Datenmenge um 67,6 %, von 401 KB auf 130 KB.
Die 7 gewechselten Bilder sparen im Median 63,6 %. Keine PNG-Vorlage blieb PNG.
| PNG-Vorlagen im Korpus | 7 |
|---|---|
| als WebP ausgegeben | 7 |
| als PNG ausgegeben | 0 |
| davon unverändert zurückgegeben | 0 |
| Ersparnis über alle Vorlagen | 67,6 % |
| Median je Bild | 63,6 % |
| niedrigster gemessener Qualitätswert | 0,99487 |
Diese Läufe setzen keine Zielauflösung und keine Zielgröße. Gemessen ist damit allein, was der Formatwechsel bei unveränderten Maßen bringt. Ein Preset mit Zielbreite erreicht mehr — wie viel, steht hier nicht, weil es hier nicht gemessen wurde.
Grundlage sind die festgeschriebenen Korpusläufe dieses Projekts: 20 Bilder, Qualitätsziel SSIM ≥ 0,98, gemessen unter Node mit den Codec-Fassungen aus dem Manifest. Nicht mitgezählt: wide-gamut-p3.jpg — Entscheidung 44: Display-P3-Profil, unter Node ohne Farbumrechnung dekodiert. Sein SSIM unter Node ist nicht das des Produkts; das Bild prüft die ICC-Erkennung und zählt in keiner Qualitäts- oder Größenaussage mit.
Die Vorgaben dieser Seite, mit Herkunft
| Preset | Website / Blogbild (web) |
|---|---|
| Zielauflösung | bis 1920 px breit |
| Maßverständnis | Budget: kleinere Bilder bleiben unverändert, größere werden eingepasst |
| Zulässige Formate | WebP, JPEG, PNG — gewählt wird nach Messung |
| Qualitätsziel | SSIM ≥ 0,98 |
| Metadaten | werden entfernt (EXIF, GPS) |
| Herkunft der Werte | Projektwert, keine externe Quelle |
| Quelle | keine — der Wert stammt aus der Spezifikation dieses Projekts |
| Zuletzt geprüft | – Kein Prüfdatum nötig |
Die Breite 1920 steht als Standardwert in der Projektspezifikation 7.2. Eine Plattformdokumentation gibt es dafür nicht — die Zahl ist eine Setzung dieses Projekts, keine fremde Vorgabe. Die Breite ist ein Budget, keine Vorgabe — deshalb `fit: "max"`.
Plattformen ändern ihre Vorgaben ohne Ankündigung. Deshalb verfällt jede Prüfung nach 90 Tagen und erscheint dann als „Prüfung fällig" — hier und auf der Preset-Übersicht.
Das Qualitätsziel selbst ist nicht gesetzt, sondern geprüft: Am 13.09.2026 wurde es am Testkorpus gegen den Augenschein gehalten. Es besteht knapp — was das genau heißt und wo das Verfahren an seine Grenzen kommt, steht unter Wie wir Qualität messen.
Warum diese Werte?
Bei PNG-Quellen treten andere Kandidaten an als bei Fotos. Erkennt das Werkzeug eine Grafik — wenige Farben, harte Kanten —, kommt ein verlustfrei optimiertes PNG hinzu; erkennt es Transparenz, fällt JPEG weg, weil es keinen Alphakanal trägt. Gewonnen hat, wer bei gehaltenem Qualitätsziel die kleinste Datei liefert. Für PNG gibt es dabei keine Hysterese: Ist es kleiner, gewinnt es.
Der Unterschied zwischen beiden Wegen ist grundsätzlich. Ein optimiertes PNG ist verlustfrei — es ordnet die Daten neu, ohne ein einziges Bildpunkt-Detail zu verändern. Ein WebP in diesem Werkzeug ist verlustbehaftet kodiert und wird deshalb gemessen. Dass der gemessene Wert bei Screenshots und Logos gewöhnlich sehr hoch ausfällt, liegt an den Bildern: Große gleichfarbige Flächen überstehen Kompression fast unbeschadet.
Deshalb ist die interessante Frage auf dieser Seite nicht, ob WebP kleiner ist, sondern wann es das nicht ist. Die Messreihe unten beantwortet sie für unseren Testkorpus — und weil dort alle Bilder denselben Weg genommen haben, steht die Zahl so da, wie sie gemessen wurde, ohne Gegenbeispiel.
Häufige Fragen
- Bleibt die Transparenz erhalten?
Ja. Erkennt das Werkzeug einen Alphakanal, scheidet JPEG als Kandidat aus, weil es keine Transparenz tragen kann. Übrig bleiben WebP und PNG, die beide einen Alphakanal führen.
Lässt eine Plattformvorgabe ausschließlich JPEG zu und hat dein Bild einen transparenten Hintergrund, bricht das Werkzeug mit einem verständlichen Satz ab, statt die Transparenz stillschweigend durch Schwarz oder Weiß zu ersetzen.
- Wann bleibt PNG die richtige Wahl?
Immer dann, wenn das optimierte PNG kleiner ausfällt als das WebP — dann gewinnt es hier von selbst, und du bekommst es ohne weiteres Zutun.
Darüber hinaus gibt es Gründe, die keine Messung entscheiden kann: Verlustfreiheit als Anforderung, Weiterverarbeitung, die Frage, wo die Datei ankommen muss. Diese Seite trifft dazu keine Aussage, solange sie nicht belegt ist.
- Was ist mit Screenshots von Text?
Text in einem Screenshot ist der empfindlichste Fall: Kanten von Buchstaben sind genau die Struktur, deren Verlust man sofort sieht. Die Messung erfasst das — sie bewertet örtliche Struktur, nicht mittlere Abweichung.
Wenn dir das Ergebnis dennoch zu weich erscheint, ist das ein Hinweis darauf, dass das Qualitätsziel für deinen Fall zu niedrig steht. Es ist im Werkzeug sichtbar und steht unter jedem Ergebnis.
- Was bedeutet der Qualitätswert unter dem Ergebnis?
Er heißt SSIM und vergleicht das Ergebnis mit deiner Vorlage — nicht nach Bytes, sondern nach Struktur: Helligkeit, Kontrast und örtliches Muster in kleinen Fenstern über das ganze Bild. 1,000 bedeutet, dass die Bilder identisch sind — diesen Wert siehst du, wenn das Werkzeug dir dein eigenes Bild zurückgibt. Darunter wird der Abstand größer.
Der Wert wird bei jedem Lauf neu gemessen und ausgewiesen, auch wenn er ungünstig ausfällt. Wie genau gemessen wird und wo das Verfahren an seine Grenzen kommt, steht auf der Seite „Wie wir Qualität messen".
- Wird mein Bild irgendwohin hochgeladen?
Nein. Die Verarbeitung läuft vollständig in deinem Browser: Dekodieren, Messen und Kodieren geschehen auf deinem Gerät, in einem Hintergrundprozess. Es gibt keinen Server, der dein Bild entgegennimmt, und deshalb auch keinen, auf dem es liegen bleiben könnte.
Das ist keine Einstellung, die man umlegen kann, sondern die Bauweise: Das Werkzeug hat keine Gegenstelle, an die es etwas senden könnte.