JPEG-XL-Kritik: AVIF komprimiert jetzt besser

Gianni Rosato hat am 13. September 2026 eine ausführliche technische Kritik an JPEG XL veröffentlicht. Er argumentiert, dass aktuelle AVIF-Encoder JPEG XL inzwischen über den ganzen Qualitätsbereich schlagen. Der Zeitpunkt ist für alle wichtig, die Bilder im Web ausliefern, denn Firefox 157 soll JPEG XL standardmäßig aktivieren - Ende September.

JPEG XL ist ein Bildformat, das 2022 als ISO/IEC 18181 standardisiert wurde. AVIF ist das konkurrierende Format, das auf dem Videocodec AV1 aufbaut. Beide wollen bei gleicher sichtbarer Qualität kleinere Dateien liefern als JPEG.

Eines sollte man vor den Zahlen wissen: Rosato arbeitet am konkurrierenden Format. Er schreibt, dass er sich mit Bildkompression beschäftigt, und dass "Julio Barba und ich bei der Arbeit an einem AV1-Encoder AVIF deutlich vorangebracht haben". Er legt das im Beitrag selbst offen. Seine Messungen werden davon nicht falsch. Es heißt aber, dass sie bisher niemand unabhängig geprüft hat.

Was der Beitrag behauptet

Rosato lässt dem Format zuerst seine Stärken. "JPEG XL ist ein technisch beeindruckender Bildcodec; er ist ein klarer Fortschritt gegenüber JPEG", schreibt er. Seine Kritik richtet sich gegen JPEG XL im Vergleich mit AVIF, nicht im Vergleich mit JPEG.

Bei verlustfreier Kompression misst er JPEG XL rund 11,9 % kleiner als verlustfreies WebP bei realistischen Webinhalten. Das hält er für einen geringen Gewinn angesichts des Aufwands, den das Format verlangt. Bei verlustbehafteter Kompression berichtet er, dass aktuelle AVIF-Encoder in drei perzeptuellen Metriken besser abschneiden: CVVDP, MS-SSIM und SSIMULACRA2. Diese Metriken schätzen, wie ähnlich zwei Bilder für einen Menschen aussehen, statt nur veränderte Pixel zu zählen. "AVIF dominiert jetzt den gesamten Qualitätsbereich", schreibt er.

Er nennt auch Kompressionswerkzeuge, die JPEG XL fehlen. Es gibt keine gerichteten Prädiktionsmodi und keinen Deblocking-Loop-Filter. Gerichtete Prädiktion lässt einen Encoder einen Pixelblock entlang eines Winkels aus seinen Nachbarn vorhersagen, was bei harten Kanten hilft. Ein Deblocking-Filter glättet die sichtbaren Nähte zwischen komprimierten Blöcken. Dass beides fehlt, begrenzt das Format laut Rosato bei nicht fotografischen Bildern wie Screenshots und Strichzeichnungen.

Die Decode-Bombe

Die schärfste Behauptung betrifft die Dekodierzeit, nicht die Dateigröße. Rosato beschreibt ein absichtlich gebautes Bild, das er Prime Wall nennt. Es ist 1.918 Byte groß und brauchte auf einem M5 Pro 17,43 Sekunden Nutzerzeit zum Dekodieren. Er schreibt: "Das Prime-Wall-Bild ist nur 1.918 Byte groß, damit wird es gleich trivial einfach, schwache Geräte mit JXL zu bombardieren."

Das ist die Form eines Denial-of-Service, keine Qualitätsbeschwerde. Ein Upload von zwei Kilobyte, der Sekunden CPU kostet, ist ein Problem für jeden Dienst, der von Nutzern gesendete Bilder dekodiert. Er führt die Lücke darauf zurück, wie ausdrucksstark die JPEG-XL-Spezifikation ist. Manche Konstruktionen sind erlaubt und gleichzeitig extrem langsam.

Er berichtet zwei weitere Befunde zum Dekodieren. WebP dekodiert in seinen Tests mehr als 10-mal schneller als JPEG XL. Progressives Rendering funktioniert inzwischen auch in AVIF, und das war einer der klarsten verbleibenden Vorteile von JPEG XL.

Beide Seiten messen gegen unterschiedliche Bezugsgrößen

Die Arbeit des JPEG-XL-Projekts selbst verkompliziert das Bild bei der Geschwindigkeit. jxl-rs ist der Rust-Decoder, der laut Projekt in Chrome und in Firefox ausgeliefert wird. Das Repository nennt als Ziel die vollständige Konformität mit der Spezifikation, mit besserer Speichersicherheit und besserer Dekodierleistung als libjxl, die offizielle C++-Referenzsoftware. Das Projekt sagt, jxl-rs erreiche diese Referenz knapp und übertreffe sie manchmal, bei geringerem Speicherbedarf.

Diese Aussagen und die von Rosato widersprechen sich nicht direkt. Er misst JPEG XL gegen WebP und AVIF. Das Projekt misst seinen neuen Rust-Decoder gegen seinen eigenen älteren C++-Decoder. Ein Decoder kann seinen Vorgänger schlagen und trotzdem gegen WebP verlieren. Zusammengelesen beschreiben beide echte Fortschritte beim Dekodieren, die den von Rosato berichteten Abstand noch nicht geschlossen haben.

Was das für Entwickler bedeutet

Wechseln Sie das Format nicht wegen eines einzigen Beitrags. Jede Zahl oben kommt aus dem Testsatz eines einzigen Autors, und dieser Autor arbeitet an dem Format, das in seinem Vergleich gewinnt. Die richtige Reaktion ist, die eigenen Bilder zu messen, denn Kompressionsergebnisse schwanken stark mit dem Inhalt.

Drei Dinge lohnen sich in diesem Monat. Erstens: Kodieren Sie eine echte Stichprobe Ihrer Produktionsbilder als AVIF und als JPEG XL, und notieren Sie die Größen bei einer Qualität, die Sie wirklich ausliefern würden. Zweitens: Messen Sie die Dekodierzeiten auf einem billigen Telefon statt auf Ihrem Laptop. Drittens: Wenn Sie Bild-Uploads annehmen, setzen Sie ein hartes Zeit- und Speicherlimit für das Dekodieren, und testen Sie es mit einer absichtlich sperrigen Datei.

Der dritte Punkt lohnt sich, ob Sie JPEG XL jemals ausliefern oder nicht. Prime Wall ist ein JPEG-XL-Beispiel, aber jeder moderne Codec hat pathologische Eingaben. Ein Upload-Pfad ohne Dekodier-Budget ist der eigentliche Fehler.

Für die meisten Websites hat sich der praktische Rat seit Mozillas Ankündigung kaum verschoben. Nutzen Sie AVIF für gewöhnliche Fotos und JPEG XL dort, wo progressives Rendering sehr großer Bilder zählt. Diese Kritik liefert einen Grund, den zweiten Fall neu zu prüfen, denn AVIFs progressive Unterstützung ist nicht mehr die Schwachstelle, die sie war.