Comment by jug
9 hours ago
And soon Firefox will include it in Stable. During October it will go from Safari only to majority coverage. Eventful month!
While AVIF may have a slight edge in some cases like in fairly lossy compression, you won't really go _wrong_ with JPEG XL (unless strongly CPU constrained) and I think the strength of the format is its extreme versatility as a "be all end all image format" for some time where comparative performance depending on functionality ranges from respectable to excellent. It can work as a replacement for AVIF, PNG, JPEG, WebP, even certain TIFF required scenarios (high bit depth, multichannel, layers) depending on use cases.
Rollout looks solid, but I'll probably avoid deploying it to anything live til early next year at the minimum. That'll give time for browser adoption to happen.
Biggest concern I have was the same I had with AVIF a couple years ago, which is hardware acceleration on the server side. I attempted to roll out AVIF only to find out the encoding time was so long that sync calls were timing out due to queuing. It's gotten a lot better, but just know that all of these newer formats really do need more compute. It may not be worth the cost tradeoff vs webp until encoders are baked into chips.
I had the same problem with AVIF. My platform allows users to “scrub” through a video file they’ve uploaded by hovering over the thumbnail. To achieve this it creates a grid of 100 representative frames, up to 480px in width per frame. So the images are pretty large and take up a lot of space in JPEG format. File size is important because it reduces lag time before the thumbnail is scrubbable.
We tried AVIF and file sizes were much better but it would take multiple minutes just to generate. We also got feedback from our self-hosted customers that it was using way too many of their system resources.
So we’re now using WebP which generates in about 10 secs using much less CPU. I’m open to JPEG XL if it can improve on those metrics.
To make sure I understand, your concern specifically applies to images that your application server is rendering custom for each visitor?
I'm assuming that for more persistent, cachable types of images, there wouldn't likely be that type of problem, right?
> your concern specifically applies to images that your application server is rendering custom for each visitor?
It's more if you accept image uploads from users in any way. I experienced a ~10-20x increase in processing time when accepting AVIF images, and I found that I couldn't rely on sync functions for that. I had to both change to async and upgrade hardware in order to support it at scale. I run a small reddit-like site that accepts media uploads and the end result was I had to choose between unshipping AVIF or doubling my server costs. I found that the image savings over webp weren't worth it at the time.
The same story is likely true for JXL until there's hardware encoding.
1 reply →
Seems Firefox will get support in version 158
https://groups.google.com/a/mozilla.org/g/dev-platform/c/3YM...
Obviously, once the Google overlords decided it.
No, the reverse. Mozilla opposed Google's original attempt to push JPEG XL years ago, and declined to ship without an implementation that they could confidently say was safe. See https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/ :
"We added experimental support for JPEG XL behind a flag back in 2021. But, at 100,000 lines of multithreaded C++, we were concerned about the attack surface this added to Firefox. 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."
4 replies →
A great codec but not the best for the web. For typical web use AVIF is almost always better.
The case against JPEG XL https://giannirosato.com/blog/post/case-against-jxl/
The article brings attention to advancements in AVIF encoders over the past few years (to which its author has greatly contributed), but does not provide a definitive comparison between the two formats, even when it comes to the web. Parts of it are entirely based on personal opinions and educated guesses.
There are some unanswered questions about the methodology used, the resources spent on development of the respective encoders is not taken into consideration, the future developments of JPEG XL encoding are written off as too costly and the author’s opinion on what kind of content is appropriate for the web is quite subjective. See also the recent discussion:
https://news.ycombinator.com/item?id=49690554
I don't see any advantage of any of the new formats over the good old and proven formats, so I stick with PNG and JPEG (properly optimized.) I can fire up any old browser and it will just work.
Unless you're targeting really old browsers, lossless WebP is absolutely worth it over PNG.
As a test, I have a set of 36 old MS paint Drawings, originally drawn on Windows 98SE, originally saved in bitmap format with a total size of 53.4 MB.
Transcoded to PNG format using FFmpeg and the highest -compression_level of 100, this same set of images takes up 403.8 kB.
Transcoded to -lossless WebP format using FFmpeg and libwebp with the maximum -quality value of 100 and maximum -compression_level of 6, the set of images takes up 174.8 kB.
Transcoded to lossless JPEG XL format using cjxl in the highest compression settings, the 36 images only takes up 126.6 kB.
Given the computing power required to decode JPEG XL images and their limited support, it may not make sense to use JPEG XL for non-archival purposes, but lossless WebP is an excellent middle-ground, achieving over 2x the compression level of PNG.
Lossless WebP has also been supported by all major web browsers since September 2022, when Apple finally added full support for lossless and animated WebP images. It really doesn't make sense to still be using PNG, unless you're targeting really out-of-date Mac or iOS devices. Having drawings and illustrations be 50% smaller (versus PNG) is huge!
Personally, I avoid WebP out of spite. While it has greatly improved over previous formats in certain uses, it has been lacking or offering only marginal improvements in others. That didn’t stop Google from pushing it hard on the web.
I was left feeling like the next time we adopt a format that tries to do everything, it should actually do everything just as well or better than its predecessors. Lo and behold, JPEG XL is probably the first format which actually achieves this, covering all kinds of pictures you can think of and doing a pretty good job on all of them. So for the first time, I feel like the format has actually earned its place in the ecosystem, rather than just being some megacorporation’s personal favourite.
Of course, this point of view is emotional more than rational. Technically, WebP is a sensible choice, so I don’t mean to discourage anyone from using it today.
1 reply →
JPEGXL literally is able to display images and colors that jpeg and png cannot (32-but floating point, layers, emission independent transparency, spot colors, built im depth maps). It’s not just about compression optimization. So for those use cases standard JPEG and PNG alone will never work. There are “updated” versions of JPEG that support some of these like HDR but those won’t work with any old browser either so back to the same issue.
Can the human eye even tell the difference? This feels like 8k vs 4k tv.
9 replies →
Yes, but that’s still a niche use case. Web pages look fine using the colors we already have. Somewhat more vibrant colors are a luxury.
1 reply →
I used to think this and then I saw how well webp reduced my website's bandwidth costs compared to optimized jpg or png. I felt a bit left behind at that moment, like I should have been paying attention to these great improvements over the years.
It is great to reduce file size but also the quality drops faster than it does with JPG. I did some testing and could confirm, it is quite documented.
Which I think it might be one of the reasons why Instagram still uses JPG for their images. The rule of thumb is that if your product is picture quality sensitive (like photos in IG) then use JPG, if not then WebP is fine since the compression is higher.
2 replies →
JXL has clear advantages and saying you don't see them means you either didn't attempt to see them or willfully ignore them
I'm not sure if the parent comment means to say, but I could choose to interpret their meaning to be:
PNG/JPEG have strong support (nearly everywhere). I think of them almost as the modern TIFF - relatively simple, and almost everything supports one or both of them (few to no issues).
JXL may eventually get there (that indeed seems to be its goal), but for now I wouldn't drop e.g. PNG or JPEG support in favor of JXL now.
And arguably, perhaps never drop support; its such a prevalent format, even if all software (prevalent or otherwise) supports the format in 10 years, there will be such a huge stockpile of JPEG/PNG that something will need to be used to read/convert.
1 reply →
Not everyone needs to be an early adopter of every technology.
Even if JXL is superior in every single way, it doesn't make sense to throw out a perfectly functional graphics package and design language for a marginal bump in capability.
4 replies →
I just switched over some machine vision code to use it for the lossless format, saving around 30% file size (~5 gigabytes per dataset) over optimized lossless PNG. I'll gladly take any storage donations you may be passing out though, so I can continue to use the good old and proven formats! ;)
James Brown recorded his music to sound good over an AM radio. It still sounds good on good equipment.
Meanwhile, there's a lot of modern music that takes full advantage of quality gear, but is basically unlistenable on bad speakers.
There's nothing wrong with either approach, but if you're not trying to raise the bar why not just stick with the lowest common denominator?
James Brown recorded his music to sound good over an AM radio. It still sounds good on good equipment.
Dean Martin recorded his records to sound good on low-end tween girl 1960's record players. My wife has one, and his stuff sounds great on it.
My wife also has two very high-end modern record players. Dean's old records sound like crap on that.
Master the media for the method.
biggest advantage for me is file size and lossless conversion of existing jpg images. In a network scenario that can meaningfully impact load times. Others will care about e.g. bit depth
Yeah but file size and lossless conversion of existing JPEG are something done by many other codecs. Dropbox famously developed Lepton[0] to compress existing JPEGs losslessly. There need to be some other factors that would lead to increased mindshare.
[0]: https://github.com/dropbox/lepton And Lepton is dead.
4 replies →
For one, it allowed me to fit several years of photos in a few gigabytes so I can easily back them up without going broke.
JXL supports extra channels for multispectral images.
JXL supports extra channels for multispectral images.
The bees and reindeer visiting my web site will be very happy to see UV images.
2 replies →
You should add that line to your resume.
I’d hire him.
I still miss the point. We have connections nowadays that are mostly good (with even the average domestic connection being gigabit!) and JPEG was fine in the days we had much slower connections.
On the other side we introduce yet another format that has to be supported, that creates compatibility issues with people that is using older browsers, or older software, older cameras, etc.
It's just another format meant to replace other formats to uniform all, so now we have N+1 formats that the user has to deal with.
What are the benefit for the final user? A reduction in 50% of the image size? We are not talking about videos (I re-encoded a lot of older videos to h265 because it save me almost 100/150% of the space, but unless you are a professional photographer, that btw uses raw format for archival, you don't have Tb of images so the saving for the average user are neglectable!).
> the average domestic connection being gigabit
This strongly depends on where your domicile is, even in Europe and the US. And lot of the users live outside these areas.
> JPEG was fine in the days we had much slower connections
Except that waiting for a large picture to load was very much thing, and in many cases still is.
> What are the benefit for the final user?
A number of users are still on metered mobile plans, and have little storage on their phones. With the current situation in electronics production, new phones are not going to offer more space, cheaper; to the contrary.
Also, publishing larger / better quality images becomes easier and cheaper.
> What are the benefit for the final user?
Many that you can search the web for, but to address the specific points you mentioned off the top of my head:
- Lower cell data usage for users
- Not everyone has gigabit fiber
The issue for me is that RAW sucks, and Jpeg also sucks. Jpegs are standardized and display anywhere, but are also super lossy. RAW, like fish, is not actually a thing beyond a sorta "I know it when I see it" deal. It's non-standard even between camera models from the same manufacturer, and there are like 10 pieces of software that bother with this bullshit and afaik none of them are OSes or browsers.
There is actually a standardised raw format, .DNG. The newer camera brands use this but the big players all stick to their proprietary formats. Amusingly DNG internally uses JXL to store the image.
First, try explaining to a non-tech person the difference between jpeg and png and they commonly scratch their head. It's nice to have a single format covering lossy and lossless, just meaning "picture". Whether it's a photo where lossless is ok or some icon where it isn't should be insubstantial.
Second, the "all connections are fast, what's the point" is one reason why the web is so slow. Connections are often slower than the dev with his 1gbps connect feels every day. The average website loads slower (in wall clock time) than it did 15 years ago. Smaller files and fewer network round trips would do everybody a favor.
Being an “everything” image format sounds awful and something that’s over engineered and no person understands it.