JPEG XL 2026: Was Firefox 157 und Chrome standardmäßig planen
Mozilla und Chrome meldeten am 24. August JPEG-XL-Intents. Firefox 157 ist das Fenster; der Decoder ist jxl-rs.
Am 24. August 2026 veröffentlichte Mozilla auf Mozilla Hacks eine Intent to Ship für JPEG XL: Dekodierung standardmäßig in Firefox 157, Ziel Ende September. Am selben Tag reichte Chromium die Absicht ein, JPEG-XL-Dekodierung in Blink auszuliefern. Das ist eine Formatgeschichte, keine Anleitung für Mikrofon oder Bildschirmfreigabe.
Die Suchanfrage lautet JPEG XL 2026 Firefox Chrome Standarddecode. Safari dekodiert das Format seit 2023. Chrome entfernte 2022 sogar die Experimentunterstützung. Die Kehrtwende basiert auf jxl-rs, einem Rust-Decoder von Google Research — nicht auf der Rückkehr des alten, rund 100.000 Zeilen großen C++-Referenzdecoders.
Wer hat wann was angekündigt
Jake Archibald schrieb, Firefox habe JPEG XL 2021 hinter einem Flag gehabt, wolle aber keinen so großen Decoder standardmäßig aktivieren. Mozilla forderte das JPEG-XL-Team bei Google Research: einen sicheren, schnellen, kompakten, kompatiblen Rust-Decoder, dann würde Firefox ausliefern. Das Ergebnis ist jxl-rs. Es ist Kern der Firefox-Umsetzung und der Decoder, den auch Chromes Intent nennt. Phoronix berichtete am selben Tag, Nightly sei bereits an; Chromes Text nannte keine feste Stable-Version für alle Nutzer.
Mozilla
Intent to Ship: Standarddecode auf allen Plattformen in Firefox 157. Nightly ist voraus. Quelle: Mozilla Hacks, 24. Aug. 2026.
Chromium / Chrome
Intent, Blink-Decode mit demselben Rust-Decoder auszuliefern. Eine Zusage, kein Beweis, dass es für alle schon an ist.
Safari
JPEG XL seit 2023. Archibald merkt an, dass Safari noch das progressive Rendering fehlt, das Firefox betont.
Der Blocker war der Decoder
JPEG XL kann vorhandene JPEGs verlustfrei neu packen (häufig zitiert: etwa 20 %) und das Motiv nach nur einem Bruchteil der Datei zeigen. Browser zögerten wegen der Angriffsfläche: Bilder sind unbekanntes, vielfältiges Input. Mozilla setzte eine Latte, die die C++-Referenz nicht räumte; Google Research räumte sie in Rust.
JPEG XL gegen AVIF
Archibalds eigene Samples: für typische verlustbehaftete Webfotos ist AVIF meist kleiner; JPEG XL gewinnt bei Verlustfreiheit und beim Neupacken alter JPEGs. AVIF progressiv ist schwach, sehr große Bilder können JPEG XL rechtfertigen. Eigene Bilder messen.
| Aufgabe | AVIF | JPEG XL |
|---|---|---|
| Verlustbehaftete Webfotos | Meist kleiner | Bei gleicher Qualität oft größer |
| Verlustfrei / JPEG neu packen | Schwächer | Stärker |
| Progressives Zeichnen | Grundlegend | Firefox-Priorität |
Was das mit einem Browser-Raum zu tun hat
Codec-News gehört in die Bildpipeline. Kurze Ko-Kreation heißt: Browser öffnen, eine Seite teilen, die Zeichnung beenden. Ob Telefone sauber joinen, steht in den
Hinweisen zum mobilen Browser. Nur ein gemeinsames Bild braucht
die Leinwand auf einer Seite mehr als .jxl. Einen Raum jetzt öffnen:
rtcroom-Startseite.
Noch Fragen?
Dekodiert Chrome Stable JPEG XL schon für alle?
Der 24. August 2026 ist eine Intent to Ship. Chromium hat jxl-rs früher gemergt und hinter einem Flag getestet. Standard an für alle Stable-Nutzer hängt an späteren Release Notes.
Was ist jxl-rs?
Ein Rust-JPEG-XL-Decoder von Google Research. Mozilla machte ihn zur Lieferbedingung. Firefox und der geplante Chrome-Pfad nutzen ihn statt des C++-Decoders vor 2022.
Sollten Sites jetzt von AVIF wechseln?
Nein. Mozillas eigener Vergleich bevorzugt AVIF für typische Webfotografie. Firefox 157 und Chrome-Defaults abwarten, dann messen. CDNs und CMS hinken Browsern hinterher.