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
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.
zen browser is pretty much vibe coded
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!
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 :(
> 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?
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 :)
Yes, because those systems cost gobs of money. You don't replace them just for the hot new thing.
Presumably the "January 2027" statement is a typo, ...or is that when it is slated to launch in safari?
yeah, it's a typo :-)
Looks like the sort of person that would create a superior image file format.
Works with Waterfox on macOS but curiously not Firefox. I wonder if their search deal with Google included keeping the image.jxl.enabled setting off.
That’s an interesting speculation, but I’m inclined to believe their official reasoning. (That being they just didn’t really care about the format and/or went with whatever Chrome said at first. A year or so later they changed their mind and said they wanted an implementation in a memory-safe language, which prompted the JXL team to work on it.)
Works on Zen as well.
I enabled image.jxl.enabled in LibreWolf and works. It doesn't work in Firefox Beta, though?
There's a jpeg xl viewer extension available for firefox.
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.
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."
I am curious, isn't AVIF also taking advantage of the hardware decoding democratized by AV1?
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.
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.
Why use AVIF when JPEG XL is much better and in a few weeks almost universally supported?
Works in ladybird as well.
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.
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).
WPE can be built for Android, but it’s not a user facing browser.
> this means only Safari will display the image, as far as I know.
Which makes sense as Orion uses the same engine as Safari.
If I download the image, Fedora KDE shows it properly in Dolphin and Gwenview.
Epiphany (aka Gnome Web) on Linux shows this correctly, as expected for a Webkit-based browser.
On Waterfox. Image displays fine.
A rare win for gnome web over firefox here
I think JPEG XL's naming was unfortunate. People want to associate new image formats with leanness, lightness, efficiency.
There was a constraint - since 2009, the Joint Photographic Experts Group had published JPEG XR, JPEG XT and JPEG XS, and they were probably reluctant to break that naming scheme.
They're running out of good options, but I hope they stick with it long enough to release "JPEG XP" :-)
JPEG XP would have been a nice name for a successor of JPEG 2000, I suppose :)
In the photography world it's shorthand for "photo unedited straight from the camera". Popular with Fujifilm cameras especially due to their 'film simulation' modes which apply basically a filter to the image.
Not really? Unedited would be some sort of raw. JPEG usually implies preprocessed by the camera
I guess I meant unedited by the photographer manually (e.g. using Lightroom etc.)
Either that or a photo that has been edited from a RAW and is a final version to be posted online.
I feel like you need to find better places on the internet. It's no longer 1997 downloading from dial up.
What makes jpeg compression bad isn’t low bandwidth. It’s really good at compressing an image for that.
What makes jpeg bad is that the compression artifacts multiply when a jpeg gets screen captured and then re-encoded as a jpeg, or automatically resized and recompressed by a social media platform. And that definitely isn’t a problem that has gone away since dialup, people do that more than ever.
Excess?!? I certainly don't want any of that in my image encoding formats!
Exactly. Image compression should excel at avoiding excess.
Though maybe some people think the JPEG committee is now creating spreadsheet formats...
It seems to me this point of discussion always tends to get way too much focus. Should it really raise concern?
Of all the people who interact with image formats in some way, how many do even know what an image format is? How many even notice they’ve got different names? How many even give them any consideration? And out of those, how many are immediately going to think JPEG XL must be big, heavy and inefficient? And out of those, how many are going to stop there without considering that maybe the new image format could actually be pretty good? Sure, there might be some, but I really don’t think it’s a fraction of a significant size.
Moreover, how many people in said fraction are going to remember the name (and thus perhaps the format) far more easily by remembering it’s got such a stupid name?
I found it unfortunate because it's not a JPEG.
It has an operation mode where it can losslessly and reversibly compress a JPEG further, and "not a jpeg" wouldn't cover that.
JPEG XL is the thing that makes your JPEG smaller?
JPEG XL is basically 4 codecs in one...
* A new lossy image Codec
* A lossless image codec (lossless modular mode)
* An alternative lossy image codec with different kinds of compression artifacts than those typically seen in JPEG (lossy modular mode)
* JPEG packer
Because it includes a JPEG packer, you can use it as such.
Crappy as a .jpg, only bigger.
Actually, I remember when JPEG XL came out, and I just thought: cool, file that one away for when I have a really big image I need to display. Which turned out to be never.
Names have consequences.
> Crappy as a .jpg, only bigger.
Honestly, that's exactly what it sounds like to me too. I know it's not, but it's still what it sounds like. And it's just way too many letters total. When we have "giff" and "ping" as one-syllable names, "jay-peg-ex-ell" is unfortunate.
Really should have been an entirely new name, rather than extending what is already an ugly acronym.
I’ll never not say pee-en-gee. You’re right though.
I always have called it PNG pee-en-ji, and JPEG XL for me has p much all the time been jay-x-el.
Just call it JXL.
Pronounced jixel?
Pronounced like French « j’excelle » (I excel).
(Kidding.)
Kidding? But I actually kinda like it!
Yes, and JAY EXCEL for the savages like me
And yet WEBP decided to associate itself with urine, which google then forced on everyone using their monopoly power.
JPEG 15 Pro Max
μJPEG
Nobody can keep you from forking the spec and calling yours JPEG SM.
Alright, that image made be really miss Lenna as an example image.
I understand why people avoid it now; however, having not seen the uncropped version for a long time initially, I have only warm associations.
[deleted]
On zen. It works.
[deleted]
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.
While I get why, it bugs me that they have comparison images between jxl and other formats, yet it doesn't actually use jxl, as evidenced by all images displaying correctly on my chrome browser.
It uses jxl if the browser supports it, using <picture>¹.
Starting from v145 Chrome supports JXL.
There is also an extension for this: https://chromewebstore.google.com/detail/jpeg-xl-viewer/bkhd...
And Firefox: https://addons.mozilla.org/en-US/firefox/addon/jxl/
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
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.
zen browser is pretty much vibe coded
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!
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 :(
> 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?
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 :)
Yes, because those systems cost gobs of money. You don't replace them just for the hot new thing.
Presumably the "January 2027" statement is a typo, ...or is that when it is slated to launch in safari?
yeah, it's a typo :-)
Looks like the sort of person that would create a superior image file format.
Works with Waterfox on macOS but curiously not Firefox. I wonder if their search deal with Google included keeping the image.jxl.enabled setting off.
That’s an interesting speculation, but I’m inclined to believe their official reasoning. (That being they just didn’t really care about the format and/or went with whatever Chrome said at first. A year or so later they changed their mind and said they wanted an implementation in a memory-safe language, which prompted the JXL team to work on it.)
Works on Zen as well.
I enabled image.jxl.enabled in LibreWolf and works. It doesn't work in Firefox Beta, though?
There's a jpeg xl viewer extension available for firefox.
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.
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...
I am curious, isn't AVIF also taking advantage of the hardware decoding democratized by AV1?
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.
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.
Why use AVIF when JPEG XL is much better and in a few weeks almost universally supported?
Works in ladybird as well.
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.
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).
WPE can be built for Android, but it’s not a user facing browser.
> this means only Safari will display the image, as far as I know.
Works fine for me in Orion on both desktop and mobile ( https://orionbrowser.com ).
Which makes sense as Orion uses the same engine as Safari.
If I download the image, Fedora KDE shows it properly in Dolphin and Gwenview.
Epiphany (aka Gnome Web) on Linux shows this correctly, as expected for a Webkit-based browser.
On Waterfox. Image displays fine.
A rare win for gnome web over firefox here
I think JPEG XL's naming was unfortunate. People want to associate new image formats with leanness, lightness, efficiency.
There was a constraint - since 2009, the Joint Photographic Experts Group had published JPEG XR, JPEG XT and JPEG XS, and they were probably reluctant to break that naming scheme.
They're running out of good options, but I hope they stick with it long enough to release "JPEG XP" :-)
JPEG XP would have been a nice name for a successor of JPEG 2000, I suppose :)
There's also a JPEG XE now (https://jpeg.org/jpegxe/index.html), by the way.
Incidentally, JPEG Vista would be thematically appropriate.
JPEG ME
Good one - made me and a coworker both LOL (in the literal sense) :D
Considering "jpeg" has become the shorthand for "digital picture", it would be a shame not to capitalise on it.
I feel like "jpeg" has generally become a shorthand for "low quality compressed digital picture"
Hence the meme response "Needs more jpeg" https://old.reddit.com/r/explainlikeimfive/comments/2ct3ax/e...
In the photography world it's shorthand for "photo unedited straight from the camera". Popular with Fujifilm cameras especially due to their 'film simulation' modes which apply basically a filter to the image.
Not really? Unedited would be some sort of raw. JPEG usually implies preprocessed by the camera
I guess I meant unedited by the photographer manually (e.g. using Lightroom etc.)
Either that or a photo that has been edited from a RAW and is a final version to be posted online.
I feel like you need to find better places on the internet. It's no longer 1997 downloading from dial up.
What makes jpeg compression bad isn’t low bandwidth. It’s really good at compressing an image for that.
What makes jpeg bad is that the compression artifacts multiply when a jpeg gets screen captured and then re-encoded as a jpeg, or automatically resized and recompressed by a social media platform. And that definitely isn’t a problem that has gone away since dialup, people do that more than ever.
"diJital PEGchure"
Is it pronounced jay-peg or gee-peg?
Nah, that's WEBP, the most hated file format.
JPEG XS :D
https://en.wikipedia.org/wiki/JPEG_XS
Excess?!? I certainly don't want any of that in my image encoding formats!
Exactly. Image compression should excel at avoiding excess.
Though maybe some people think the JPEG committee is now creating spreadsheet formats...
It seems to me this point of discussion always tends to get way too much focus. Should it really raise concern?
Of all the people who interact with image formats in some way, how many do even know what an image format is? How many even notice they’ve got different names? How many even give them any consideration? And out of those, how many are immediately going to think JPEG XL must be big, heavy and inefficient? And out of those, how many are going to stop there without considering that maybe the new image format could actually be pretty good? Sure, there might be some, but I really don’t think it’s a fraction of a significant size.
Moreover, how many people in said fraction are going to remember the name (and thus perhaps the format) far more easily by remembering it’s got such a stupid name?
I found it unfortunate because it's not a JPEG.
It has an operation mode where it can losslessly and reversibly compress a JPEG further, and "not a jpeg" wouldn't cover that.
JPEG XL is the thing that makes your JPEG smaller?
JPEG XL is basically 4 codecs in one...
* A new lossy image Codec
* A lossless image codec (lossless modular mode)
* An alternative lossy image codec with different kinds of compression artifacts than those typically seen in JPEG (lossy modular mode)
* JPEG packer
Because it includes a JPEG packer, you can use it as such.
Crappy as a .jpg, only bigger.
Actually, I remember when JPEG XL came out, and I just thought: cool, file that one away for when I have a really big image I need to display. Which turned out to be never.
Names have consequences.
> Crappy as a .jpg, only bigger.
Honestly, that's exactly what it sounds like to me too. I know it's not, but it's still what it sounds like. And it's just way too many letters total. When we have "giff" and "ping" as one-syllable names, "jay-peg-ex-ell" is unfortunate.
Really should have been an entirely new name, rather than extending what is already an ugly acronym.
I’ll never not say pee-en-gee. You’re right though.
I always have called it PNG pee-en-ji, and JPEG XL for me has p much all the time been jay-x-el.
Just call it JXL.
Pronounced jixel?
Pronounced like French « j’excelle » (I excel).
(Kidding.)
Kidding? But I actually kinda like it!
Yes, and JAY EXCEL for the savages like me
And yet WEBP decided to associate itself with urine, which google then forced on everyone using their monopoly power.
JPEG 15 Pro Max
μJPEG
Nobody can keep you from forking the spec and calling yours JPEG SM.
> Nobody can keep you from forking the spec
ISO: "Challenge accepted." [1]
[1] https://www.iso.org/standard/85066.html
Shouldn't that be JPEG℠ vs JPEG™?
Do you have anything to back this up?
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.
Works on FireFox Focus on mobile, FWIW. (Latest iOS)
That’s because it uses the WebKit renderer built in to iOS
Cannot see it with lockdown mode iOS
Related:
Chromium Has Merged JpegXL
https://news.ycombinator.com/item?id=46597927
I can see the image just fine on Thorium!
Alright, that image made be really miss Lenna as an example image.
I understand why people avoid it now; however, having not seen the uncropped version for a long time initially, I have only warm associations.
On zen. It works.
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.
1: https://caniuse.com/jpegxl
2: https://youtube.com/watch?v=inQxEBn831w
Works in Waterfox (6.6.8)
Yep, doesnt work on firefox or chrome.
Works in Zen 1.17.15b (aka Firefox 146.0.1) on Linux.
Same for me, Zen 1.17.15b on Mac
Same I am using Zen 1.17.15b on Mac too and it works for me too
Working fine on Firefox for me
Firefox version 146.0.1 on Windows 11
https://caniuse.com/jpegxl
I have the flag enabled but it's still broken in FF, needs to be a nightly build to work
Same here, doesn't work, FF 148.0b5
Honestly I was hoping for a page showing off more of jpeg xl features rather than just a single image
You probably want the JPEG XL Info[1] site then. A nice site outlining what JPEG XL actually is.
[1] https://jpegxl.info/
While I get why, it bugs me that they have comparison images between jxl and other formats, yet it doesn't actually use jxl, as evidenced by all images displaying correctly on my chrome browser.
It uses jxl if the browser supports it, using <picture>¹.
¹ https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
Looks like it works in Brave
Weird, doesn't work in Brave (macOS) for me. Did you enable a setting? Brave says it's up to date when I check.
Doesn't work for me on Brave on Android