JPEG XL vs. AVIF: Welches Format sollten Sie ausliefern?

Für die produktive Web-Auslieferung im Jahr 2026 empfiehlt sich AVIF: Das Format erreicht Mitte 2026 eine globale Browser-Abdeckung von rund 93 % und wird von CDNs, CMS-Systemen und Build-Tools ausgereift unterstützt. JPEG XL ist technisch das überlegene Format — schnelleres Encoding, deutlich bessere verlustfreie Komprimierung, natives progressives Decoding — doch Chrome liefert es nach wie vor nur hinter einem Flag aus, sodass JXL auf eine Abdeckung von rund 15 % kommt, die ausschließlich über Safari erreicht wird und die caniuse als partial support klassifiziert. Dieser eine Umstand entscheidet die Frage für jede öffentlich zugängliche Website: Solange Chrome JXL nicht standardmäßig aktiviert, liefert ein JXL-first-Delivery-Stack dem Großteil der Nutzer ohnehin AVIF oder JPEG aus.

Dieser Artikel richtet sich direkt an diejenigen, die sich mitten in der Entscheidung befinden: Sie liefern bereits WebP oder AVIF aus, kennen die Grenzen von JPEG und suchen eine fundierte Einschätzung auf Basis der aktuellen Browser-Realität — keine Format-Evangelisierung. Der Artikel geht Kriterium für Kriterium vor — Komprimierung, Browser-Unterstützung, Encoding-Aufwand, progressives Rendering — liefert ein korrektes <picture>-Snippet und benennt das konkrete Signal, das die Empfehlung kippen würde.

Was die beiden Formate eigentlich sind

AVIF und JPEG XL lösen dasselbe Problem — kleinere Dateien bei gleicher oder besserer Qualität — entstammen jedoch gegensätzlichen Design-Traditionen. AVIF (AV1 Image File Format) wurde 2019 von der Alliance for Open Media eingeführt und leitet sich aus der Keyframe-Intra-Kodierung des AV1-Video-Codecs ab, der von Diensten wie YouTube und Netflix eingesetzt wird. JPEG XL (ISO/IEC 18181) wurde von der Joint Photographic Experts Group gemeinsam mit Google und Cloudinary als reines Standbildformat entwickelt und 2022 als Standard verabschiedet.

Diese unterschiedliche Herkunft — AVIF abgeleitet von einem Video-Codec, JPEG XL zweckgebaut für Standbilder — erklärt den Großteil der nachfolgend beschriebenen Kompromisse. AVIF erbt die starke verlustbehaftete Fotokomprimierung von AV1 sowie dessen CPU-intensiven Encoder. JPEG XL wurde um bildspezifische Anforderungen herum entwickelt: progressives Decoding, hohe Farbtiefe, verlustfreie Modi und eine Funktion, die kein anderes modernes Format bietet — verlustfreie JPEG-Rekomprimierung. Ein vorhandenes JPEG kann zu JXL umgewandelt werden, was die Dateigröße um rund 20 % reduziert, und byte-genau in das ursprüngliche JPEG zurückkonvertiert werden. Damit ist JXL das einzige praktikable Format für die verlustfreie Archivierung großer JPEG-Bibliotheken — ein echter Entscheidungsfaktor, keine Randnotiz.

Komprimierung: Wer gewinnt, hängt vom Inhalt ab

AVIF gewinnt bei verlustbehafteter Fotokomprimierung in niedrigen bis mittleren Qualitätsstufen; JPEG XL gewinnt bei hoher Qualität, bei nicht-fotografischen oder flächigen Grafiken sowie klar bei verlustfreier Komprimierung. Eine pauschale Aussage wie „Format X ist N % kleiner” gibt es nicht, und jeder Artikel, der eine solche Zahl nennt, übertreibt ein inhaltsabhängiges Ergebnis.

Die praktische Aufschlüsselung:

