JPEG XL in Chrome 155: Was Webdesigner jetzt über das neue Bildformat wissen müssen

JPEG XL wird wieder eine ernsthafte Weboption

Am 6. Oktober 2026 hat das Chrome-Team einen wichtigen Schritt für die Bildauslieferung im Web bestätigt: Chrome 155 kann JPEG-XL-Dateien mit der Endung .jxl standardmäßig dekodieren. Das offizielle Release für Desktop wurde am selben Tag angekündigt, die Verteilung an Nutzer erfolgt allerdings über mehrere Tage oder Wochen. Für Websites ist deshalb nicht allein das Veröffentlichungsdatum entscheidend, sondern die tatsächlich installierte Browserversion.

Auch andere Browser bewegen sich. Safari unterstützt JPEG XL bereits seit Version 17. Die derzeitigen Entwicklerhinweise zu Firefox 158 führen JPEG XL als standardmäßig aktiviertes Bildformat auf; die Veröffentlichung dieser Version ist für den 13. Oktober vorgesehen. Am 11. Oktober ist das also noch eine angekündigte Änderung, kein bereits abgeschlossener allgemeiner Firefox-Rollout. Zusammen ergibt sich ein guter Anlass, bestehende Bildstrategien neu zu prüfen.

Was JPEG XL technisch besonders macht

JPEG XL ist unter ISO/IEC 18181 standardisiert und für sehr unterschiedliche Bildanforderungen ausgelegt. Das Format unterstützt verlustbehaftete und verlustfreie Kompression, Transparenz, große Farbräume, hohe Farbtiefen, HDR und Animationen. Besonders interessant für Fotografien ist die progressive Darstellung: Bildinformationen können schrittweise übertragen und angezeigt werden, statt erst nach vollständigem Download sichtbar zu werden. Welche Funktionen ein Browser tatsächlich nutzt, hängt jedoch von seiner Implementierung ab.

Das Chrome-Team nennt gegenüber klassischem JPEG eine um etwa 30 bis 50 Prozent bessere Kompression als typische Stärke des Formats. Das ist keine Zusage für jede einzelne Datei. Motiv, Bildrauschen, gewünschte Qualität, Encoder-Einstellungen und Vergleichsmethode verändern das Ergebnis erheblich. Für reale Projekte zählt daher nicht die größte Prozentzahl aus einer Ankündigung, sondern ein nachvollziehbarer Vergleich mit den bereits verwendeten WebP- und AVIF-Dateien.

Verlustfreie JPEG-Umwandlung als unterschätzter Vorteil

Eine Besonderheit ist das verlustfreie Transkodieren bestehender JPEG-Dateien. Dabei lässt sich ein vorhandenes JPEG in JPEG XL überführen und später wieder als bitidentisches ursprüngliches JPEG rekonstruieren. Das unterscheidet sich von einer gewöhnlichen verlustbehafteten Neukompression, bei der zusätzliche Bildinformationen verloren gehen können. Gerade große Fotoarchive können dadurch Speicherplatz sparen, ohne ihre ursprünglichen JPEG-Dateien inhaltlich aufzugeben.

Für die Praxis ist die Unterscheidung entscheidend: Wer das bestehende JPEG bitgenau rekonstruieren möchte, muss ausdrücklich den dafür vorgesehenen verlustfreien Transkodierungsweg verwenden. Eine normale JPEG-XL-Neukodierung aus einem Bildeditor garantiert diese Eigenschaft nicht. Vor einem Archivwechsel sollten Teams daher Wiederherstellung, Metadaten, Dateinamen und die langfristige Lesbarkeit ihrer Backups testen, statt nur die erzeugte Dateigröße zu vergleichen.

Warum Chrome den Decoder in Rust umgesetzt hat

Googles neue Implementierung basiert auf jxl-rs, einem in Rust geschriebenen Decoder. Der Hintergrund ist Sicherheit: Browser verarbeiten Bilddateien aus fremden Quellen, und Fehler in komplexen Binärformaten können sicherheitsrelevant werden. Das Chrome-Team beschreibt, dass es mit Rust typische Speicherfehler bereits durch die Wahl der Programmiersprache vermeiden und verbleibende Risiken durch Tests und zusätzliche Schutzmechanismen begrenzen will.

