Chrome 155 aktiviert JPEG XL standardmäßig

Chrome 155 dekodiert JPEG-XL-Bilder standardmäßig, gab das Chrome-Team von Google bekannt, und zwar am 6. Oktober 2026. Der Decoder heißt jxl-rs und ist aus Gründen der Speichersicherheit in Rust geschrieben. Da Firefox 158 am 13. Oktober folgen soll, funktioniert JPEG XL bald in allen großen Browser-Engines. Damit endet ein vierjähriger Umweg für ein Format, das sich Webentwickler immer wieder gewünscht haben.

Was Chrome ausliefert

JPEG XL, Dateiendung .jxl, ist ein Bildformat, das JPEG ersetzen soll. Es kann Fotos in kleineren Dateien speichern, und es kann ein vorhandenes JPEG auch ohne Qualitätsverlust neu verpacken.

Das Chrome-Team nennt diese unterstützten Funktionen:

• verlustbehaftete und verlustfreie Kompression
• HDR, also High Dynamic Range, für hellere Lichter und tiefere Schatten
• verlustfreie JPEG-Transkodierung, die ein altes JPEG verkleinert und es wieder in das exakte Original zurückverwandeln kann
• progressive Dekodierung, die zuerst eine grobe Version des Bildes zeigt und es schärfer macht, sobald mehr Daten eintreffen
• Animation

Laut CoreWebVitals.io kam das Format im Februar 2026 mit Chrome 145 erstmals in den Browser, und zwar hinter einem Flag unter chrome://flags/#enable-jxl-image-format. Mit Chrome 155 ist das Flag nicht mehr nötig.

Warum der Decoder in Rust geschrieben ist

Bild-Decoder sind ein klassisches Ziel für Angreifer. Ein Fehler im Code, der ein Bild entpackt, kann ein präpariertes Bild zur Übernahme eines Browsers machen. Das Chrome-Team nennt Decoder „eine der kritischsten und am häufigsten angegriffenen Angriffsflächen in jedem modernen Webbrowser“.

Deshalb wählte es jxl-rs, einen von Grund auf in Rust geschriebenen Decoder. Der Compiler von Rust blockiert ganze Klassen von Speicherfehlern, die C und C++ zulassen. Das Team baute außerdem jxl_simd, eine SIMD-Schicht, die sich an der Highway-Bibliothek von Google orientiert. SIMD-Befehle lassen einen Prozessor viele Pixel auf einmal bearbeiten, und so bleibt der sichere Code schnell.

Das Chrome-Team sagt, dass Fuzzing und KI-gestützte Code-Reviews während der Arbeit keine Fehler bei der Speichersicherheit fanden. Beim Fuzzing wird der Code mit Millionen zufälliger Eingaben beworfen.

Bei der Geschwindigkeit widersprechen sich die Berichte. CoreWebVitals.io sagt, jxl-rs laufe innerhalb von 15-25 % des C++-Referenz-Decoders. Fileza beziffert den Abstand auf 5-10 %.

Warum Chrome seine Meinung geändert hat

Chrome hatte JPEG XL schon einmal entfernt. Fileza nennt das „die umstrittene Entfernung von 2022“. Das Chrome-Team sagt jetzt, es habe auf „anhaltendes Feedback und Anfragen von Webentwicklern“ reagiert. Es verweist auf die Beliebtheit des Formats bei den Vorschlägen für das Interop Project, in dem sich Browserhersteller jedes Jahr auf Lücken einigen, die sie gemeinsam schließen.

Das Comeback folgt auf eine lange Vorgeschichte. Mozilla kündigte im August die Unterstützung von JPEG XL mit einem eigenen Rust-Decoder an. jpegxl.info führt Firefox 158 inzwischen als Version, die das Format standardmäßig aktiviert, geplant für den 13. Oktober 2026.

Browser	Status von JPEG XL	Quelle
Chrome 155+	Standardmäßig aktiv	Chrome-Team, jpegxl.info
Chrome 145-154	Hinter einem Flag	CoreWebVitals.io
Firefox 158	Standardmäßig aktiv, geplant für den 13. Oktober 2026	jpegxl.info
Safari 17+	Seit September 2023 unterstützt, ohne Animation und ohne progressive Dekodierung	CoreWebVitals.io
Brave Beta 1.98+	Unterstützt, basiert auf Chromium 155	jpegxl.info

Wie viel kleiner die Dateien sind

Die Angaben zur Größe gehen auseinander. CoreWebVitals.io sagt, JPEG-XL-Dateien seien 50-60 % kleiner als JPEG und 10-15 % kleiner als AVIF. Sowohl diese Quelle als auch Fileza beziffern die verlustfreie Neukompression von JPEGs auf etwa 20 % weniger.

Nicht alle teilen diese Vergleiche. Eine ausführliche Kritik argumentierte im September, dass AVIF JPEG XL bei der Kompression jetzt schlägt. Messen Sie an Ihren eigenen Bildern, bevor Sie einen Gewinner küren.

Was das für Entwickler bedeutet

• Liefern Sie JPEG XL mit einem Fallback aus. Nutzen Sie das HTML-Element picture mit einer Quelle vom Typ image/jxl, oder prüfen Sie den Accept-Header auf dem Server. Chrome vor Version 155 und andere Browser ohne Unterstützung brauchen weiterhin JPEG, WebP oder AVIF.
• Beginnen Sie mit der verlustfreien JPEG-Neukompression. Sie ist der sicherste Gewinn. Vorhandene JPEGs schrumpfen um etwa 20 % und lassen sich in das exakte Original zurückverwandeln, sodass nichts verloren geht, falls Sie es sich anders überlegen.
• Testen Sie Animation und progressive Bilder in Safari. Laut CoreWebVitals.io fehlt Safari beides. Ein progressives JXL, das in Chrome gut aussieht, kann dort auf einmal laden.
• Aktualisieren Sie Ihre Bild-Pipeline. CDNs, Resizer und Upload-Prüfungen, die unbekannte MIME-Typen ablehnen, blockieren .jxl-Dateien. Prüfen Sie sie, bevor Nutzer mit dem Hochladen beginnen.
• Beobachten Sie Largest Contentful Paint. Kleinere Hero-Bilder können diesen Core-Web-Vitals-Wert verbessern, der misst, wann der Hauptinhalt erscheint. Vergleichen Sie vorher und nachher mit echtem Traffic, nicht nur in einem Labortest.

Verfolgen Sie die Veröffentlichung von Firefox 158 am 13. Oktober. Wenn sie planmäßig erscheint, wird JPEG XL zu einem Format, auf das Sie planen können, und nicht mehr zu einem Experiment.