Wonderful. Allow an "unmonitored" extension from a random stranger on the Internet have access to "all data for all websites" just to support an image format for which Mozilla should have long built in native support...
Firefox Nightly v149 has added experimental support via Settings > Firefox Labs:
Webpage Display
Media: JPEG XL
With this feature enabled, Nightly supports the JPEG XL (JXL) format. This is an enhanced image file format that supports lossless transition from traditional JPEG files. See bug 1539075 for more details.
I compare PNG and the four modern formats, AVIF, HEIF, WebP, JPEG XL, on tasks/images that PNG was designed for. (Not on photographs or lossy compression.)
It seems like the natural categories are (1) photographs of real things, (2) line art, (3) illustrator images, (4) text content (eg, from a scanned document).
Is there a reason you used only synthetic images, ie, nothing from group 1?
The motivation behind the benchmarks was to understand what are the options today for optimizing the types of image we use PNG for, so I used the same set of images I had used previously in a comparison of PNG optimizers.
The reason the set does not have photographs: PNG is not good at photographs. It was not designed for that type of image.
Even so, the set could do with a bit more variety, so I want to add a few more images.
One thing I like about JPEG-XL is that it supports all kinds of weird image formats.
For example, I used to work with depth data a lot, which is best expressed as monochrome 16-bit floating point images. Previously, TIFF was the only format that supported this. Many shops would instead save depth images as UINT16 .PNG files, where the raw pixel intensity maps to the camera distance in mm. The problem with this is that pixels more than 65.535 meters away aren't representable. (Hot take: I personally think this is one reason why nobody studies depth estimation for outdoor scenes.)
JPEG-XL supports more weird combinations here, e.g. storing greyscale float32 images (with alpha even! you can store sparse depth maps without needing a separate mask!)
It's like, uniquely suited to these sorts of 3D scene understanding challenges and I really hope people adopt the format for more scientific applications.
> One thing I like about JPEG-XL is that it supports all kinds of weird image formats.
And it is probably the reason why browser vendors disliked it. Lots of complexity, it means a big library, which is high maintenance with a big attack surface. By comparison, webp is "free" if you have webm, as webp is essentially a single frame video.
AFAIK browsers do not reuse any VP8 codepath for WebP, they just use libwebp, which decodes lossy images in software. WebP has a non-VP8 lossless mode too. The concern about image format attack surface is also probably because of the recent exploit in libwebp.
On the subject of tiff, why is it not used more? I mean, it is more or less really a container format right. Why are we not using it all over the place but with modern compression methods?
As just one of innumerable examples, it's the basis for Adobe's DNG raw photo format and many proprietary raw formats used by camera manufacturers (Nikon NEF, Canon CRW and CR2, etc.).
Speaking as an outside observer, the ISO Base Media File Format seems to have more mindshare for newer applications, presumably on account of its broader scope and cleaner design.
Designers might also be hesitant to use an untested file format for print, too.
If there’s a large amount of paper that’s been purchased for a job, I definitely wouldn’t want to be the one who’s responsible for using JPEG XL and – for whatever reason – something going wrong.
Pixels are cheaper than paper or other physical media :)
Yup, Gnome Web loads it just fine! Man, it really is a great browser. I try to switch to it every 6 months, but then I remember that it doesn't support extensions at all. I could give up everything, but not 1Password. Nothing is worth copy/pasting credentials and losing passkeys entirely.
Checking the Firefox bugs on this, it seems they decided to replace the C++ libjxl with a rust version which is a WIP, to address security concerns with the implementation. All this started a few months ago.
Maybe the zen fork is a bit older and still using the C++ one?
... update. after reading the comments in the rust migration security bug, I saw they mentioned "only building in nightly for now"
I grabbed the nightly firefox, flipped the jxl switch, and it does indeed render fine, so I guess the rust implementation is functioning, just not enabled in stable.
... also, I see no evidence that it was ever enabled in the stable builds, even for the C++ version, so I'm guessing Zen just turned it on. Which... is fine, but maybe not very cautious.
Google Chrome is using a Rust implementation. The existence and sufficient maturity of it is the reason they were willing to merge support in the first place.
Flipping `image.jxl.enabled` made it work for me after refreshing the page. I'm using Librewolf 146.0.1-1, but I guess it works just fine in firefox 146
Readit News
There is also an extension for this: https://chromewebstore.google.com/detail/jpeg-xl-viewer/bkhd...
Like this demo page: https://bevara.github.io/Showcase/libjxl/
Deleted Comment
Works great on PaleMoon, one of the earliest browsers to support JPEG XL and "Global Privacy Control" ( https://globalprivacycontrol.org/ ).
https://op111.net/posts/2025/10/png-and-modern-formats-lossl...
I compare PNG and the four modern formats, AVIF, HEIF, WebP, JPEG XL, on tasks/images that PNG was designed for. (Not on photographs or lossy compression.)
Is there a reason you used only synthetic images, ie, nothing from group 1?
The motivation behind the benchmarks was to understand what are the options today for optimizing the types of image we use PNG for, so I used the same set of images I had used previously in a comparison of PNG optimizers.
The reason the set does not have photographs: PNG is not good at photographs. It was not designed for that type of image.
Even so, the set could do with a bit more variety, so I want to add a few more images.
Numbers for decompression speed is one of the two things I want to add.
The other is a few more images, for more variety.
For example, I used to work with depth data a lot, which is best expressed as monochrome 16-bit floating point images. Previously, TIFF was the only format that supported this. Many shops would instead save depth images as UINT16 .PNG files, where the raw pixel intensity maps to the camera distance in mm. The problem with this is that pixels more than 65.535 meters away aren't representable. (Hot take: I personally think this is one reason why nobody studies depth estimation for outdoor scenes.)
JPEG-XL supports more weird combinations here, e.g. storing greyscale float32 images (with alpha even! you can store sparse depth maps without needing a separate mask!)
It's like, uniquely suited to these sorts of 3D scene understanding challenges and I really hope people adopt the format for more scientific applications.
And it is probably the reason why browser vendors disliked it. Lots of complexity, it means a big library, which is high maintenance with a big attack surface. By comparison, webp is "free" if you have webm, as webp is essentially a single frame video.
As just one of innumerable examples, it's the basis for Adobe's DNG raw photo format and many proprietary raw formats used by camera manufacturers (Nikon NEF, Canon CRW and CR2, etc.).
Speaking as an outside observer, the ISO Base Media File Format seems to have more mindshare for newer applications, presumably on account of its broader scope and cleaner design.
Hopefully my photo processor will accept JPEG XL in the near future!
The chrome://flags/#enable-jxl-image-format is not even found in the build :(
Aren't print shops, machining shops, other small manufacturers etc. ones that always lag behind with emerging technologies?
If there’s a large amount of paper that’s been purchased for a job, I definitely wouldn’t want to be the one who’s responsible for using JPEG XL and – for whatever reason – something going wrong.
Pixels are cheaper than paper or other physical media :)
even with `image.jxl.enabled` I don't see it on firefox
Maybe the zen fork is a bit older and still using the C++ one?
I grabbed the nightly firefox, flipped the jxl switch, and it does indeed render fine, so I guess the rust implementation is functioning, just not enabled in stable.
... also, I see no evidence that it was ever enabled in the stable builds, even for the C++ version, so I'm guessing Zen just turned it on. Which... is fine, but maybe not very cautious.
Chromium Has Merged JpegXL
https://news.ycombinator.com/item?id=46597927