--
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.
jxl-rs started to outperform the C++ library 2 months ago.
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.
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.
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.
The obvious reason not to do this is that you lose the safety properties of it being written in Rust. What assurance do you have that there's not a memory error in the C++ version? It's similar but not purely a mechanical translation. Yes, you can port it back to C++, you can also port it to C or assembly or anything else you want. But why would you, especially for something like a codec?
There is a rust encoder in active developing by someone outside the core JPEG XL devs.
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.
The rust borrow checker makes it difficult to implement tree like structures with pointers like you would in C or C++. Safe rust trees are (imo) best written using vecs.
Rust makes function arguments noalias.
Rust adds runtime array bound checks.
Rust and C++ do iteration quite differently. Rust encourages map/filter/reduce. I suspect this results in different assembly.
Doing a “unity build” in rust is really easy (codegen-units=1). In C++, you need to make heavy modifications to your build system and sometimes your source too.
But with some time you could probably port the optimisations across. If anyone has some spare tokens, Claude can be quite good at doing this sort of work. Show it both repositories and tell it to make the C++ code just as fast as rust.
Not only Rust does C API, but Objective-C the way it allows to call Apple platform and call Apple compatible functions back.
Also well integrated Rust programs(with platform calls and low level hardware access) are well compiled without Apple SDK.
3-4 kicking Rust solutions are easy findable in this area.
> Shipping unsafe C++ is easier on Apple platforms than Rust.
... Which seems false.
I can easily believe that apple might not have rust tooling in their Safari build system. But that doesn't mean rust has poor support for apple platforms.
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.
No, it was actually the PDF Association.
They added JXL to the PDF standard.
If google wanted to maintain support for displaying PDFs, they would need to add support for JXL.
> No, it was actually the PDF Association.
The PDF Association didn't adopt JPEG-XL until September 2025. By then, Apple had been shipping JPEG-XL in Safari for two years [1]. So there's that.
[1]: https://webkit.org/blog/14205/news-from-wwdc23-webkit-featur...
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.)
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
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
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.
Imagine if you couldn't, because you needed to charge your mouse first.
MacOS releases a new version each year, the current MacOS landscape looks like:
- MacOS Sequoia (previous version, everything works as expected)
- MacOS Tahoe (current version, broken experience, basically Apple's "Windows Vista/8 moment")
- MacOS Golden Gate (next version, fixes what was broken in Tahoe, comes out in a month)
I'm on MacOS Sequoia because I have things that can't be broken by updating to Tahoe.
I also cannot test how my websites/webapps will work in a month, because Safari's beta (called Safari Technology Preview) only works on Tahoe and Golden Gate.
I cannot wait a month to update to Golden Gate because Golden Gate drops support for my iMac.
And I can't test the new version of Safari on my Windows or Linux devices because Safari isn't available for them.
I can test the Webkit browser, but that doesn't include the Safari specific changes that apple makes which I need to be able to test.
---
So, I can't test Safari until I wait a month and purchase a new apple machine.
(Oh by the way, apple keeps cancelling orders for new machines)
You can download three Linux-compatible WebKit-based browsers from Apple's WebKit page:
Epiphany Technology Preview: https://webkitgtk.org/epiphany-tech-preview
WPE: http://wpewebkit.org/download
WebKitGTK: http://webkitgtk.org/download
We use App Store.
That was the original conception of iPhone apps, until Steve Jobs realized just how much money could be made from the app store. Now you get to pay Apple a 30% cut for the privilege of installing software on your own device!
'The etymology of the name "XL" is as follows: JPEG has called all its new standards since j2k something that starts with an X: XR, XT, XS (S for speed, since it is very fast and ultra-low-latency), and now XL. The L is supposed to mean Long term, since the goal is to make something that can replace the legacy JPEG and last as long as it did.'[1]
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.)
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.
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.
Where is the software support lacking other than the browsers at this point?
There's a good visual comparison here:
I haven't actually seen a progressive jpeg rendering since the dialup days at any rate.
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
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.
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?
https://github.com/dlemstra/Magick.NET/discussions/872
cjxl / djxl do lossless transcode reliably when called with all defaults (no arguments). Just re-checked:
$ cjxl src.jpg out.jxl
(some output)
$ djxl out.jxl rev.jpg
(more output)
$ cmp src.jpg rev.jpg
(no output: files identical)(The IR used to be PixelPacket. Not sure how modern versions handle it.)
- people dispute it compresses meaningfully better the types of images typically found on the web.
- progressive decoding is increasingly less useful on the internet as more and more connections become latency limited instead of bandwidth limited. jpeg & png (Although png's version has a cost i think) both support progressive decoding. However the last time i saw an image actually progressively decode was probably mid 2000s.
-flexibility in file formats is usually a bad thing. look at tiff.
personally i think jxl is massively overhyped. Its not horrible by any means, but its only marginally better than existing stuff, at best.
Generally, the approach should always be to prioritize files loading as fast as possible.
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.
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.
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.
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.