2017: Zwei Codecs auf der Suche nach einem Standard

Die Geschichte von JPEG XL beginnt mit zwei parallel laufenden Forschungs-Projekten. Bei Google Research Zürich arbeitete eine Gruppe um Jyrki Alakuijala (denselben Ingenieur, der schon WebP-Lossless mitentwickelt hatte; siehe WebP-Geschichte) seit 2014 an einem Codec mit Arbeitsnamen PIK. Bei Cloudinary in Tel Aviv entwickelte Jon Sneyers parallel FUIF (Free Universal Image Format), gestützt auf einen anderen mathematischen Ansatz — auf MA-Trees und prädiktiver Wavelet-Codierung.

Beide Codecs hatten gleiche Ziele: besser als JPEG, lizenz-frei, fähig zur verlustfreien Neu-Komprimierung existierender JPEGs. 2017 schrieb das JPEG-Komitee einen offenen Wettbewerb für ein „Next-Generation Image Coding" aus. PIK und FUIF erreichten die Endrunde — und die Komitee-Mitglieder erkannten, dass beide Codecs komplementäre Stärken hatten. Statt einer zu wählen, schlossen die Teams einen ungewöhnlichen Kompromiss: Fusion.

2018–2021: JPEG XL entsteht

Aus PIK und FUIF wurde ein gemeinsamer Codec, der von Google, Cloudinary und einer breiteren akademischen Community weiterentwickelt wurde. Federführend waren Jyrki Alakuijala, Jon Sneyers, Luca Versari, Sami Boukortt und Iulia-Maria Comşa. Die Spezifikation wurde im Oktober 2018 als JPEG-Komitee-Arbeitsdokument freigegeben, im Januar 2021 als ISO/IEC 18181-1 ratifiziert und im März 2022 mit Teil 2 (Datei-Format und Coding-Tools) ergänzt.

Die technischen Vorteile waren beeindruckend. JPEG XL bringt mehrere strukturelle Eigenschaften mit, die keiner der etablierten Konkurrenten hat:

  • Verlustfreie JPEG-Re-Komprimierung. Existierende JPGs lassen sich in JPEG XL umwandeln und werden dabei typisch 20 % kleiner — ohne dass sich ein einziger Pixel ändert. Das macht JPEG XL ideal für Foto-Archive, die JPGs ohne Qualitätsverlust verkleinern wollen.
  • Progressives Laden. Wie das klassische JPEG-Progressive, aber feiner gesteuert: das Bild kommt zunächst als grobe Vorschau an und verfeinert sich Schritt für Schritt — gut für mobile Browser bei langsamen Verbindungen.
  • HDR und Wide Color Gamut. 32-Bit-Float-Pipeline, BT.2020, HDR10+ — alles, was moderne Display-Pipelines fordern.
  • Modular für verlustlos und Lossy. Ein einziger Codec deckt beides ab, statt zwei verschiedene Pipelines wie bei WebP.

2021: Browser-Adoption beginnt

Im April 2021 implementierte Chrome 91 eine experimentelle JPEG-XL-Unterstützung hinter einem Feature-Flag. Firefox folgte mit einem ähnlichen Flag in Version 90. Adobe brachte JPEG XL in DNG-Workflows (für RAW-Foto-Archivierung). Cloudinary und Imgix lieferten serverseitige JPEG-XL-Konvertierung im Bild-Pipeline-Layer. 2021 sah danach aus, als würde JPEG XL der nächste große Web-Standard.

Dann kam die Wendung.

Oktober 2022: Google zieht den Stecker

Am 31. Oktober 2022 kündigte das Chrome-Team an, die JPEG-XL-Unterstützung in Chrome 110 zu entfernen. Die offizielle Begründung: „nicht genügend Interesse aus der Ökosystem- Community", und „die inkrementellen Vorteile rechtfertigen nicht den Wartungsaufwand". Die Web-Community reagierte mit Erstaunen und Wut. Auf dem Chromium-Issue-Tracker häuften sich mehrere tausend Kommentare; Cloudinary, Facebook, Adobe und die JPEG-Komitee- Mitglieder veröffentlichten öffentliche Stellungnahmen für JPEG XL.