Dabei ging es nicht nur um Speichersicherheit. Google verweist auch auf Optimierungen für moderne Prozessoren, etwa SIMD-Verarbeitung, und auf Prüfungen mittels Fuzzing. Daraus lässt sich aber keine pauschale Aussage ableiten, JPEG XL sei für jede Anwendung schneller oder grundsätzlich unangreifbar. Für Websitebetreiber bleibt die wichtigste Konsequenz: Browserupdates zeitnah einspielen und keine Bilddateien aus ungeprüften Quellen unkontrolliert durch eigene Konvertierungsdienste schleusen.

Browserunterstützung bedeutet noch nicht: Fallbacks abschalten

Ein häufiges Missverständnis lautet: Sobald ein großer Browser ein neues Format unterstützt, kann die gesamte Website darauf umgestellt werden. Das übersieht ältere Browserversionen, eingebettete WebViews, Unternehmensgeräte mit verzögerten Updates und Bildverarbeitungsdienste zwischen Server und Nutzer. Selbst bei wachsender JPEG-XL-Unterstützung sollte eine öffentliche Website deshalb weiterhin eine zuverlässig lesbare Alternative anbieten.

Das HTML-Element picture ist dafür der naheliegende Weg. Ein source-Eintrag verweist mit dem MIME-Typ image/jxl auf die neue Datei; das nachfolgende img-Element enthält beispielsweise eine WebP- oder JPEG-Version. Der Browser entscheidet anhand seiner Unterstützung, welche Quelle geladen wird. Wichtig ist, dass auch responsive Bildgrößen, Breitenangaben und der alternative Bildtext sauber gepflegt bleiben. Das Format ersetzt keine gute HTML-Auszeichnung.

JPEG XL, AVIF oder WebP: keine Universallösung

Google empfiehlt ausdrücklich, JPEG XL und AVIF an realen Motiven zu vergleichen. JPEG XL kann vor allem bei hochauflösenden Fotografien, sehr hoher Bildtreue, verlustfreien Workflows oder progressiver Darstellung interessant sein. AVIF und WebP bleiben für viele Websites leistungsfähige, breit etablierte Optionen. PNG und SVG haben ebenfalls weiterhin klare Einsatzgebiete, etwa für bestimmte verlustfreie Grafiken beziehungsweise skalierbare Vektormotive.

Für einen fairen Vergleich müssen die Bilder bei ähnlicher wahrgenommener Qualität betrachtet werden. Ein kleines, aber sichtbar beschädigtes Bild ist kein Performancegewinn. Sinnvoll sind mehrere Motivklassen: Porträts, Produktfotos, Screenshots, feine Texturen und transparente Grafiken. Teams sollten Dateigröße, Darstellungsqualität, Dekodieraufwand und Erstellungszeit gemeinsam bewerten. Eine einzelne Testdatei liefert noch keine belastbare Entscheidung für eine gesamte Mediathek.

Was bei CDN, CMS und Build-Pipeline geprüft werden muss

Zwischen Upload und Browser liegen oft mehrere Systeme: Content-Management-System, Bildoptimierer, CDN, Cache und gegebenenfalls ein externer Medienservice. Dass Chrome JPEG XL anzeigen kann, bedeutet nicht automatisch, dass diese Komponenten .jxl-Dateien akzeptieren oder erzeugen. Vor einer Einführung sollten Teams daher testen, ob Uploads funktionieren, Vorschaubilder erstellt werden, die Auslieferung den MIME-Typ image/jxl setzt und Caches die richtige Variante bereitstellen.

Wer Bildformate abhängig vom Accept-Header aushandelt, muss besonders sorgfältig mit Cache-Schlüsseln und dem HTTP-Header Vary umgehen. Andernfalls könnte ein Cache eine nicht unterstützte Bildvariante an andere Clients weiterreichen. Für kleine Websites ist eine explizite picture-Auslieferung häufig leichter nachvollziehbar als komplexe automatische Formatverhandlung. Bestehende WebP- oder JPEG-Pfade sollten erst entfallen, wenn sämtliche beteiligten Systeme nachweislich kompatibel sind.

Ladezeiten und Core Web Vitals realistisch messen

Kleinere Bilddateien können die Übertragungszeit reduzieren. Das ist besonders bei großen Titelbildern und langsameren Mobilverbindungen relevant. Dennoch folgt daraus nicht automatisch ein besserer Largest Contentful Paint. Auch Serverantwort, Priorisierung des Hero-Bildes, responsive Größen, Browserdekodierung und Layoutstabilität beeinflussen die Messung. Eine neue Dateiendung allein löst weder überdimensionierte Bilder noch fehlende Breiten- und Höhenangaben.

