Das Konvertierungs-Labor

Fast jede Anleitung zu Bildformaten erzählt dir, WebP sei kleiner als PNG oder JPG kleiner als alles andere. Auf Seiten dieser Website stand früher Ähnliches. Das Problem: Solche Aussagen gelten nur für manche Bilder, und die Ausnahmen sind nicht klein. Auf unserer eigenen Seite PNG → JPG schrumpft ein Foto um 85%, während ein Screenshot einer Anwendung um 142% wächst. Gleiche Seite, gleiche Einstellungen, gegenteiliger Ratschlag.

Also haben wir aufgehört zu behaupten und angefangen zu messen. Jeder unten aufgeführte Konverter läuft gegen dasselbe kleine Set an Testbildern, und die Dateigrößen auf jenen Seiten sind die Bytes, die im echten Browser tatsächlich aus dem Werkzeug kamen. Diese Seite dokumentiert, wie das geschieht, was wir bewusst nicht gemessen haben und wo du die Testdateien bekommst, wenn du unsere Zahlen prüfen willst.

Die Testdateien

Ein Benchmark ist nur so ehrlich wie seine Eingaben. Auf Stockfotos haben wir absichtlich verzichtet: Sie bringen Lizenzen mit, lassen sich nicht weiterveröffentlichen, und eine Zahl, die niemand reproduzieren kann, ist kein Beleg. Stattdessen zeichnet ein Skript alle vier Bilder von Null auf, mit festem Zufalls-Seed — es entstehen jedes Mal exakt dieselben Bytes, und jede Quelldatei steht unten zum Download. Jedes Bild bricht eine andere Annahme über Kompression.

Fotoähnlich

Weiche Verläufe mit feinen Strichen und Filmkorn — die hochfrequenten Details, die ein echtes Foto hat.

Download: PNG 1.88 MB JPG 330.2 KB JFIF 330.2 KB WEBP 351.5 KB BMP 2.75 MB TIFF 2.75 MB AVIF 122.3 KB HEIC 886.6 KB

UI-Screenshot

Große einfarbige Flächen und harte 1-Pixel-Rahmen, wie der Screenshot einer Anwendung.

Download: PNG 18.0 KB JPG 45.3 KB JFIF 45.3 KB WEBP 7.3 KB BMP 2.75 MB TIFF 2.75 MB GIF 10.2 KB AVIF 1.4 KB HEIC 21.9 KB

Flache Illustration

Sechs Volltonfarben in großen Formen, komplett ohne Verläufe.

Download: PNG 34.7 KB JPG 25.6 KB JFIF 25.6 KB WEBP 10.8 KB BMP 2.75 MB TIFF 2.75 MB AVIF 3.2 KB HEIC 26.0 KB

Logo mit Transparenz

Harte Kanten, wenige Farben und ein transparenter Hintergrund.

Download: PNG 28.8 KB WEBP 7.6 KB GIF 4.3 KB HEIC 25.1 KB

Vektordiagramm

Ein handgeschriebenes SVG: Volltonformen und eine Kurve — 574 Byte Text.

Download: SVG 574 B

5-seitige gemischte PDF

Vier Textseiten plus eine ganzseitige Fotografie — die Seiten unterscheiden sich enorm im Gewicht.

Download: PDF 334.1 KB

3-seitige Text-PDF

Nichts als Text — die zweite Datei für den Merge-Test.

Download: PDF 2.8 KB

Wie die Zahlen entstehen

Es gibt nirgends einen Schätzschritt. Für jede Zeile in jeder Tabelle tut ein Skript Folgendes:

1. Es zeichnet die Testbilder auf ein Browser-Canvas und schreibt sie auf die Festplatte.
2. Es öffnet die echte /convert/…-Seite aus dem ausgelieferten Build.
3. Es legt die Datei in das Dateifeld dieser Seite — genau der Weg, den du auch nimmst.
4. Es wartet auf den Download-Link, holt den entstandenen Blob und liest dessen exakte Bytelänge.

Jeder Wert auf dieser Website entstand so, am 2026-07-28 mit Chromium 151.0.7922.34, mit den Standardeinstellungen der jeweiligen Seite, sofern die Tabelle nichts anderes angibt.

