JPEG XL in Chrome 155: Was das Bildformat für DAM und Web bedeutet

Von /
Isometrische Illustration: Browserfenster zeigt ein Foto, davor ein JPEG-XL-Dateisymbol mit grünem Häkchen

Google Chrome zeigt ab Version 155 Bilder im Format JPEG XL an. Weil Safari das Format seit 2023 unter­stützt und Firefox 158 es seit dem 13. Oktober 2026 stan­dard­mä­ßig akti­viert, können erst­mals alle großen Browser-Engines .jxl-Dateien darstel­len. Für Verlage und Agenturen stellt sich damit die Frage, wo JPEG XL in Bild-Workflows, DAM und Web-Ausspielung einen Platz hat.

Angekündigt hat Google den Schritt am 6. Oktober 2026 im Blog »Chrome for Developers«. Chrome 155 wird seit Ende September schritt­weise verteilt, zunächst als soge­nann­tes Early Stable. Das Google-Release-Blog verzeich­net am 13. Oktober ein Stable-Update auf Version 155.0.8059.79 für Windows, Mac und Linux. Laut der Ankündigung im Blink-Entwicklerforum gilt die Unterstützung für Windows, Mac, Linux, ChromeOS, Android und Android WebView.

Neuer Decoder statt alter Code

Chrome hatte JPEG XL schon einmal als expe­ri­men­telle Funktion an Bord und den Code Ende 2022 wieder entfernt. Google verwies damals unter ande­rem auf die offene Frage, ob andere Browser das Format unter­stüt­zen, und auf den Wartungsaufwand, den jedes zusätz­li­che Bildformat verur­sacht.

Die Rückkehr beruht auf jxl-rs, einem in Rust geschrie­be­nen Decoder. Rust verhin­dert typi­sche Speicherfehler, die bei Bildbibliotheken in C und C++ ein bekann­tes Sicherheitsrisiko sind. Nach Angaben der Chrome-Entwickler haben Fuzzing-Tests und KI-gestützte Code-Reviews keine Speichersicherheitsfehler in jxl-rs gefun­den. Testen ließ sich der Decoder bereits seit Chrome 145 (Februar 2026) über ein Flag.

Zum Format selbst nennt Google eine um 30 bis 50 Prozent bessere Kompression als JPEG, dazu verlust­freie Kompression, HDR, Animationen und einen schritt­wei­sen Bildaufbau in feinen Stufen (progres­sive Dekodierung). Bestehende JPEG-Dateien lassen sich laut JPEG-Gremium verlust­frei in JPEG XL umwan­deln und wieder exakt in das Original zurück­füh­ren. Google empfiehlt ausdrück­lich, JPEG XL und AVIF paral­lel zu testen; Vorteile sieht das Team vor allem bei hoch­wer­ti­ger oder verlust­freier Kompression von Fotos.

Was bedeutet das konkret?

JPEG XL wird damit zu einem realis­ti­schen Ausspielformat für das Web. Für Bild-Workflows in Verlagen und Agenturen sind vor allem diese Punkte rele­vant:

  • Web-Ausspielung: Ältere Browserversionen zeigen .jxl-Dateien nicht an. Ein Fallback bleibt nötig, etwa über das HTML-Element »picture« mit JPEG oder AVIF als Alternative. Firefox 158 meldet den Typ »image/jxl« zusätz­lich im Accept-Header, anhand dessen Server das passende Format wählen können.
  • Unterschiede zwischen Browsern: Laut einer von xenos­pec­trum zitier­ten Mozilla-Präsentation zeigt Safari JPEG XL weder progres­siv noch animiert an, Firefox stellt HDR-Bilder in SDR dar. Die Browserhersteller unter­su­chen solche Abweichungen gemein­sam im Projekt Interop 2026.
  • DAM und Renditions: Ob ein DAM-System .jxl-Dateien annimmt, Vorschauen erzeugt und Derivate für das Web rech­net, hängt von den einge­setz­ten Bildbibliotheken und Konvertern ab. Hier helfen nur Herstellerangaben und eigene Tests.
  • CMS: WordPress führt JPEG XL im aktu­el­len Entwicklungsstand des Kerns nicht unter den erlaub­ten Dateitypen. Uploads in die Mediathek setzen daher eine Erweiterung voraus, Größenvarianten zusätz­lich eine passende Bildbibliothek auf dem Server.
  • Metadaten: JPEG XL sieht laut JPEG-Gremium Metadaten wie Exif und den Container JUMBF vor. Ob Bildcredits und Rechteangaben eine Konvertierung über­ste­hen, muss für jede Strecke einzeln geprüft werden.

Unsere Einordnung: JPEG XL gezielt testen statt umstellen

Für eine Massenkonvertierung von Bildbeständen besteht kein Anlass. Das Original im DAM bleibt die Referenz; JPEG XL kommt am ehes­ten als zusätz­li­che Rendition am Ende der Kette infrage, dort, wo Bilder für das Web ausge­spielt werden. Wir empfeh­len folgende Schritte:

  • Kette erfas­sen: Welche Systeme verar­bei­ten Ihre Bilder, vom DAM über Redaktionssystem und CMS bis zu Bildserver und CDN, und welche davon lesen oder schrei­ben .jxl?
  • Pilot mit eige­nem Material: Typische Motive als JPEG XL und AVIF erzeu­gen und Dateigröße, Bildqualität und Ladezeit auf Mobilgeräten verglei­chen. Im Blink-Entwicklerforum wurde auf die vergleichs­weise lang­same Dekodierung verlust­frei kompri­mier­ter JPEG-XL-Dateien hinge­wie­sen; das gehört in den Test.
  • Metadaten prüfen: Nach der Konvertierung kontrol­lie­ren, ob Credits, Copyright und Beschreibungen erhal­ten blei­ben.
  • Archiv sepa­rat bewer­ten: Die verlust­freie Umwandlung bestehen­der JPEGs ist für Speicherplatz inter­es­sant, lohnt sich aber nur, wenn alle lesen­den Systeme damit umge­hen können.

Als Integrator für DAM-Systeme wie WoodWing Assets und fylr betrach­ten wir solche Formatfragen entlang der gesam­ten Strecke: vom Import über die Erzeugung der Renditions bis zur Übergabe an CMS und Website.

Mit Chrome 155 ist JPEG XL im Web ange­kom­men; ob sich das Format für Ihre Workflows lohnt, entschei­den Tests mit eige­nem Material und die Fähigkeiten der betei­lig­ten Systeme.

Quellen

Wie können wir Sie unter­stüt­zen?

Kostenloses Erst-Gespräch

Lassen Sie uns gemein­sam prüfen, wo in Ihren Kommunikations‑, Marketing- oder Unternehmensprozessen konkrete Effizienzpotenziale liegen.

– Henning Bartens, Co-CEO

Termin verein­ba­ren


Strukturiert. Ehrlich. Informativ.

Nach oben scrollen