Years ago, both Chrome and Firefox had experimental support. In October 2022, Chrome suddenly announced their decision to drop it (citing dubious reasons like lack of interest or improvements over existing formats). [1] It was only later, in January 2023, that Mozilla announced their formal position of not really caring about the format. [2]

In October 2023, one of the JPEG XL devs said that the responsible team at Google was ready to write a decoder in Rust if that was the only reason holding adoption back, even offering to work on browser integration. [3] One month later, another dev confirmed that a different pre-existing decoder written in Rust was already standard-conformant. [4]

It wasn’t until September 2024, nearly a whole year later, that Mozilla changed their official position from not caring to waiting for a suitable decoder written in Rust. [5] And it was only then that jxl-rs development really picked up. [6] Only later on, Chrome decided to change their position as well, but we can only speculate on what actually changed their mind.

There was no Google shoving JPEG XL down everyone’s throat like they once did with WebP. There was no Mozilla taking a clear, principled stance from the get-go. Whether or not JPEG XL was worth it, neither of these companies has acted in a transparently fair, exemplary way. And of course the first major browser to ship JPEG XL support to users was Safari, which may well have played a role in the others’ decision-making.

  [1]: https://issues.chromium.org/issues/40168998#comment85
  [2]: https://github.com/mozilla/standards-positions/issues/522#issuecomment-1409539985
  [3]: https://github.com/web-platform-tests/interop/issues/430#issuecomment-1776762287
  [4]: https://github.com/web-platform-tests/interop/issues/430#issuecomment-1811972676
  [5]: https://github.com/mozilla/standards-positions/pull/1064
  [6]: https://github.com/libjxl/jxl-rs/graphs/contributors?from=03%2F01%2F2024&to=01%2F01%2F2026