With both Firefox and Chromium using jxl-rs (Rust-based), I wonder what Apple will do about the libjxl (C++) they already shipped. I know they're doing some memory-safety with Swift, but are they shipping any Rust in their platforms so far? I also wonder if anyone's done benchmark comparisons between both libs.
--
Also, I was under the impression that after backtracking, Chromium was relying on Mozilla to come up with a Rust port, but it seems it was the reverse. Good on Google Research.
> 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.
Luca Versari, one of the devs between both libraries, has a performance dashboard to compare performance between the two
https://jxl-rs-perf.lucaversari.it/
jxl-rs started to outperform the C++ library 2 months ago.
As much as I enjoy rust, there is no reason why a c++ library can’t be optimised to match the rust implementation.
It’s very rare that the actual performance benefits of rust implementations come from rust itself (though it does often push you to slightly better patterns). They usually come from the fact that rust implementations are usually a second (or 3rd, or 4th) iteration of the design, and the lessons learned help performance.
The other benefit of rust is that the stronger type system makes it easier to iterate and optimise without bugs creeping in. But once optimisations are implemented in rust, there isn’t that much pain to porting them back to c++, as long as someone cares enough to do so.
>As much as I enjoy rust, there is no reason why a c++ library can’t be optimised to match the rust implementation
but why would you bother? The rust library is the one that is being chosen to use. There is no point optimizing a library which is not going to be used.
> As much as I enjoy rust, there is no reason why a c++ library can’t be optimised to match the rust implementation.
I don't think anyone is claiming that. I took the GP's point as what was desired was a "safe, performant, compact, and compatible JPEG XL decoder in Rust" and "performant" (as defined as the speed of the c++ version) was passed two months ago.
> They usually come from the fact that rust implementations are usually a second (or 3rd, or 4th) iteration of the design, and the lessons learned help performance.
Sure, and looking at the recent commit histories, the team is focusing on getting the rust version ready for this milestone for obvious reasons, and is less concerned about immediate parity in the c++ codebase.
I suspect the real reason is safety. Rust isn't bulletproof but it's certainly much better than C++ when it comes to defending against memory corruption related attacks. And when you are building a decoder for untrusted data sent over the internet, this kind of thing matters a lot more.
If he is one of the devs between both libraries, why is there a performance gap? Why not port the optimizations from one lib to the other? You can even create a pinned agent workflow that automatically translates optimizations between repos. Fairly trivial to implement actually.
Just because you can theoretically write equivalent code in both languages doesn't mean two idiomatic implementations in each language will be 1:1 with each other. I haven't looked at the code in question, but some examples of common differences:
A C++ program might do template metaprogramming at compile time and the same thing at runtime in Rust, or vice versa. The C++ version might use virtual functions that rust wouldn't use. The Rust version might simply give more optimization information to the backend. The C++ version might use fairly awful parts of the stdlib like iostreams or shared_ptr that rust simply implements better. Etc.
Or maybe they're just focused on the rust implementation as they should be.
JXL was dead. Apple is who brought it back to life[1], and the only reason Chrome resurrected JXL, and now Firefox followed their path, is because Apple pushed JXL support to a billion plus devices.
I know people like complaining about Apple, but there's a "read the room" kind of moment where people just seem to either not know the context or are just knee jerking.
[1] Worth noting that Apple used the reference implementation, libjxl, and that project still remains the reference implementation with the Rust port being experimental (and of course Apple deployed JXL support over a year before the Rust port even existed). Maybe they'll switch to it at some point, but it's a bit premature to complain about.
I believe Firefox was the first to put out a standards position about adopting jxl if a Rust implementation happened. Chromium only aligned their position this year I believe, prior to that, it was a complete rejection.
Which is to say, Chrome followed Firefox here.
(Yes, I know Google Research implemented jxl-rs, but then, they also implemented jxl. Chrome’s position appears independent of them.)
I'm not one to usually defend Apple-ism, but it always felt that this was such a nothing-burger. The mouse charges in like fifteen minutes and lasts for weeks. I don't have a work Macbook (or job :) ) right now, but when I did I would just occasionally plug it in while I went to the bathroom. It really was not nearly as annoying as everyone said it was.
Their point is that Apple is the Nintendo of computing. They don't care what others do, they just do their own thing. Which produces some great things and some stupid things. They also don't care whether you think what they are doing is great or stupid, they just continue doing their thing
Which then tracks back to the beginning of the thread: the correct answer to whether apple will adopt jxl-rs or keep libjxl is "who knows, no point trying to predict them". Which is not a value judgement
How you square all of that with the iPhone regularly copying features Android had for years is your decision. Might be a symptom of the same, might be that this all was an entirely inaccurate description of Apple
And their Safari browser is the worst. It doesn’t properly support PWAs or many other features because they want to maintain tight control over their App Store.
Maybe because they don't want to see this thread dragged down into an open-ended gripe-fest against Apple, especially when it's concerning a feature Apple did ship before everyone else.
And Apple including support in their default graphics library so every iOS (and Mac) supported it. (I use Firefox, but let's not pretend like they'd move the market on JXL support.)
Now I'd only wish browsers could come up with more convenient ways to get around when some websites and upload fields don't support jxl or some other image format, and would either do something about it automatically or offer some option to get around it (convert to jpeg or png and upload, or 'paste as an image' which would pretty much be the same as png conversion, or something)
It compresses better than webp*, has really good progressive decoding (current encoders are able to encode the image such that the most important part of the image gets decoded first, and you only need the first ~20% of the image to display it as a thumbnail), and it's also a very flexible format (unlike avif) since it can also display lossless files* and display much larger images than AVIF can.
Also the compatibility with existing JPEG files that was mentioned below, unlike other formats you can losslessly convert a JPEG into a JXL without losing quality but saving file size in the process.
* it actually has better compression than PNG for this
avif also supports lossless, but it's so inefficient it might as well not exist.
Lossless webp is a completely different image format compared to lossy webp, even though they come under the same file extension. Unlike lossy webp, it's a good image format that has excellent compression ratio compared to png. I've often been using it for screenshots to avoid damaging text clarity and still maintain acceptable file size.
jxl has excellent support for both lossy and lossless cases, and can replace both lossy avif (even if somewhat less efficient at low file sizes), and lossless webp.
Note also that converting jpeg to jxl is 100% reversible, you can convert it back to exactly the same image (byte for byte identical) if you need to.
>Note also that converting jpeg to jxl is 100% reversible, you can convert it back to exactly the same image (byte for byte identical) if you need to.
Speaking as someone who loves JXL, I have a serious question: I once used ImageMagick to convert a JPG to a JXL, and then back to JPG, and the final JPG was a noticeably different file size compared to the source JPG.
JPEG to JXL transcoding and JXL to JPEG reconstruction are different from converting an image in either direction, it's gonna be a specific option (in something like xl-converter), so maybe it wasn't what was used and it was just a "reencode" into jxl and then into jpeg.
It probably used pixel-by-pixel conversion (decode input format -> encode output format), which is lossy, not the libjxl native way to convert JPEG (it needs to know about the original JPEG data, not the raw image data).
> [JPEG XL can] display much larger images than AVIF can
Does it do tiles? What about pyramids (i.e. precomputed downscaled images, think mipmaps)? Right now the state of the art for truly large images (medical, geospatial, scanned artworks) seems to be JPEG (and I think also JPEG 2000?) tiles in TIFF containers, which would be fine except nobody seems to agree on how exactly to express the pyramids.
I mean, a plain JPEG can tolerate up to I think 2^16 × 2^16 pixels, and already that you don’t really want to decode from a single unseekable bitstream with no index and no effort to improve locality of data required to fill a rectangular viewport. [ImageMagick’s display(1) is the best at tolerating huge JPEGs and even it, IIRC, conks out after 2^15 × 2^15.] You can allocate however many bits you want for the size, but beyond a few dozen megapixels you really need to do indexed independently-decodable tiles, and when the image is dozens of gigabytes after compression, you need a pyramid of pre-downscaled versions as well (1/4 + 1/16 + ... ≈ 33% overhead which is completely acceptable). Thus my question.
If browsers extended `srcset` with support for HTTP Range requests, we could use a progressive-encoded jpg (xl or not) file as the source for multiple detail levels.
A device with a small screen would request the first 10kb of the image, while one with a medium screen might fetch 40kb.
The big advantage of that - for sites with many images - is a much better cache hit-rate for a given CDN spend.
Additionally, if you've already fetched a small version of an image and then want to view a bigger version, you've already got partial content downloaded & can fetch only the rest of the file.
The big feature over other new formats is compatibility with legacy JPEGs. You can (simplified) take the raw data from a legacy JPEG, reformat it as a JPEG XL, and achieve like 20-30% filesize savings without any actual re-encode, just better packaging of the same data. While converting them to AVIF or webp is a lossy re-encode, and so loses quality. I think it's really this feature that has people wanting it still despite the support for AVIF.
Also webp is IMO subjectively worse at the same file sizes than the other two. Dunno if there's any studies on it to back that up though. It also has a max image size that is plausibly a problem in some use cases (16k in one dimension) while AVIF is 65k per axis and JXL 1M per axis.
Webp lossy is better (compresses more with higher quality image results) than jpeg at everything except smooth gradients at high quality settings according to the research I remember doing. Webp lossy can't seem to get rid of banding until you go ultra high quality settings. Jpeg can show blue skies without banding at much more reasonable quality settings. So webp is better at anything where smaller files is preferred, like all website usage. Jpeg is better for long term storage of very high quality lossy compressed images.
I chose webp for long term storage of scanned documents in our SaaS product, as size reduction was more important than no banding.
Also webp has excellent support in modern software and operating systems. So that's not a drawback any more. JpegXL will be the best of all worlds choice in a few years when software support is good.
The big advantage is that you can convert from JPEG to JXL without re-encoding. This gives you an easy way to save 10%-20% in bandwidth for images you don’t have a lossless master for.
At the basic job of showing a normal 24bpp photo on screen, the differences between the formats are marginal.
jxl shines when you want to do anything even a little bit more complex. Support for lots more color formats, including fp ones. Support for an image with parts of it encoded losslessly, and parts with a lossy encoder. Great progressive decoding. And many more features.
Lossless: stronger than both (even though webp was pretty good there), especially AVIF that can't really do lossless RGB (must convert to YUV or incur a really bad compression ratio) yet relatively fast encoding.
Lossy: webp (VP8 I-frame format which means mandatory 4:2:0 chroma subsampling and ungodly smoothing) was never good, AVIF is better but only equal or worse at decent, visually transparent bitrates.
Another point worth mentioning: AV1/AVIF doesn't really have a standard encoder, libaom is a reference codec thus slow and not really interested in proper psy optimizations, SVT-AV1 is slowly getting there thanks to enthusiasts porting x264's good stuff to it but remains locked to 4:2:0 (lol). I won't even speak about the missed promises of FGS.
And finally, JXL's format has a lot of gizmos that make it more future proof as something to replace JPEG/PNG/GIF. Progressive decoding, lossless conversion from JPEG, very large limits (float bitdepth for HDR, image dimensions without tiling, unlimited channels incl. CMYK support) are good even when the encoder isn't yet supporting everything.
With both Firefox and Chromium using jxl-rs (Rust-based), I wonder what Apple will do about the libjxl (C++) they already shipped. I know they're doing some memory-safety with Swift, but are they shipping any Rust in their platforms so far? I also wonder if anyone's done benchmark comparisons between both libs.
--
Also, I was under the impression that after backtracking, Chromium was relying on Mozilla to come up with a Rust port, but it seems it was the reverse. Good on Google Research.
https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/
> 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.
Luca Versari, one of the devs between both libraries, has a performance dashboard to compare performance between the two https://jxl-rs-perf.lucaversari.it/
jxl-rs started to outperform the C++ library 2 months ago.
As much as I enjoy rust, there is no reason why a c++ library can’t be optimised to match the rust implementation.
It’s very rare that the actual performance benefits of rust implementations come from rust itself (though it does often push you to slightly better patterns). They usually come from the fact that rust implementations are usually a second (or 3rd, or 4th) iteration of the design, and the lessons learned help performance.
The other benefit of rust is that the stronger type system makes it easier to iterate and optimise without bugs creeping in. But once optimisations are implemented in rust, there isn’t that much pain to porting them back to c++, as long as someone cares enough to do so.
>As much as I enjoy rust, there is no reason why a c++ library can’t be optimised to match the rust implementation
but why would you bother? The rust library is the one that is being chosen to use. There is no point optimizing a library which is not going to be used.
> As much as I enjoy rust, there is no reason why a c++ library can’t be optimised to match the rust implementation.
I don't think anyone is claiming that. I took the GP's point as what was desired was a "safe, performant, compact, and compatible JPEG XL decoder in Rust" and "performant" (as defined as the speed of the c++ version) was passed two months ago.
> They usually come from the fact that rust implementations are usually a second (or 3rd, or 4th) iteration of the design, and the lessons learned help performance.
Sure, and looking at the recent commit histories, the team is focusing on getting the rust version ready for this milestone for obvious reasons, and is less concerned about immediate parity in the c++ codebase.
I suspect the real reason is safety. Rust isn't bulletproof but it's certainly much better than C++ when it comes to defending against memory corruption related attacks. And when you are building a decoder for untrusted data sent over the internet, this kind of thing matters a lot more.
I don't understand why anyone would continue working on the c++ project once the rust one started beating it in performance
jxl-rs (rust) is just a decoder while libjxl (C++) can also encode.
There is a rust encoder in active developing by someone outside the core JPEG XL devs.
If he is one of the devs between both libraries, why is there a performance gap? Why not port the optimizations from one lib to the other? You can even create a pinned agent workflow that automatically translates optimizations between repos. Fairly trivial to implement actually.
Just because you can theoretically write equivalent code in both languages doesn't mean two idiomatic implementations in each language will be 1:1 with each other. I haven't looked at the code in question, but some examples of common differences:
A C++ program might do template metaprogramming at compile time and the same thing at runtime in Rust, or vice versa. The C++ version might use virtual functions that rust wouldn't use. The Rust version might simply give more optimization information to the backend. The C++ version might use fairly awful parts of the stdlib like iostreams or shared_ptr that rust simply implements better. Etc.
Or maybe they're just focused on the rust implementation as they should be.
Because developers of security critical code don't flippantly merge LLM changes for marginal performance gain, and their time is incredibly valuable.
Shipping unsafe C++ is easier on Apple platforms than Rust. This seems unlikely to change anytime soon.
Apple is gonna do what apple wants.
What a funny tangent to go off on.
JXL was dead. Apple is who brought it back to life[1], and the only reason Chrome resurrected JXL, and now Firefox followed their path, is because Apple pushed JXL support to a billion plus devices.
I know people like complaining about Apple, but there's a "read the room" kind of moment where people just seem to either not know the context or are just knee jerking.
[1] Worth noting that Apple used the reference implementation, libjxl, and that project still remains the reference implementation with the Rust port being experimental (and of course Apple deployed JXL support over a year before the Rust port even existed). Maybe they'll switch to it at some point, but it's a bit premature to complain about.
I believe Firefox was the first to put out a standards position about adopting jxl if a Rust implementation happened. Chromium only aligned their position this year I believe, prior to that, it was a complete rejection.
Which is to say, Chrome followed Firefox here.
(Yes, I know Google Research implemented jxl-rs, but then, they also implemented jxl. Chrome’s position appears independent of them.)
I wasn't complaining, it's a factual statement made sarcasticly.
Things apple do because apple do:
- make a mouse you can't use while charging it
- gets bored of the power inefficency L of x86, makes the fastest arm cpu that causes x86 manufacturers get serious about power
- hey, those f keys? what if useless strip
- decades ahead in panel tech and refuses to compromise
> make a mouse you can't use while charging it
I'm not one to usually defend Apple-ism, but it always felt that this was such a nothing-burger. The mouse charges in like fifteen minutes and lasts for weeks. I don't have a work Macbook (or job :) ) right now, but when I did I would just occasionally plug it in while I went to the bathroom. It really was not nearly as annoying as everyone said it was.
I don't see what this has to do with the topic, sorry.
Their point is that Apple is the Nintendo of computing. They don't care what others do, they just do their own thing. Which produces some great things and some stupid things. They also don't care whether you think what they are doing is great or stupid, they just continue doing their thing
Which then tracks back to the beginning of the thread: the correct answer to whether apple will adopt jxl-rs or keep libjxl is "who knows, no point trying to predict them". Which is not a value judgement
How you square all of that with the iPhone regularly copying features Android had for years is your decision. Might be a symptom of the same, might be that this all was an entirely inaccurate description of Apple
That useless strip could play lemmings and doom, it wasn't all bad
And their Safari browser is the worst. It doesn’t properly support PWAs or many other features because they want to maintain tight control over their App Store.
Not to mention how updates are tied to OS updates...
Hasn't been the case for some time.
who are the knuckledraggers that are downvoting this comment? Its completely factual.
Significantly more on that here: https://infrequently.org/series/browser-choice-must-matter/
Maybe because they don't want to see this thread dragged down into an open-ended gripe-fest against Apple, especially when it's concerning a feature Apple did ship before everyone else.
Chrome appears to be doing the same: https://groups.google.com/a/chromium.org/g/blink-dev/c/-gDoj...
This is awesome! All it took was a Rust implementation I guess?
> All it took was a Rust implementation I guess?
And Apple including support in their default graphics library so every iOS (and Mac) supported it. (I use Firefox, but let's not pretend like they'd move the market on JXL support.)
Now I'd only wish browsers could come up with more convenient ways to get around when some websites and upload fields don't support jxl or some other image format, and would either do something about it automatically or offer some option to get around it (convert to jpeg or png and upload, or 'paste as an image' which would pretty much be the same as png conversion, or something)
I'm curious how many HN people in 2026 have not yet heard of JPEG XL / jxl
I have only heard of it in passing. I wonder what it adds beyond Webp and Avif.
It compresses better than webp*, has really good progressive decoding (current encoders are able to encode the image such that the most important part of the image gets decoded first, and you only need the first ~20% of the image to display it as a thumbnail), and it's also a very flexible format (unlike avif) since it can also display lossless files* and display much larger images than AVIF can.
Also the compatibility with existing JPEG files that was mentioned below, unlike other formats you can losslessly convert a JPEG into a JXL without losing quality but saving file size in the process.
* it actually has better compression than PNG for this
* and potentially AVIF too, but this is debated
avif also supports lossless, but it's so inefficient it might as well not exist.
Lossless webp is a completely different image format compared to lossy webp, even though they come under the same file extension. Unlike lossy webp, it's a good image format that has excellent compression ratio compared to png. I've often been using it for screenshots to avoid damaging text clarity and still maintain acceptable file size.
jxl has excellent support for both lossy and lossless cases, and can replace both lossy avif (even if somewhat less efficient at low file sizes), and lossless webp.
Note also that converting jpeg to jxl is 100% reversible, you can convert it back to exactly the same image (byte for byte identical) if you need to.
>Note also that converting jpeg to jxl is 100% reversible, you can convert it back to exactly the same image (byte for byte identical) if you need to.
Speaking as someone who loves JXL, I have a serious question: I once used ImageMagick to convert a JPG to a JXL, and then back to JPG, and the final JPG was a noticeably different file size compared to the source JPG.
What am I misunderstanding here?
Not sure imagemagick supports lossless transcoding. This old discussion from 2021 mentions that it didn't (in 2021):
https://github.com/dlemstra/Magick.NET/discussions/872
cjxl / djxl do lossless transcode reliably when called with all defaults (no arguments). Just re-checked:
JPEG to JXL transcoding and JXL to JPEG reconstruction are different from converting an image in either direction, it's gonna be a specific option (in something like xl-converter), so maybe it wasn't what was used and it was just a "reencode" into jxl and then into jpeg.
Image Magick re-encodes into an internal format, before output. If reproducibility is the goal, I'm afraid it just isn't the right tool.
(The IR used to be PixelPacket. Not sure how modern versions handle it.)
It probably used pixel-by-pixel conversion (decode input format -> encode output format), which is lossy, not the libjxl native way to convert JPEG (it needs to know about the original JPEG data, not the raw image data).
> [JPEG XL can] display much larger images than AVIF can
Does it do tiles? What about pyramids (i.e. precomputed downscaled images, think mipmaps)? Right now the state of the art for truly large images (medical, geospatial, scanned artworks) seems to be JPEG (and I think also JPEG 2000?) tiles in TIFF containers, which would be fine except nobody seems to agree on how exactly to express the pyramids.
Level 10 spec is 2^40 pixels, which is a ~1 million x ~1 million pixel square.
I mean, a plain JPEG can tolerate up to I think 2^16 × 2^16 pixels, and already that you don’t really want to decode from a single unseekable bitstream with no index and no effort to improve locality of data required to fill a rectangular viewport. [ImageMagick’s display(1) is the best at tolerating huge JPEGs and even it, IIRC, conks out after 2^15 × 2^15.] You can allocate however many bits you want for the size, but beyond a few dozen megapixels you really need to do indexed independently-decodable tiles, and when the image is dozens of gigabytes after compression, you need a pyramid of pre-downscaled versions as well (1/4 + 1/16 + ... ≈ 33% overhead which is completely acceptable). Thus my question.
One particularly interesting (to me, at least) approach using progressive decoding was described by Jake Archibald ( https://jakearchibald.com/2025/present-and-future-of-progres... ).
If browsers extended `srcset` with support for HTTP Range requests, we could use a progressive-encoded jpg (xl or not) file as the source for multiple detail levels.
A device with a small screen would request the first 10kb of the image, while one with a medium screen might fetch 40kb.
The big advantage of that - for sites with many images - is a much better cache hit-rate for a given CDN spend.
Additionally, if you've already fetched a small version of an image and then want to view a bigger version, you've already got partial content downloaded & can fetch only the rest of the file.
The big feature over other new formats is compatibility with legacy JPEGs. You can (simplified) take the raw data from a legacy JPEG, reformat it as a JPEG XL, and achieve like 20-30% filesize savings without any actual re-encode, just better packaging of the same data. While converting them to AVIF or webp is a lossy re-encode, and so loses quality. I think it's really this feature that has people wanting it still despite the support for AVIF.
Also webp is IMO subjectively worse at the same file sizes than the other two. Dunno if there's any studies on it to back that up though. It also has a max image size that is plausibly a problem in some use cases (16k in one dimension) while AVIF is 65k per axis and JXL 1M per axis.
Webp lossy is better (compresses more with higher quality image results) than jpeg at everything except smooth gradients at high quality settings according to the research I remember doing. Webp lossy can't seem to get rid of banding until you go ultra high quality settings. Jpeg can show blue skies without banding at much more reasonable quality settings. So webp is better at anything where smaller files is preferred, like all website usage. Jpeg is better for long term storage of very high quality lossy compressed images.
I chose webp for long term storage of scanned documents in our SaaS product, as size reduction was more important than no banding.
Also webp has excellent support in modern software and operating systems. So that's not a drawback any more. JpegXL will be the best of all worlds choice in a few years when software support is good.
> JpegXL will be the best of all worlds choice in a few years when software support is good.
Where is the software support lacking other than the browsers at this point?
The big advantage is that you can convert from JPEG to JXL without re-encoding. This gives you an easy way to save 10%-20% in bandwidth for images you don’t have a lossless master for.
At the basic job of showing a normal 24bpp photo on screen, the differences between the formats are marginal.
jxl shines when you want to do anything even a little bit more complex. Support for lots more color formats, including fp ones. Support for an image with parts of it encoded losslessly, and parts with a lossy encoder. Great progressive decoding. And many more features.
Higher bit-depth 10,12,16, float.
Lossless: stronger than both (even though webp was pretty good there), especially AVIF that can't really do lossless RGB (must convert to YUV or incur a really bad compression ratio) yet relatively fast encoding.
Lossy: webp (VP8 I-frame format which means mandatory 4:2:0 chroma subsampling and ungodly smoothing) was never good, AVIF is better but only equal or worse at decent, visually transparent bitrates.
Another point worth mentioning: AV1/AVIF doesn't really have a standard encoder, libaom is a reference codec thus slow and not really interested in proper psy optimizations, SVT-AV1 is slowly getting there thanks to enthusiasts porting x264's good stuff to it but remains locked to 4:2:0 (lol). I won't even speak about the missed promises of FGS.
And finally, JXL's format has a lot of gizmos that make it more future proof as something to replace JPEG/PNG/GIF. Progressive decoding, lossless conversion from JPEG, very large limits (float bitdepth for HDR, image dimensions without tiling, unlimited channels incl. CMYK support) are good even when the encoder isn't yet supporting everything.
I'm curious why a PDF with a jxl in it takes ages to load.
If you're in a browser without native support maybe they implemented a jxl decoder in javascript.
Will they add it to Firefox 115 for the remaining Windows 7/8 users or will you need a new operating system to add an image format?
Another thread: https://news.ycombinator.com/item?id=49421758
[dupe] https://news.ycombinator.com/item?id=49421758