Der Verdacht in der Community: Google bevorzugte AVIF (siehe unsere AVIF-Geschichte), an dessen Entwicklung Google federführend beteiligt war. JPEG XL war Cloudinary's Steckenpferd; Google wollte das eigene Format stärken. Die Verschwörungs-Theorie ist nicht beweisbar, aber die Timing-Korrelation ist auffällig.

Im Januar 2023 entfernte Chrome 110 die JPEG-XL-Unterstützung vollständig. Auch Firefox stoppte seine Implementierung. JPEG XL war im Web damit faktisch tot — obwohl die ISO-Spezifikation lebte.

2023: Apple greift ein

Während Google sich von JPEG XL abwendete, ging Apple den entgegengesetzten Weg. Im Juni 2023 kündigte Apple auf der WWDC an, dass macOS Sonoma und iOS 17 JPEG XL nativ unterstützen würden — Safari, Photos, Quick Look, Finder. Im September 2023 wurde das Versprechen eingelöst.

Damit war eine paradoxe Situation entstanden: Safari unterstützte JPEG XL, Chrome nicht. Web-Entwickler, die JPEG XL ausliefern wollten, mussten dasselbe<picture>-Pattern fahren wie damals bei WebP — JPEG XL für Safari, AVIF oder JPG für die anderen Browser.

2025: Die Rückkehr

Im Januar 2025 änderte Google die Entscheidung. Chrome 132 brachte JPEG XL hinter einem Origin-Trial-Flag zurück, Chrome 135 (Mai 2025) als reguläre Funktion. Die offizielle Begründung: „signifikantes Interesse von Foto-Archivierungs-Anwendungen, professioneller Bildbearbeitung und JPEG-Migrations-Workflows". Firefox folgte im Juli 2025. Damit war JPEG XL nach drei Jahren wieder in allen Mainstream-Browsern angekommen.

Die Rückkehr war kein vollständiger Sieg. Chrome behandelt JPEG XL weiterhin als „spezielle Verwendung" — gut für Foto-Archive und JPEG-Migration, aber kein Default-Web-Format. Die Frage, ob JPEG XL AVIF langfristig verdrängen kann, ist 2026 offen.

Wann JPEG XL die richtige Wahl ist

  • JPEG-Migrationen. Existierende JPG-Archive verlustlos um 20 % verkleinern, ohne Pixel zu verändern — ein echter Killer-Use-Case ohne Konkurrenz.
  • Professionelle Foto-Workflows. 32-Bit-Float-Pipeline, breiter Farbraum, HDR — Foto-RAW-Archivierung profitiert messbar.
  • Progressives Laden auf mobilen Verbindungen. Die feinere Granularität beim Streaming ist in 4G/5G-Edge-Netzen spürbar.
  • Apple-Plattform-Native Apps. Photos, Quick Look, Finder nutzen JPEG XL inzwischen für eigene Pipelines — siehe auch unseren HEIC-Beitrag.

Wann JPEG XL nicht ideal ist: clientseitiges Encoding im Browser (kein nativer Encoder verfügbar), maximale Web-Reach (AVIF hat höhere Browser-Coverage), Druck-Workflows (Druckereien akzeptieren bisher kein JPEG XL).

Die offene Frage 2026

JPEG XL ist eines der wenigen Formate der jüngeren Geschichte, dessen Schicksal noch nicht entschieden ist. Es hat strukturelle Vorteile gegenüber AVIF (verlustfreie JPG-Migration, bessere Foto-Komprimierung), aber AVIF hat Network-Effekte (frühere Adoption, breitere Tool-Unterstützung, AOMedia-Lobby). Die nächsten Jahre werden zeigen, ob das Web-Ökosystem zwei moderne Formate parallel pflegt oder ob eines das andere verdrängt. Eine ehrliche Gegenüberstellung der drei modernen Konkurrenten findest du in unserem Formate-Vergleich.

Quellen

JPEG XL Community-Portal · ISO/IEC 18181-1 — JPEG XL Core Coding System · libjxl-Quellcode · Chromium-Issue 1178058 — JPEG XL Diskussion · Apple Image I/O Framework · Cloudinary — JPEG XL Pareto Front · Sneyers, J. & Alakuijala, J., „JPEG XL Next-Generation Image Compression", ICIP 2019.