• Verlustbehaftete Fotografie, mittlere Qualität: AVIF-Verluste wirken bei aggressiven Bitraten weicher und natürlicher — das Format verwischt Kanten und verbirgt Artefakte dort, wo JXLs VarDCT-Modus Ringing oder Blocking erzeugen kann, das an klassisches JPEG erinnert. Das ist das Heimspielfeld von AVIF und der häufigste Anwendungsfall im Web.
• Hohe Qualität und nicht-fotografische Inhalte: JPEG XL hält mit AVIF mit oder übertrifft es, insbesondere bei Illustrationen, Logos, Screenshots und textlastigen Grafiken, wo sein modularer Kodierungsmodus flächige Farbbereiche sauber verarbeitet.
• Verlustfrei: JPEG XL ist klar überlegen. Verlustfreies AVIF ist in der Praxis kaum sinnvoll — es schneidet kaum besser als PNG ab — während verlustfreies JXL mit PNG konkurriert und häufig deutlich kleiner ist.

Komprimierungsverhältnisse variieren je nach Bildinhalt und Qualitätseinstellung erheblich; der Vorsprung von JXL gegenüber AVIF ist besonders inhaltsabhängig und kein feststehender Wert. Bevor Sie eine Inhaltsbibliothek auf ein Format festlegen, testen Sie Ihre spezifischen Assets in Squoosh. Das Tool kodiert beide Formate direkt im Browser und zeigt den Größen-/Qualitätskompromiss für Ihre eigenen Bilder — nicht für den Benchmark-Datensatz eines anderen.

Browser-Unterstützung: Die entscheidende Achse

Die Browser-Unterstützung ist der Punkt, an dem diese Entscheidung tatsächlich fällt — und die Achse, die in den meisten Referenzartikeln falsch dargestellt oder veraltet berichtet wird. Mitte 2026 erreicht AVIF eine globale Abdeckung von rund 93 % und ist standardmäßig aktiviert in Chrome, Edge, Firefox und Safari. JPEG XL kommt auf rund 15 % Abdeckung — ausschließlich über Safari und als partial support klassifiziert.

Die Chrome-Geschichte ist relevant, weil zwei der drei meistzitierten Artikel sie falsch wiedergeben. Der korrekte Zeitverlauf:

Die weit verbreitete Behauptung, Chrome habe JPEG XL „eingestellt”, ist inzwischen überholt. Chromium hat die veraltete Bezeichnung des Formats zurückgezogen und das Decoding mithilfe eines neuen Rust-basierten Decoders anstelle des C++-libjxl wieder integriert. Reintegration ist jedoch nicht dasselbe wie Auslieferung: Im aktuellen Stable-Channel bleibt JXL-Decoding in Chrome standardmäßig deaktiviert und erfordert die manuelle Aktivierung über chrome://flags/#enable-jxl-image-format. Firefox enthält JXL-Code in Nightly hinter der Einstellung image.jxl.enabled, kompiliert ihn jedoch nicht in Release-Builds und hat keinen Auslieferungszeitplan veröffentlicht.

Die Konsequenz für eine Auslieferungsentscheidung — der Punkt, den jeder Referenzartikel andeutet, aber keiner klar ausspricht: Ein JXL-first-<picture>-Element liefert heute rund 85 % Ihrer Nutzer AVIF oder JPEG aus. Sie kodieren und speichern drei Formatvarianten, um JXL an etwa jeden siebten Besucher auszuliefern — und selbst diese Reichweite ist nur Safari-Teilunterstützung. Das sind die tatsächlichen Kosten eines JXL-first-Ansatzes heute, und sie rechnen sich erst, wenn Chrome das Format standardmäßig aktiviert.

Encoding-Aufwand und progressives Rendering

JPEG XL kodiert schneller als AVIF und unterstützt als einziges Format natives progressives Decoding; AVIF-Encoding ist CPU-intensiv und besitzt keinen echten progressiven Modus. Beide Unterschiede sind betrieblich relevant — der eine in Ihrer Build-Pipeline, der andere bei der wahrgenommenen Ladezeit Ihrer Nutzer.

AVIF-Encoding ist der langsame Schritt in den meisten Pipelines

AVIF-Encoding mit dem AV1-Referenz-Encoder (libaom-av1) ist die langsamste Stufe in einer typischen Bild-Pipeline — pro Bild deutlich langsamer als JPEG XL bei vergleichbarer wahrgenommener Qualität. Bei der manuellen Konvertierung eines einzelnen Hero-Images ist das vernachlässigbar. Bei einem CI-Job, der bei jedem Deployment Hunderte von Produktbildern verarbeitet, ist es eine echte Einschränkung: Die Encoding-Zeit skaliert mit der Bildanzahl, und der AV1-Encoder ist konstruktionsbedingt rechenintensiv.