Ein belastbarer Test vergleicht dieselbe Seite mit identischem Layout, denselben Bildabmessungen und ähnlicher visueller Qualität. Dabei sollten sowohl Labormessungen mit gedrosselter Verbindung als auch echte Nutzungsdaten berücksichtigt werden. Für Bilder oberhalb des sichtbaren Bereichs ist außerdem zu prüfen, ob sie früh genug angefordert werden. Bei weiter unten platzierten Bildern kann Lazy Loading sinnvoll sein. Entscheidend ist das Gesamterlebnis, nicht die isolierte Codec-Benchmark.

SEO, GEO und Barrierefreiheit bleiben unabhängig vom Codec

Für Suchmaschinen zählt weiterhin, dass Bildinhalte erreichbar, verständlich eingebunden und thematisch passend sind. Ein JPEG-XL-Upload ist für sich genommen kein belegter Rankingvorteil. Aussagekräftige Dateinamen, Alt-Texte, Bildunterschriften, Kontext im Fließtext und passende strukturierte Daten bleiben die relevanteren redaktionellen Grundlagen. Wer Bilder für Artikel und soziale Vorschauen nutzt, sollte außerdem kontrollieren, welche Dateiformate externe Plattformen tatsächlich verarbeiten.

Barrierefreiheit wird durch bessere Kompression ebenfalls nicht automatisch erreicht. Dekorative Bilder benötigen andere Alternativtexte als inhaltlich wichtige Grafiken; informative Screenshots brauchen gegebenenfalls eine zusätzliche textliche Erklärung. Gerade bei der Umstellung einer Mediathek dürfen vorhandene Bildbeschreibungen nicht verloren gehen. Auch Metadaten sollten bewusst behandelt werden: Standortinformationen und andere eingebettete Angaben gehören nur dann in öffentlich ausgelieferte Dateien, wenn sie wirklich erforderlich sind.

Ein pragmatischer Pilot für Webteams

Statt sofort Tausende Dateien umzuwandeln, bietet sich ein begrenzter Pilot mit zehn bis zwanzig repräsentativen Bildern an. Zuerst werden Originale und aktuelle WebP- oder AVIF-Varianten gesichert. Danach entstehen JPEG-XL-Versionen mit dokumentierten Encoder-Einstellungen. Im nächsten Schritt prüft das Team die visuelle Qualität, Dateigröße, Serverantworten und das Verhalten in aktuellen sowie älteren Browsern. Auch mobile Geräte und mindestens eine reale Produktionsumgebung gehören in diesen Test.

Erst wenn diese Prüfungen überzeugen, lohnt sich eine kontrollierte Erweiterung auf neue Artikelbilder oder besonders große Fotogalerien. Die bestehende Bildbibliothek muss dafür nicht sofort neu aufgebaut werden. Wer einen CMS-Workflow betreibt, kann JPEG XL zunächst als zusätzliche Ausgabevariante behandeln und die bewährte Originaldatei behalten. So bleiben Rückbau und spätere Anpassungen möglich, falls sich Browser- oder Tool-Unterstützung anders entwickelt als erwartet.

Fazit: ein sinnvoller neuer Baustein, kein Pflichtwechsel

Die Ankündigungen der vergangenen Tage markieren einen konkreten Fortschritt: Chrome 155 unterstützt JPEG XL regulär, Mozilla bereitet die standardmäßige Aktivierung in Firefox 158 vor, und Safari verfügt bereits länger über grundlegende Unterstützung. Zusammen macht das den Codec für Webdesigner, Entwickler und Betreiber bildintensiver Websites deutlich interessanter. Der Nutzen liegt vor allem in zusätzlichen Möglichkeiten für Qualität, Kompression und Archivierung.

Die redaktionelle Einschätzung lautet dennoch: JPEG XL ist derzeit eine Option für gut geplante Tests, keine Aufforderung zur überstürzten Komplettmigration. Wer heute WebP oder AVIF sauber ausliefert, hat keinen akuten Handlungsdruck. Wer dagegen große Fotoarchive, hochwertige Produktbilder oder anspruchsvolle Medienworkflows betreut, sollte das Format jetzt evaluieren – mit Fallbacks, messbaren Qualitätskriterien und einer überprüften Auslieferungskette.