Stand: 31. Oktober 2026. JPEG XL bekommt neuen Schwung: Chrome liefert das Bildformat ab Version 155 aus. Safari unterstützt es bereits seit Version 17, Mozilla hat die Aktivierung für Firefox angekündigt. Für Unternehmenswebsites ist das relevant, weil nun ein moderner Bildstandard mehrere große Browserfamilien erreicht. Trotzdem wäre es verfrüht, JPEG, WebP oder AVIF einfach durch Dateien mit der Endung .jxl zu ersetzen.
Was JPEG XL besser machen soll
Google nennt in der Ankündigung für Chrome 155 mehrere Stärken: 30 bis 50 Prozent bessere Kompression als klassisches JPEG, verlustfreie Kompression, HDR, progressive Darstellung und verlustfreies Transkodieren vorhandener JPEG-Dateien. Letzteres bedeutet, dass sich ein JPEG in JPEG XL überführen und später bitgenau wiederherstellen lässt.
JPEG XL eignet sich damit besonders für hochwertige Fotografien, große Bildarchive und Motive, bei denen feine Verläufe oder hohe Farbtiefe wichtig sind. Progressive Darstellung kann zusätzlich die wahrgenommene Ladezeit verbessern: Der Bildinhalt wird bereits während des Downloads erkennbar und schärft sich schrittweise. Chrome empfiehlt dennoch, JPEG XL und AVIF am konkreten Material miteinander zu vergleichen. Ein Format gewinnt nicht automatisch bei jedem Motiv und jeder Qualitätsstufe.
Browserunterstützung ist breiter – aber nicht lückenlos
WebKit führte JPEG XL mit Safari 17 ein. Mozilla beschreibt im Intent to Ship eine Rust-basierte Implementierung und die geplante browserweite Aktivierung. Chrome verwendet ebenfalls den speichersicheren Decoder jxl-rs.
Das klingt nach flächiger Unterstützung, erfasst aber nicht automatisch ältere Geräte, noch nicht aktualisierte Unternehmensrechner, In-App-Browser, WebViews und jede Browserableitung. Zudem unterscheiden sich einzelne Funktionen: Ein Browser kann JPEG XL grundsätzlich anzeigen, ohne progressive Darstellung oder Animation identisch umzusetzen. Die sichere Strategie lautet deshalb: JPEG XL als bevorzugte Quelle anbieten, aber ein verbreitetes Ersatzformat behalten.
So funktioniert der Fallback ohne Browserweiche
Das HTML-Element <picture> lässt den Browser selbst die passende Quelle wählen:
<picture>
<source srcset="motiv.jxl" type="image/jxl">
<source srcset="motiv.avif" type="image/avif">
<img src="motiv.jpg" alt="Präzise Beschreibung des Motivs"
width="1600" height="900" loading="lazy">
</picture>Ein Browser mit JPEG-XL-Unterstützung lädt die erste Quelle. Andere versuchen AVIF und greifen zuletzt auf JPEG zurück. Wichtig: Der Fallback ist kein zusätzlich sichtbares Bild, wird bei sauberer Umsetzung also nicht dreifach heruntergeladen. Breite und Höhe sollten gesetzt bleiben, damit beim Laden kein Layoutsprung entsteht. Für wichtige Startbilder darf loading="lazy" nicht unkritisch übernommen werden; dort kann verzögertes Laden den Largest Contentful Paint verschlechtern.
Der WordPress-Workflow ist der eigentliche Prüfpunkt
Browserunterstützung allein sagt noch nichts darüber aus, ob WordPress, der Server und ein Bild-CDN die Datei korrekt verarbeiten. WordPress erzeugt beim Upload mehrere Größen, ergänzt srcset und kann Bilder je nach Umgebung server- oder browserseitig bearbeiten. Die aktuelle WordPress-Dokumentation zu responsiven Bildern zeigt, wie stark die Auslieferung von erzeugten Untergrößen abhängt.
Vor einem produktiven Einsatz sollten deshalb diese Punkte geprüft werden:
- Akzeptiert die Mediathek die JXL-Datei und erzeugt sie alle registrierten Bildgrößen?
- Zeigen Editor, Frontend, Safari, Chrome und Firefox dasselbe Motiv korrekt an?
- Erkennt das CDN den MIME-Typ
image/jxl, oder liefert es die Datei als Download aus? - Bleiben Ausschnitte, Transparenz, Farbräume und Metadaten wie erwartet erhalten?
- Erzeugen Optimierungsplugins sinnvolle Varianten oder überschreiben sie das Format?
- Nutzen Social-Media-Vorschaubilder weiterhin JPEG oder PNG, falls der jeweilige Crawler JXL nicht versteht?
Ein sinnvoller Test statt einer Komplettumstellung
Für einen realistischen Vergleich genügen zunächst fünf bis zehn typische Bilder: ein großes Foto, ein feiner Farbverlauf, ein transparentes Motiv, ein kleines Vorschaubild und ein Bild mit vielen Details. Exportieren Sie JPEG XL, AVIF und den bisherigen Standard jeweils in visuell vergleichbarer Qualität. Vergleichen Sie Dateigröße, sichtbare Artefakte, Erstellungszeit und Darstellung auf echten Geräten. Ein Prozentwert aus einem Herstellerbeitrag ersetzt diesen Test nicht.
Auch die Pflegekosten zählen. Wenn Redakteure für jedes Bild manuell drei Dateien erzeugen und zuordnen müssen, kann ein kleiner Dateivorteil schnell unwirtschaftlich werden. Besser ist eine reproduzierbare Pipeline über Bild-CDN, Build-Prozess oder ein sauber getestetes WordPress-Setup. Das Original sollte unabhängig davon erhalten bleiben.
Ist JPEG XL jetzt bereit?
Als zusätzliche, moderne Bildquelle: ja. Für hochwertige Fotografie, progressive Darstellung und verlustfreie Workflows ist ein begrenzter Praxistest sinnvoll. Als einziges Format ohne Fallback: noch nicht. Dafür sind ältere Browser und nachgelagerte Systeme zu unterschiedlich.
Die robuste Entscheidung lautet daher: JPEG XL zunächst dort einsetzen, wo der Qualitäts- oder Größenvorteil messbar ist, über <picture> absichern und die komplette Kette von WordPress bis CDN prüfen. So lässt sich das neue Format nutzen, ohne Besucher oder Redaktionsabläufe von einer einzelnen Browserfunktion abhängig zu machen.