Zwei Einschränkungen sagen wir lieber deutlich, als sie zu verstecken. Erstens sitzen die Bild-Encoder im Browser, nicht auf unserem Server — ein anderer Browser oder ein neueres Chromium kann also leicht abweichende Größen liefern. Diese Zahlen sind reproduzierbar, nicht allgemeingültig. Zweitens ist Dateigröße nicht Bildqualität: Eine kleinere Datei kann durchaus schlechter aussehen, und keine dieser Tabellen misst, wie das Ergebnis aussieht.

Was wir nicht gemessen haben — und warum

Ein Browser-Canvas kann nur drei Formate kodieren — verlangst du von Chromium 151 ein image/avif, image/gif, image/bmp oder image/tiff, bekommst du ein PNG. Für alles außer PNG, JPEG und WebP mussten wir den Encoder also selbst schreiben. Drei sind inzwischen fertig: ein unkomprimiertes 24-Bit-BMP, ein unkomprimiertes Baseline-TIFF (genau das liefern Scanner oft) und ein GIF89a mit LZW-Kompression.

GIF ist nur teilweise abgedeckt, und schuld ist GIF selbst: höchstens 256 Farben. Wir haben die Farben unserer Testbilder gezählt — die UI-Aufnahme hat 13, das transparente Logo 12, beide kodieren also exakt. Die flache Illustration hat aber 490 und das Foto 200.374, weil die antialiasierten Kanten der Kreise und das Filmkorn hunderte Zwischentöne erzeugen. Sie zu reduzieren ergäbe ein anderes Bild, und ein Größenvergleich mit dem ursprünglichen PNG wäre sinnlos. Die GIF-Zeilen nutzen daher die zwei Bilder, die wirklich passen — und das sind genau die Inhalte, für die GIF in der Praxis verwendet wird: flache Interface-Aufnahmen und transparente Sticker.

AVIF ging einen anderen Weg. Der Inhalt einer AVIF-Datei ist ein AV1-Videobild, und einen AV1-Encoder schreibt niemand in ein paar hundert Zeilen von Hand. Diese Testdateien haben wir daher mit ffmpeg und libaom-av1 erzeugt: -crf 23 -cpu-used 4 -still-picture 1 -pix_fmt yuv420p. Der crf-Wert liegt bewusst nahe an der Qualität 92, die für die JPEG- und WebP-Quellen verwendet wurde — ein AVIF geringer Qualität gegen ein JPG hoher Qualität zu stellen wäre kein fairer Vergleich. Dass wir zu einem externen Werkzeug greifen, schwächt die Aussage nicht, denn die Regel hier lautete nie „die Datei muss im Browser entstehen“, sondern „die Datei muss veröffentlicht sein, damit jeder die Zahl reproduzieren kann“. Die drei AVIF-Dateien und der genaue Befehl sind beide veröffentlicht, beide Hälften sind also prüfbar.

HEIC: Wir haben geschrieben, das sei unmöglich — das war falsch. Auf dieser Seite stand früher, HEIC lasse sich nicht messen: dieser ffmpeg-Build habe libx265, aber keinen HEIF-Muxer, und auch im Browser oder auf npm gebe es keinen Encoder für .heic. Die erste Hälfte war richtig. Die zweite Hälfte machte aus der Grenze eines Werkzeugs eine allgemeine Grenze. libheif bringt einen eigenen x265-Encoder mit, und über pillow-heif entstanden die vier Testdateien beim ersten Versuch — bei Qualität 92, passend zu den JPEG- und WebP-Quellen. Alle vier sind mit den übrigen veröffentlicht. Präzise gesagt: Es sind mit libheif kodierte HEIC-Dateien, keine Fotos aus einem iPhone — Apples Dateien sind oft 10-Bit-4:2:0 mit eigener Ausrichtung und EXIF, deine Zahlen werden unsere also nicht genau treffen. Eine Grenze bleibt: Im Korpus gibt es kein transparentes AVIF, denn der AVIF-Muxer von ffmpeg schreibt das Alpha-Hilfsbild nicht und die erzeugte Datei ist deckend. Mit einer Datei ohne Transparenz zu prüfen, ob Transparenz erhalten bleibt, wäre bloße Inszenierung. Bei HEIC blieb das Alpha erhalten — das Korpus-Skript dekodiert jede Datei direkt zurück und prüft es; was Alpha verliert, wird verworfen statt veröffentlicht.

