upvote
Obviously, once the Google overlords decided it.
reply
No, the reverse. Mozilla opposed Google's original attempt to push JPEG XL years ago, and declined to ship without an implementation that they could confidently say was safe. See https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/ :

"We added experimental support for JPEG XL behind a flag back in 2021. But, at 100,000 lines of multithreaded C++, we were concerned about the attack surface this added to Firefox. So, we laid down a challenge to the JPEG XL team at Google Research: Build a safe, performant, compact, and compatible JPEG XL decoder in Rust, and we’ll ship it. That challenge was met; Google Research built jxl-rs, and it’s the core of our JPEG XL support in Firefox."

reply
That’s not at all how it went.

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
reply
All of this reinforces my point, which is that Mozilla is not simply following marching orders handed down by "the Google overlords".
reply
Firefox did not take very long to support AVIF (another recent image format clearly favoured by Google). Please do correct me if I’m wrong, but I’m not aware of Mozilla expressing any reluctance over AVIF’s abysmal lossless performance or other shortcomings (some of which have been addressed since), or insisting on using a memory-safe decoder like they have for JPEG XL. Why the stark difference in treatment?

We may not be able to say for certain, but Google’s massive influence is by far the most plausible explanation I can think of. And if the first step in your decision making is looking at what Google is doing, then ‘following marching orders’ is suddenly not such a bad description. (One can argue that with 3 % market share they don’t have much choice, but that’s beside the point.)

reply
[2] was anticipatory obedience from Mozilla. Good for them that they grew a spine later (or more likely: they knew that Google will implement it some time later, so the change of opinion cost them nothing).
reply