Get the top HN stories in your inbox every day.
senfiaj
pkulak
And Firefox: https://addons.mozilla.org/en-US/firefox/addon/jxl/
Santosh83
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...
Vinnl
Security concerns are exactly the reason the format doesn't have native support yet. However: https://github.com/mozilla/standards-positions/pull/1064
mikae1
This...
I would not install non-recommended Firefox addons for things that can be achieved in about:config.
Just do set image.jxl.enabled flag in about:config to true.
undefined
iam-TJ
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.breve
It's a good use case for WebAssembly. For browsers that don't yet support JPEG XL natively the page could provide a wasm decoder.
Like this demo page: https://bevara.github.io/Showcase/libjxl/
undefined
thisislife2
Also checkout - https://jpegxl.info/resources/jpeg-xl-test-page
Works great on PaleMoon, one of the earliest browsers to support JPEG XL and "Global Privacy Control" ( https://globalprivacycontrol.org/ ).
demetris
I published some benchmarks recently:
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.)
tasty_freeze
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?
demetris
Hey, tasty_freeze!
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.
enimodas
Would be nice to also see decompression speed and maybe a photo as a bonus round.
gcr
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.
GuB-42
> 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.
edflsafoiewq
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.
somat
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?
jasomill
It is used quite a bit.
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.
JBorrow
There is also FITS, but that is mainly for astronomical applications (and is in general an insane and terrible format). But it supports tons of types!
p_ing
Orion, and presumably other Webkit-based browsers that are actually up-to-date, can also see the image.
Hopefully my photo processor will accept JPEG XL in the near future!
nine_k
Chromium 143 (the latest available in Void Linux, a rolling-release distro) still can't.
The chrome://flags/#enable-jxl-image-format is not even found in the build :(
RicoElectrico
> Hopefully my photo processor will accept JPEG XL in the near future!
Aren't print shops, machining shops, other small manufacturers etc. ones that always lag behind with emerging technologies?
sanjit
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 :)
p_ing
Yes, because those systems cost gobs of money. You don't replace them just for the hot new thing.
Dylan16807
Replace? Why bring that up?
The company that owns whatever system can and should be able to convert formats.
pkulak
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.
encrypted_bird
Have you tried KeePassXL with SyncThing? I've heard good things about that setup.
Dylan16807
For what purpose? While it's a perfectly good password manager, when used with Gnome Web it also means copy/pasting passwords and losing passkeys. Doesn't it?
numbers
I'm seeing the image on zen which is a firefox fork but not on firefox itself :/
even with `image.jxl.enabled` I don't see it on firefox
capitainenemo
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?
capitainenemo
... 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.
awestroke
zen browser is pretty much vibe coded
bpbp-mango
good. image parsing has produced so many bad RCEs.
dietr1ch
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
rhdunn
Works in ladybird as well.
jiggawatts
Support is not a boolean.
A proper test page should have HDR images, images testing if 10-bit gradients are posterised to 8-bit or displayed smoothly, etc...
iOS for example can show a JPEG XL image, but can't forward it in iMessage to someone else.
MrDrone
There have been a few other test pages posted in the comments with varying degrees of additional context.
https://jpegxl.info/resources/jpeg-xl-test-page https://caniuse.com/jpegxl
mort96
HDR support is an anti-feature. Nobody want a part of a website to suddenly be 10x as bright as pure white.
uyzstvqs
JPEG XL is also good, but why not use AVIF? It's widely supported by browsers, and rivals JPEG XL in being the best lossy image format.
judah
Jake Archibald has an excellent post about progressive image rendering, including some metrics on JPEG XL compared to AVIF[0].
> "I was also surprised to see that, in Safari, JPEG XL takes 150% longer (as in 2.5x) to decode vs an equivalent AVIF. That's 17ms longer on my M4 Pro. Apple hardware tends to be high-end, but this could still be significant. This isn't related to progressive rendering; the decoder is just slow. There's some suggestion that the Apple implementation is running on a single core, so maybe there's room for improvement.
> JPEG XL support in Safari actually comes from the underlying OS rather than the browser. My guess is that Apple is considering using JPEG XL for iPhone photo storage rather than HEIC, and JPEG XL's inclusion in the browser is a bit of an afterthought. I'm just guessing though.
> The implementation that was in Chromium behind a flag did support progressive rendering to some degree, but it didn't render anything until ~60 kB (39% of the file). The rendering is similar to the initial JPEG rendering above, but takes much more image data to get there. This is a weakness in the decoder rather than the format itself. I'll dive into what JPEG XL is capable of shortly.
> I also tested the performance of the old behind-a-flag Chromium JPEG XL decoder, and it's over 500% slower (6x) to decode than AVIF. The old behind-a-flag Firefox JPEG XL decoder is about as slow as the Safari decoder. It's not fair to judge the performance of experimental unreleased things, but I was kinda hoping one of these would suggest that the Safari implementation was an outlier.
> I thought that "fast decoding" was one of the selling points of JPEG XL over AVIF, but now I'm not so sure.
> We have a Rust implementation of JPEG XL underway in Firefox, but performance needs to get a lot better before we can land it."
[0]: https://jakearchibald.com/2025/present-and-future-of-progres...
jomohke
Strange, as Cloudinary's test had the opposite conclusion -- jpegxl was significantly faster to decode than avif. Did the decoders change rapidly in a year, or was it a switch to new ones (the rust reimplementation)?
https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front
If decode speed is an issue, it's notable that avif varied a lot depending on encode settings in their test:
> Interestingly, the decode speed of AVIF depends on how the image was encoded: it is faster when using the faster-but-slightly-worse multi-tile encoding, slower when using the default single-tile encoding.
N19PEDL2
>> My guess is that Apple is considering using JPEG XL for iPhone photo storage rather than HEIC, and JPEG XL's inclusion in the browser is a bit of an afterthought.
This would be great.
quentindanjou
I am curious, isn't AVIF also taking advantage of the hardware decoding democratized by AV1?
michaelt
Taking advantage of hardware decoding is generally like pulling teeth.
For video you can't avoid it, as people expect several hours of laptop battery life while playing video. But for static images - I'd avoid the pain.
F3nd0
Because JPEG XL is the first format to actually bring significant improvements across the board. In some aspects AVIF comes close, in others it falls far behind, and in some it can’t even compete. There’s just nothing else like JPEG XL and I think it deserves to be supported everywhere as a truly universal image codec.
Socket-232
Why use AVIF when JPEG XL is much better and in a few weeks almost universally supported?
dlcarrier
Are there any up-to-date WebKit browsers for Android? The best I could find was Lightning, but it hasn't been updated in years.
Edit: I found A Lightning fork called Fulguris. It didn't work with the JPEG XL test image, but I really like the features and customizability. It's now my default browser on Android.
zamadatix
The closest thing I know of is Igalia has a project trying to port https://wpewebkit.org/ to Android https://github.com/Igalia/wpe-android and they have a minibrowser example apk in the releases of the current state (but I wouldn't call it a Chrome drop in replacement or anything at the moment - just the closest thing I know on Android).
TingPing
WPE can be built for Android, but it’s not a user facing browser.
cubefox
According to CanIUse, no browser implementation currently supports progressive decoding [1]. This is unfortunate, since progressive decoding theoretically is a major advantage of JPEG XL over AVIF, which doesn't allow it in principle, even though ordinary JPEG allows it. But apparently even a default (non-progressive) JPEG XL allows some limited form of progressive decoding [2]. It's unclear whether browsers support it though.
Get the top HN stories in your inbox every day.
Starting from v145 Chrome supports JXL.
There is also an extension for this: https://chromewebstore.google.com/detail/jpeg-xl-viewer/bkhd...