Praktische Gegenmaßnahmen für eine Node.js-Pipeline:

• Verwenden Sie Sharp, das libvips kapselt, für AVIF- und JXL-Encoding. Es bietet quality- und effort-Parameter, mit denen Encoding-Zeit gegen Ausgabegröße abgewogen werden kann.
• Passen Sie die Effort-/Speed-Einstellung an, anstatt den Encoder standardmäßig mit maximaler Stufe zu betreiben — hochstufiges AVIF-Encoding erzeugt marginal kleinere Dateien bei erheblichem Zeitaufwand.
• Parallelisieren Sie über Worker-Threads oder CPU-Kerne, oder verlagern Sie die Konvertierung auf ein CDN, das on-the-fly kodiert, damit der Build-Prozess nie blockiert wird.

const sharp = require("sharp");

// AVIF: niedrigerer `effort`-Wert tauscht etwas Dateigröße gegen deutlich schnelleres CI-Encoding
await sharp("hero.png")
  .avif({ quality: 60, effort: 4 })
  .toFile("hero.avif");

// JXL kodiert bei vergleichbarer Qualität schneller (erfordert einen libjxl-fähigen Build)
await sharp("hero.png")
  .jxl({ quality: 60 })
  .toFile("hero.jxl");

Prüfen Sie die Formatverfügbarkeit Ihrer installierten sharp-Version mit sharp.format — JXL-Unterstützung hängt vom mitgelieferten libvips/libjxl ab und ist nicht in jeder Distribution garantiert.

Progressives Decoding beeinflusst den wahrgenommenen LCP

JPEG XL unterstützt natives progressives Decoding: Der Browser rendert sofort eine Version des Bildes in niedrigerer Qualität und schärft diese nach, während weitere Daten eintreffen. AVIF besitzt keinen echten progressiven Modus, sodass ein großes AVIF-Bild entweder vollständig gerendert wird oder gar nicht. Bei langsamen Verbindungen äußert sich das als sichtbare Largest-Contentful-Paint-Verzögerung — der Hero-Image-Bereich bleibt leer, bis die vollständige Datei angekommen ist.

Diese Klasse von Problemen ist in Session-Replays direkt beobachtbar: Auf bildlastigen Seiten bleibt ein Hero-Image-Bereich bei eingeschränkter Verbindung für die gesamte Dauer eines großen Bild-Downloads leer, wobei der LCP-Zeitstempel auf den Moment fixiert ist, in dem die vollständige Datei schließlich gerendert wird. Das progressive Decoding im JXL-Stil adressiert genau dieses Fehlerbild — ein Bild in niedriger Qualität erscheint früh und schärft sich nach —, was das wahrgenommene Performance-Verhalten ist, das für echte Nutzer in langsamen Netzwerken zählt. Das ist der Grund, warum Payload-Größe und progressives Rendering LCP-Stellhebel sind und keine kosmetischen Präferenzen.

Der Entscheidungsrahmen: Wann Sie welches Format wählen

Setzen Sie AVIF jetzt für die öffentliche Web-Produktion ein, mit WebP- und JPEG-Fallbacks über <picture>. Greifen Sie auf JPEG XL in spezifischen, klar abgegrenzten Fällen zurück: verlustfreie oder Archivierungs-Workflows, nicht-fotografische Bildbibliotheken, Safari-lastige Zielgruppen oder große JPEG-Archive, die Sie ohne Qualitätsverlust rekomprimieren möchten.

Wählen Sie AVIF, wenn:

• Sie eine öffentlich zugängliche Produktionsseite betreiben, die heute eine breite Abdeckung benötigt.
• Ihre Assets überwiegend fotografisch oder gemischt sind.
• Sie ein CMS oder CDN mit nativer Unterstützung verwenden — AVIF ist seit WP 6.5 (April 2024) nativ in WordPress integriert, und große CDNs kodieren es on-the-fly.
• Sie messbare LCP-Verbesserungen gegenüber JPEG/WebP erzielen möchten, ohne eine vierte Formatvariante verwalten zu müssen.