Die PDF-Werkzeuge fehlten zunächst aus einem anderen Grund — wir hielten Zusammenfügen oder Drehen für keine Frage der Dateigröße. Das war falsch, und die Zahlen sind der interessante Teil: Seite 3 unseres Testdokuments extrahiert ergibt 331,2 KB, Seite 4 nur 1,4 KB — aus derselben Datei. Alle neun PDF-Konverter sind daher inzwischen ebenfalls gemessen, an einem fünfseitigen Dokument mit sehr unterschiedlich schweren Seiten.

Damit stehen alle 38 Konverter auf gemessenen Zahlen. Es sind 38 statt 36 nicht, weil wir die Messlatte gesenkt hätten, sondern weil der Absatz darüber falsch war — und so einen Satz zu korrigieren heißt, den Encoder zu suchen, nicht die Zahl zu ändern.

Alle Messungen an einem Ort

Dieselben Daten wie auf den einzelnen Konverterseiten, hier gesammelt. Die Prozentwerte beziehen sich jeweils auf die Quelldatei. Wenn du lieber die Schlussfolgerungen als die Tabelle liest: Wir haben sie als Entscheidungshilfe aufgeschrieben — in welches Format umwandeln, sortiert nach dem, was tatsächlich im Bild steckt.

Mach es selbst nach

Dazu brauchst du uns nicht. Lad oben ein Testbild herunter, öffne die passende Konverterseite, leg die Datei hinein und vergleich die vom Werkzeug angezeigte Größe mit der Zeile in der Tabelle. Die Werkzeuge laufen vollständig in deinem Browser, und die Quelldateien sind dieselben, die wir benutzt haben.

Sechs Dinge, die die gesamte Tabelle uns beigebracht hat

1. Es gibt kein „kleineres Format", nur ein kleineres Format für ein bestimmtes Bild. Die größte Spanne in den Daten liefert ein einziger Konverter mit Standardeinstellungen: −85% beim Foto, +142% beim Screenshot.
2. WebP gewinnt fast überall — und „fast" ist das ehrliche Wort. Aus PNG-, JPG-, BMP- und TIFF-Quellen war jede WebP-Ausgabe kleiner als ihre Eingabe. Aus AVIF war sie es nie und konnte es nicht sein. Dann kam GIF dazu, und mit ihm die Ausnahme: Unser 4,3 KB großes transparentes GIF kam bei 5,4 KB heraus, plus 27%. Gegen ein 4 KB kleines Palettenbild bleibt einem modernen Codec kaum etwas zu holen.
3. Die Umwandlung in ein verlustfreies Format holt keine Qualität zurück, kostet aber immer Platz. JPG → PNG ließ das Foto um 542% wachsen — und das Bild ist genauso beschädigt wie das JPG zuvor.
4. Die Dateigröße einer BMP ist völlig unabhängig vom Inhalt. Alle drei BMP-Quellen sind auf das Byte genau 2,75 MB, ob sie ein körniges Foto oder sechs Volltonflächen enthalten. Genau das bedeutet „keine Kompression" in der Praxis.
5. Von Vektor zu Raster führt eine Einbahnstraße. Ein 574 Byte kleines SVG wird gerastert zu 6,6 bis 17,9 KB und ist nicht mehr skalierbar. Der Rückweg funktioniert nur bei flacher Grafik — das Foto zu vektorisieren ergab einen Haufen Pfade von 7,74 MB.
6. Die schiefsten Zeilen der Tabelle sind die AVIF-Zeilen, und das ist ein Kompliment an AVIF. Unsere UI-Aufnahme mit 1200 × 800 Pixeln passt als AVIF in 1.472 Byte; die Umwandlung kostet +378% als WebP, +2442% als PNG und +2942% als JPG. Für das Verlassen von AVIF gibt es kein Größenargument, nur ein Kompatibilitätsargument — genau dafür sind jene drei Seiten da.