Greifen Sie auf JPEG XL zurück, wenn:

• Sie ein großes JPEG-Archiv pflegen und verlustfreie Rekomprimierung wünschen — konvertieren Sie zu JXL (~20 % kleiner) und stellen Sie Originale byte-genau wieder her.
• Ihre Inhalte überwiegend nicht-fotografisch sind: Illustrationen, Logos, Diagramme, Screenshots.
• Ihre Zielgruppe Safari-lastig ist und Sie das vollständige <picture>-Markup in einem Headless- oder Custom-Setup kontrollieren.
• Sie eine zukunftsorientierte Auslieferung für den Moment aufbauen, in dem Chrome JXL standardmäßig aktiviert.

JPEG XL hat Mitte 2026 keine native WordPress-Upload-Unterstützung, was AVIF als praktische CMS-Wahl weiter bestätigt.

Ein korrektes, aktuelles <picture>-Snippet

In einem <picture>-Element wertet der Browser <source>-Einträge in Dokumentreihenfolge aus und wählt den ersten type, den er unterstützt; fällt keiner durch, greift er auf das <img> zurück. Die Reihenfolge ist daher nicht kosmetisch — sie ist der Auswahlalgorithmus. Listen Sie Formate vom bevorzugten zum am wenigsten bevorzugten auf, und machen Sie den <img>-Fallback zu einem universell unterstützten JPEG, nicht zu WebP (WebP benötigt einen eigenen <source>-Eintrag, da es ein eigenständiger MIME-Typ ist).

<picture>
  <!-- JXL zuerst: wird nur an Safari 17+ ausgeliefert (partial); Chrome Mitte 2026 deaktiviert -->
  <source srcset="hero.jxl" type="image/jxl">
  <!-- AVIF: ~93 % Abdeckung, das Arbeitspferd für nahezu den gesamten Traffic -->
  <source srcset="hero.avif" type="image/avif">
  <!-- WebP: deckt ältere Chrome/Firefox-Versionen ab, die AVIF noch nicht unterstützen -->
  <source srcset="hero.webp" type="image/webp">
  <!-- JPEG: bedingungsloser Fallback; das src, das immer gerendert wird -->
  <img src="hero.jpg" alt="Beschreibung" width="1200" height="630"
       loading="lazy" decoding="async">
</picture>

Die ehrliche Einschätzung dieses vierstufigen Stacks: Heute kostet Sie das vier kodierte Varianten, um JXL an eine Safari-exklusive Minderheit auszuliefern. Wenn Ihre Zielgruppe nicht Safari-lastig ist und Sie keinen Archivierungsgrund für JXL haben, lassen Sie die erste <source> weg und liefern Sie die dreistufige AVIF/WebP/JPEG-Version aus — sie deckt nahezu den gesamten Traffic mit einem Format weniger ab, das gebaut und gespeichert werden muss. Fügen Sie die JXL-Quelle hinzu, wenn — und nicht bevor — Chrome das Flag aktiviert.

Worauf Sie achten sollten, damit sich die Empfehlung ändert

Der praktische Auslöser, JPEG XL zu Ihrem primären Auslieferungsformat zu machen, ist die standardmäßige Aktivierung von chrome://flags/#enable-jxl-image-format in Chrome. Bis das geschieht, hält die Abdeckungsrechnung — rund 15 % JXL (Safari-only, partial) gegenüber ~93 % AVIF — AVIF als einziges vertretbares primäres Format für die öffentliche Web-Produktion. Konkrete Signale, die es zu beobachten gilt:

• Der Chrome Platform Status-Eintrag für JPEG XL wechselt von „flagged” zu „shipped/default-on”.
• Die Vollunterstützungs-Abdeckung auf caniuse.com/jpegxl überschreitet einen nutzbaren Schwellenwert und verliert die partial-Bezeichnung.
• Firefox verschiebt JXL von Nightly in einen Release-Build.
• Große CDNs aktivieren JXL-Konvertierung standardmäßig in ihren Bild-Pipelines.

Sobald das erste dieser Ereignisse eintritt, hört ein JXL-first-<picture>-Stack auf, ein spekulativer Kostenfaktor zu sein, und wird zur Standardempfehlung — und der oben beschriebene Rahmen kehrt sich um.

Fazit

Liefern Sie heute AVIF aus und halten Sie Ihr <picture>-Markup für JPEG XL bereit. AVIF ist das Format, das Ihre Nutzer jetzt erreicht, mit der Tool- und CMS-Unterstützung, die das untermauert; JPEG XL ist technisch das bessere Format und das richtige Werkzeug für verlustfreie Archive und JPEG-Rekomprimierung, aber sein Einsatz im öffentlichen Web hängt vollständig davon ab, dass Chrome es standardmäßig aktiviert. Konvertieren Sie Ihre Assets zu AVIF, fügen Sie WebP- und JPEG-Fallbacks hinzu, und behalten Sie den Chrome-Platform-Status-Eintrag im Blick — der Tag, an dem dieses Flag standardmäßig aktiviert wird, ist der Tag, an dem Sie JXL als Ihre primäre Quelle neu bewerten sollten.

Häufig gestellte Fragen

Verdoppelt die Bereitstellung von AVIF und einer JXL-Quelle im selben picture-Element meinen Speicher- und Bandbreitenverbrauch?

Es erhöht den Speicherbedarf, nicht jedoch die Bandbreite pro Anfrage. Jede Formatvariante, die Sie auflisten, fügt eine kodierte Datei zum Speicher hinzu — ein vierstufiger JXL/AVIF/WebP/JPEG-Stack bedeutet also vier gespeicherte Dateien pro Bild. Die Bandbreite ist davon unberührt, da der Browser nur die erste unterstützte Quelle herunterlädt, die er auswählt, niemals mehrere Varianten gleichzeitig. Die tatsächlichen Kosten eines JXL-first-Stacks sind das zusätzliche Encoding und der Speicher, um eine Safari-exklusive Minderheit zu erreichen — keine doppelten Downloads.

Kann ich meine AVIF-Bilder später ohne erneutes Encoding aus dem Original zu JPEG XL konvertieren?

Nein, nicht ohne Qualitätsverlust. Die verlustfreie Transkodierung von JPEG XL gilt ausschließlich für JPEG-Quellen, nicht für AVIF oder WebP. Ein vorhandenes JPEG lässt sich in JXL einbetten und byte-genau wiederherstellen, aber AVIF und WebP sind verlustbehaftete Formate ohne einen solchen reversiblen Pfad. Die Konvertierung von AVIF zu JXL bedeutet, das bereits komprimierte AVIF zu dekodieren und neu zu kodieren, was Artefakte verstärkt. Bewahren Sie immer Ihre originalen verlustfreien Master auf, damit Sie sauber in jedes Format neu kodieren können.

Warum beeinträchtigt mein AVIF-Hero-Image immer noch den Largest Contentful Paint, obwohl die Datei kleiner als das JPEG ist?

AVIF besitzt kein echtes progressives Decoding, sodass ein großes AVIF-Bild erst gerendert wird, wenn die vollständige Datei angekommen ist — anstatt zunächst eine Vorschau in niedriger Qualität anzuzeigen. Bei einer langsamen Verbindung bleibt der Hero-Bereich für die gesamte Download-Dauer leer, und der LCP-Zeitstempel ist auf den letzten Render-Zeitpunkt fixiert. Eine kleinere Gesamtdateigröße ändert dieses Alles-oder-nichts-Verhalten nicht. Das progressive Decoding von JPEG XL schärft schrittweise nach, was die wahrgenommene Ladezeit auch bei ähnlicher Bytezahl verbessert.

Wählt ein Browser, der sowohl AVIF als auch JPEG XL unterstützt, immer die zuerst aufgelistete Quelle?

Ja. Das picture-Element wählt die erste Quelle, deren type-Attribut der Browser unterstützt — ausgewertet in Dokumentreihenfolge, unabhängig von Dateigröße oder Format-Fähigkeiten. Wenn Sie JXL vor AVIF auflisten, liefert ein Safari-Build, der beides unterstützt, JXL aus; kehren Sie die Reihenfolge um, liefert er AVIF. Der Browser vergleicht weder Qualität noch Gewichtung — die Quellreihenfolge ist der Auswahlmechanismus. Platzieren Sie Ihr bevorzugtes Format zuerst und schließen Sie mit einem universell unterstützten JPEG als img-Fallback ab.