Rendered at 23:46:30 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
jug 10 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.
jjcm 7 hours ago [-]
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.
dabinat 4 hours ago [-]
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.
xp84 7 hours ago [-]
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?
jjcm 6 hours ago [-]
> 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.
javier2 49 minutes ago [-]
This, even the prevalence of hevc (heic) encoded image from phones have caused us 4x the cpu usage.
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."
F3nd0 2 hours ago [-]
That’s not at all how it went.
Years ago, both Chrome and Firefox had experimental support. In October 2022, Chrome suddenly announced their decision to drop it (citing dubious reasons like lack of interest or improvements over existing formats). [1] It was only later, in January 2023, that Mozilla announced their formal position of not really caring about the format. [2]
In October 2023, one of the JPEG XL devs said that the responsible team at Google was ready to write a decoder in Rust if that was the only reason holding adoption back, even offering to work on browser integration. [3] One month later, another dev confirmed that a different pre-existing decoder written in Rust was already standard-conformant. [4]
It wasn’t until September 2024, nearly a whole year later, that Mozilla changed their official position from not caring to waiting for a suitable decoder written in Rust. [5] And it was only then that jxl-rs development really picked up. [6] Only later on, Chrome decided to change their position as well, but we can only speculate on what actually changed their mind.
There was no Google shoving JPEG XL down everyone’s throat like they once did with WebP. There was no Mozilla taking a clear, principled stance from the get-go. Whether or not JPEG XL was worth it, neither of these companies has acted in a transparently fair, exemplary way. And of course the first major browser to ship JPEG XL support to users was Safari, which may well have played a role in the others’ decision-making.
All of this reinforces my point, which is that Mozilla is not simply following marching orders handed down by "the Google overlords".
F3nd0 1 hours ago [-]
Firefox did not take very long to support AVIF (another recent image format clearly favoured by Google). Please do correct me if I’m wrong, but I’m not aware of Mozilla expressing any reluctance over AVIF’s abysmal lossless performance or other shortcomings (some of which have been addressed since), or insisting on using a memory-safe decoder like they have for JPEG XL. Why the stark difference in treatment?
We may not be able to say for certain, but Google’s massive influence is by far the most plausible explanation I can think of. And if the first step in your decision making is looking at what Google is doing, then ‘following marching orders’ is suddenly not such a bad description. (One can argue that with 3 % market share they don’t have much choice, but that’s beside the point.)
kibwen 3 minutes ago [-]
Mozilla was a founding member of the Alliance for Open Media, having sponsored Xiph to create Daala, which was later polymerized with Google's VP10 to create AV1. Mozilla has a vested interested in pushing all things related to AV1, including AVIF. That has nothing to do with Google's favor and everything to do with Mozilla's favor.
gsich 2 hours ago [-]
[2] was anticipatory obedience from Mozilla. Good for them that they grew a spine later (or more likely: they knew that Google will implement it some time later, so the change of opinion cost them nothing).
u1hcw9nx 5 hours ago [-]
A great codec but not the best for the web. For typical web use AVIF is almost always better.
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:
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.
Denatonium 2 hours ago [-]
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!
F3nd0 1 hours ago [-]
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.
miladyincontrol 47 minutes ago [-]
It wasn't some one company's choice and push. Almost everyone wins when bandwidth is cut and you get higher quality for less space. I'd argue most people's hatred for webp purely comes down to a few other corporations like microsoft, not supporting it well in the early days and blaming the format instead.
VanTheBrand 7 hours ago [-]
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.
Mistletoe 7 hours ago [-]
Can the human eye even tell the difference? This feels like 8k vs 4k tv.
Gigachad 2 hours ago [-]
Yes, a hdr photo in heif or jxl is a night and day difference. And if you apply any kind of color edits to the photo it stretches the colors to the point visible banding occurs on jpeg.
xp84 7 hours ago [-]
Bottom line it can deliver greater quality at much smaller filesizes. Considering RAM and storage are more expensive per byte now than they have been in years, I think it's incumbent on everyone in a position to do so, to use those resources wisely.
WebP and AVIF and HEIC had similar advantages but also some disadvantages (honestly chief disadvantage to WebP in my humble opinion was that nothing except web browsers -- to this day -- seem to support it!).
Another important point in its favor is that JPEG XL is designed as a royalty‑free, open standard, and Google provides a perpetual, worldwide, royalty‑free patent license for its reference implementation.
Avoiding JXL (once the rollout is sufficiently complete) seems, to me, like still shipping (non-animated) .GIF files where .PNG is better and smaller.
UberFly 4 hours ago [-]
Good summary. Thanks. I've played around a bunch with JPEG XL and the lack of JPEG compression artifacts even at much smaller file size is amazing.
Gigachad 28 minutes ago [-]
I imagine the result of this will be social media platforms and such will deliver higher quality images at the same filesize. Currently for local storage any image format is mostly fine, but for web services the image size becomes a massive cost which is why they compress your 8MB JPEG down to a 2 megapixel crunchy mess.
throw0101a 6 hours ago [-]
> Can the human eye even tell the difference? This feels like 8k vs 4k tv.
Even if it cannot, getting the same quality as 'classic' JPEG in fewer bits is still useful. So you have:
* better quality in the same number of bits
* same quality in fewer bits
Dylan16807 6 hours ago [-]
You can very easily see ugly banding if you try to use an 8 bit format to store HDR images, and that's all you get with normal jpeg.
sroussey 6 hours ago [-]
Everything should be HDR these days.
But I’m sure there are some that will say 64k of RAM is all anyone will ever need!
badatnames 5 hours ago [-]
Yes, and image editors absolutely can. If JXL lets me correct over/underexposed images by default everywhere I find them then it's worth it even just for that reason alone
tormeh 6 hours ago [-]
On an ecommerce site? Who cares. On instagram or anywhere people share photos? Amazing.
sam1714 4 hours ago [-]
E-commerce is the important use case, particularly in goods where people care about appearance: clothing, cosmetics, food.
Things in these categories have colorful packaging with spot colors, metallic inks, coatings, as well as store displays with carefully designed lighting. The added cost is justified because it increases sales. It makes sense to carry that over online.
skybrian 7 hours ago [-]
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.
Broiler9437 6 hours ago [-]
It looks fine sure, but that doesn't make it good either. Are you going to lock display technology to 8 bit forever? Most PC monitors already match or exceeding that limit, phones especially. HDR is something that needs to happen eventually, and for that new format is very important
j2kun 6 hours ago [-]
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.
tech-ninja 5 hours ago [-]
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.
xigoi 3 hours ago [-]
How so? You can literally convert a JPEG to a JXL that contains the exact same information and is 30% smaller.
throawayonthe 2 hours ago [-]
seems to refer to webp not jxl
ezfe 8 hours ago [-]
JXL has clear advantages and saying you don't see them means you either didn't attempt to see them or willfully ignore them
smaudet 8 hours ago [-]
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.
spider-mario 8 hours ago [-]
> I think of them almost as the modern TIFF - relatively simple
TIFF is not simple at all. There is a joke that it stands for “Thousands of Incompatible File Formats”.
legitster 7 hours ago [-]
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.
Gigachad 2 hours ago [-]
The industry already started throwing out jpeg for heif because jpeg is so woefully inadequate. Most camera brands have heif support now despite heif having horrible patent issues. Jpeg XL provides all the technical benefits without being patent encumbered.
Arnt 6 hours ago [-]
It may or may not be marginal.
For me now, its marginal.
For a past customer, not at all. That customer really cared about delivering image-heavy pages quickly. There was a fairly big difference in customer perception at a timing threshold.
BHSPitMonkey 5 hours ago [-]
The very point of this topic is that JXL is leaving the "early adopter" realm. If your website begins serving JXL assets next month, you'll simply be an adopter.
ezfe 1 hours ago [-]
What are you throwing out to use JXL?
nomel 4 hours ago [-]
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! ;)
legitster 7 hours ago [-]
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?
6 hours ago [-]
reaperducer 2 hours ago [-]
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.
asddubs 7 hours ago [-]
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
kccqzy 6 hours ago [-]
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.
Being a well supported format on all OSs will allow that. One of the biggest failure of WebP was very poor native support beyond browsers. JXL is supported natively by pretty much all operating systems right now beside Android. JPEG recompression is simply an advantage
Gigachad 2 hours ago [-]
I think the main issue with webp is it was pushed as purely a web delivery optimisation format and not a final output file you’d use in software. So it worked fine if you have a website automatically converting files for delivery, but no one was pushing for it to be supported in other programs.
JPEG XL is marketed as a high end format for photographers and already has support in most editing software.
asddubs 5 hours ago [-]
well, lepton doesn't have browser support. I'm not married to jxl specifically, I just want something in the browser with those features, and jxl fills that niche
4 hours ago [-]
xigoi 3 hours ago [-]
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.
RobotToaster 8 hours ago [-]
JXL supports extra channels for multispectral images.
reaperducer 2 hours ago [-]
JXL supports extra channels for multispectral images.
The bees and reindeer visiting my web site will be very happy to see UV images.
Gigachad 2 hours ago [-]
There could be a lot of scientific use cases for this rather than having to cram everything in to a visible color space.
reaperducer 2 hours ago [-]
My mind drifted closer to steganography.
copperx 8 hours ago [-]
You should add that line to your resume.
groundzeros2015 8 hours ago [-]
I’d hire him.
alerighi 7 hours ago [-]
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!).
nine_k 6 hours ago [-]
> 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.
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
tormeh 6 hours ago [-]
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.
Gigachad 2 hours ago [-]
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.
teiferer 7 hours ago [-]
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.
groundzeros2015 8 hours ago [-]
Being an “everything” image format sounds awful and something that’s over engineered and no person understands it.
xx_ns 12 hours ago [-]
It's exciting to see JXL support being re-added in Chrome after being removed a while ago and them seemingly not being interested in supporting it [1].
I think JXL is a cool image format, but was being held back by the most popular browser not supporting it, limiting its use (in the web especially) by a lot.
Yes I think the major story here is Google removing and then re-adding it back. Big companies have big egos, so this is quite a miracle.
I have a feeling now JXL is here to stay, finally.
Gigachad 2 hours ago [-]
The original libjxl was written in C and has been riddled with security issues. It’s been rewritten in Rust which is what has been shipped by Chrome and soon Firefox.
I have to think this is a substantial reason for the backflip here as adding a new huge C library to browsers is a huge concern.
smaudet 8 hours ago [-]
Hurrah!
ur-whale 4 hours ago [-]
> Big companies have big egos
More likely the Google eng. director who tried to get rid of it because of not-invented-here syndrome (it was built in a different org) got a new job or changed company.
2 hours ago [-]
innocent_name 12 hours ago [-]
Wasn't it due to poor security? libjxl had notorious bugs that would've on par with webp exploit, if present in browser:
Somebody could think of the web as primarily a platform for consumption, in which case it is OK for it to support a limited number of formats, actually desirable because it reduces the attack area.
Another is that the web is connected to general purpose computing in which that case the web browser competes with GUI shells (e.g. explorer, finder) and should be able to support every image format that is commonly used on the platform.
Back in the 1990s most platform supported a lot of file formats that weren't JPEG or GIF but browsers didn't support them and only a small set of formats have been added since then.
A long time ago I ran some sites that hosted large image collections and I struggled with costs so I did a lot of thinking about how to optimize storage and transfer. I came to the conclusion about 5 years ago that WebP is consistently a win over Jpeg, but I've never been a fan of AVIF. Yeah, it does great for big blog hero images that people don't look at closely, but it makes my mirrorless shots look like they were shot on a cheap Android. Yeah, I've seen that picture of the F1 car and it is superficially impressive but if you look closely at the highlights you can see that it erased the real highlights and replaced them with something plausible but... different.
dist-epoch 8 hours ago [-]
Interesting.
I'm on the other side, I hate webp because if I download such an image a lot of apps don't support it. So typically I need to screenshot it instead to get a usable jpg/png.
Now one more format to hate.
I would say webp/jxl/avif is anti-general compute, since they require very recent software.
mort96 8 hours ago [-]
Some people get mad at this reason for hating WebP, but it's so true. The main way in which most people's lives are affected by WebP is that images they download from the web no longer work.
xp84 7 hours ago [-]
So true. If browsers would just allow users to save images from the web in the user's choice of original, PNG or JPEG format, this would be a huge win. I recall 25 years ago that Internet Explorer, when right-clicking and saving an image, allowed me to save it as whatever it was, or as a .BMP. Somehow that's impossible today??
I know that end-users making memes or whatever aren't a demographic that will matter for adoption, but it seems really weird that this is still a problem on Windows and Mac in 2026. I've searched for browser extensions to no avail.
Dylan16807 6 hours ago [-]
Copy image puts a bitmap on the clipboard but nobody wants to bloat the menu with saving in alternate formats.
mort96 5 hours ago [-]
You don't need to bloat any menu. There's already a "Save image as..." context menu option which opens a save dialog. This dialog could have a way to select format.
I just tried it out now, using Waterfox on macOS 27. The save image dialog literally already has a Format dropdown. But I'm guessing it's just a weird part of some native dialog, it lets me select between "WebP Image" and "All Files". This kind of design could've been used to allow the user to save it as a different format than what it was served as.
Dylan16807 6 hours ago [-]
Personally I get mad at the programmers who sit there not updating their image decoding library for over a decade.
mort96 5 hours ago [-]
However many decades you wait, libpng is not gonna add support for WebP
Dylan16807 2 hours ago [-]
I'm also mad at anyone that linked to only libpng.
If you have support for multiple file types, you're already using multiple libraries or you're using a library that handles several kinds of file, either way you can and should update that.
asadotzler 8 hours ago [-]
We had plug-ins to support them all.
mort96 8 hours ago [-]
And that was a pretty bad solution. Nobody wants to see "this web page doesn't display correctly because you're missing the bla bla plug-in".
kstrauser 4 hours ago [-]
For the hundredth time, I miss Amiga’s “datatypes” system. You’d download a sound or image or video or compression library and drop it in the right place to register it with the OS. Then any app which used the OS’s built-in system for opening media files automatically got support for that format, without changing a line of code.
Imagine if installing libzstd meant that every program on your computer suddenly knew how to use ZSTD compression, or adding libjpegxl added support to every browser, word processor, and age editor you’d already installed.
Some parts of AmigaOS were wonky, like lack of memory protection. Others would still be phenomenally useful today.
j16sdiz 10 hours ago [-]
that's what firefox said, not chrome
F3nd0 7 hours ago [-]
And even Firefox took well over a year to bring it up, after stating they didn’t really care for JPEG XL. It was literally no one’s primary concern from the get-go.
dncornholio 11 hours ago [-]
Probably why Google implemented their own decoder in Rust
That’s what I was getting at, yes. (I contributed to both and am sitting with another core contributor right now.)
paimapi 10 hours ago [-]
I'm sure those implementers got their fair share of the Google profit or at least a nominal donation for doing most of the work of building out a feature enhancement
right?
mrandish 8 hours ago [-]
Thanks for pointing that out. The stated reasoning for not supporting JXL is understandable, though quite vague. It feels like the sort of general trade-offs you could cite about not supporting any codec. In my experience in large companies, such 'tough choices' on features that would be "nice to have, but doesn't make the priority cut" are usually driven by demand from internal stakeholders or corp strategy not exceeding budget/head count constraints.
While I'm happy for the reversal, it would be helpful to have a corresponding explanation addressing what changed leading to this reversal just two years later (assuming the decision to support was made 9-12 mos ago). Since significant decisions are usually harder to make in big companies (due to many competing prioritities, stakeholders, and processes), they tend to also be harder to reverse (especially in just two years, when most of original deciders are still in the same roles). I suspect the real thing that changed is more interesting than "the technology or people changed" or "our prior assessment was wrong".
est 11 hours ago [-]
> removed a while ago and them seemingly not being interested in supporting it
Removed because no one from Google benifits from supporting it then.
Re-added because someone could get a promotion by supporting it now.
andruby 11 hours ago [-]
> nobody benifits from supporting it
Do you mean the users of the browsers not benefitting, or specific Google employees/stakeholders?
thesuitonym 10 hours ago [-]
What a silly question, Google has never cared about users.
est 10 hours ago [-]
Yes, I meant Google employees/stakeholders.
They always abandon shit like this.
alwillis 9 hours ago [-]
There were obviously some internal politics going on—Google joined the Alliance for Open Media, a consortium of the who's who of the media/tech industry: Apple, Facebook, Microsoft, Amazon, Netflix, Nvidia… the list goes on. They supported AVIF as the next generation image format.
Google apparently wanted to be one of the "cool kids" supporting AVIF. When they removed the JPEG XL code from Chrome, they created the excuse that there was little demand for it, along with some other disingenuous talking points that didn't quite make sense. Ironically the project that ended up becoming JPEG XL was started by Google employees in Switzerland.
Anyway, I’m glad Google is supporting JPEG XL now. I wanted to use JPEG XL files for a project I started a month ago, but it was a non-starter with global usage under 20% at the time.
crote 11 hours ago [-]
Removed because having yet another giant C codec was a huge risk, re-added because the PDF Association chose JXL as their next image format so anyone rendering PDFs (including browsers) is now required to have it.
nananana9 9 hours ago [-]
"Required" is a strong word. More than enough people use Chrome as a PDF viewer that if Google decided to not support JXL, you'd see ~0 PDFs with it.
Another giant codec is only a huge risk if you run the decoder in the renderer process, which they say in the linked thread they do, but I don't see a sane reason why.
I'm sure if they asked the secret Gemini 4.0 AGI to use their existing very good sandbox to throw all the decoders in their own process and only share the image buffers, it could do it in a few hours.
est 10 hours ago [-]
> Removed because having yet another giant C codec was a huge risk
Removed because trillion dollar advertising company don't bother, which also happens to be the browser vendor monopoly.
How many man-hour effort does it take to create jxl-rs ?
My favourite tidbit about the Amiga is that it was the first platform that got PNG support in all its web browsers: you just had to install the png.datatype.
mrandish 7 hours ago [-]
AmigaOS was the first to bring a lot of smart ideas to a consumer platform.
I got my A1000 in late '85 and only had prior exposure to 8-bit home computers (C64, Atari, etc), CP/M and DOS (no mainframes, minis or workstations). I didn't actually use Macs or early Windows until the early 90s and it was shocking how backward they still seemed in some ways. I'd sort of the assumed the other major platforms were making similar advancements throughout by the late 80s and shocked to find out how wrong I was. It wasn't until the mid-90s that PCs and Macs felt like they mostly caught up on QoL and OS features.
alwillis 10 hours ago [-]
> Why can't it be shipped as a shared library for the whole system to use?
That's how it works on macOS; the bundled apps (Preview, Photos, etc.) gained support for JPEG XL.
burnte 9 hours ago [-]
This way browser vendors control what their app supports, and won't have something break because a user doesn't have a library.
code_duck 11 hours ago [-]
Google seems to prefer reimplementing every portion of an OS possible in Chrome.
DC-3 10 hours ago [-]
If you want things to work every single time on a billion different devices this is how you do it.
titzer 9 hours ago [-]
Yeah, and then 100 different apps can repackage the browser engine as an Electron app, each weigh 300+mb.
I saw this recently with Balena etcher. It's a firmware flashing app with about 10 buttons total. It's over 400mb because it's written in node and has an electron GUI.
Good jerb.
encom 9 hours ago [-]
When your flashing app starts getting bigger than the operating systems it's writing, you should start asking yourself some questions.
~$ du -h $(which dd)
76K /usr/bin/dd
Etcher truly is the clowniest Electron app of them all.
mort96 8 hours ago [-]
Better and similar size:
$ du -h $(which pv)
116K /usr/bin/pv
pv has a progress bar and nicer syntax. Next time you need to write an image, try:
sudo pv -Yo /dev/blah /path/to/your/image.img
The -Y makes it sync after each write so that the progress bar represents actual progress instead of just how fast you can copy to kernel write buffers.
My life improved measurably after I contributed that '-o' flag to pv and it then made its way into all my systems through regular OS updates :)
TheAmazingRace 3 hours ago [-]
Nice pro-tip! Thanks stranger.
titzer 8 hours ago [-]
Long live dd! Except every time I use it I am terrified I'll blow out the brains of the wrong device :/
Another example clown app: the MacOS downloads of TuxGuitar, a Java app, used to just ship as a zip with a big jar in it. Now it ships an entire Java Runtime environment specific to your processor architecture. It's 480MB. Derp.
yjftsjthsd-h 6 hours ago [-]
> the MacOS downloads of TuxGuitar, a Java app, used to just ship as a zip with a big jar in it. Now it ships an entire Java Runtime environment specific to your processor architecture. It's 480MB.
MacOS used to include Java out of the box, and then they stopped doing that. How else should an app reasonably behave to keep supporting new versions of the system?
titzer 3 hours ago [-]
Requires: Java 22 [link]
BHSPitMonkey 5 hours ago [-]
> It's a firmware flashing app with about 10 buttons total.
What you're saying is it's the ideal kind of application for not obsessing over its background resource consumption, given that it's only going to be running for 10 minutes once or twice a year.
xp84 6 hours ago [-]
Indeed. The most goofy is their proprietary Print dialog. I think(?) they added it to gain a previewing pane, but Apple added that capability to the native print dialog about 10 years ago. Chrome still forces its old bespoke one though, and when you do the extra click to get the OS standard one, they apparently don't use the previewing API, so it's missing.
lxgr 10 hours ago [-]
Given that there are more operating systems than browser engines these days, I'm not sure this would be an unequivocal win.
arghwhat 9 hours ago [-]
Eh. WebKit, Blink, Gecko being the big ones, supporting Windows, Linux (and alikes — maybe one would consider Android separate in this context) and Darwin (in this context iOS/macOS is the same). Mostly 1:1.
The thing is that it's still just a library, it just happened to be pre-installed. CGImage is just a helper in the Core Graphics library, not some magical "native"/"core" functionality in the OS that would be different than any other library with the same features.
An equivalent library for Linux (glycin for example), or per-format libraries like jxl-rs, are not "included in the OS", and tend to be the very same libraries one would use for Windows. If that does the trick on most platforms, then why have the maintenance burden of doing something different on macOS if all it does is save a few bytes on disk?
From Google's perspective, they would likely not want Chrome for macOS to gain support for jxl as the sole platform anyway, even if they are using CGImage and could decode it that way...
lxgr 8 hours ago [-]
I'd definitely consider Android separate from Linux, yes. Their multimedia subsystems are completely different. The same applies to tons of embedded Linux platforms running an embedded Chromium or WebKit.
Browsers have also largely switched to handling most aspects of TLS and certificates themselves, despite there being OS libraries for those as well; the same applies to HTTP.
groundzeros2015 8 hours ago [-]
Because browsers want to provide a consistent platform and can’t rely on OS vendors to do it in the way they need and prioritize their interests.
looperhacks 11 hours ago [-]
But it is a shared library? It's used in both Chrome and Firefox.
spider-mario 10 hours ago [-]
Which both vendor it.
ur-whale 4 hours ago [-]
> Why can't it be shipped as a shared library
Shared libraries are a bad idea that is simply taking way too long to just die the horrible death it deserves.
echelon 10 hours ago [-]
Such an important piece of software does not want to subject itself to the packaging and support woes of shared libraries. There are security issues, maintainability issues, and much more headache by going with that approach.
Static linking is one and done, headache gone. People have large drives these days, so it's not a problem.
There are areas where the browser will dynamically link, but those are more OS-related than image and file format codecs.
Glad to see it happen. I'd prefer it there was just one format rather than both jxl and avif, but at least it's the final nail in the coffin of webp which seems to have accomplished little but annoy people for not much gain.
The wider ecosystem support is still far from commonplace, but it is slowly changing. iOS 18 wouldn't work with .jxl in Photos, but 27 does. Similarly, quick look and preview works fine on MacOS 27, thumbnails show up properly etc. I also found no issues with .jxl on linux, and image editors are slowly adding support as well.
Plain old jpg will still be everywhere for the next decade, but I'm glad that we finally have superior options with no real downsides, and without all the patent bullshit to boot.
notnullorvoid 10 hours ago [-]
What issue do people have with webp?
nemomarx 10 hours ago [-]
Still can't upload it to every site that takes images, my file browser doesn't preview them nicely for whatever reason, that kind of stuff.
IvanK_net 5 hours ago [-]
The support for WEBP images across the industry is like 100x better than AVIF or JXL.
tredre3 15 minutes ago [-]
JXL is too new to draw any conclusions. But indeed, the market has spoken and it doesn't want avif. I tried adding avif support to a service myself, but the very slow encode speed made it unsuitable without paying for a larger server (or worse, a thumbnailner-as-a-service). Only a handful of enthusiasts (who chime in every such thread!) like avif.
Personally I fully expect jxl to succeed where avif failed and webp floundered.
hbn 8 hours ago [-]
I wonder how much lack of support is due to the name that seems to self-imply that it's only for the web.
Seems like terrible branding if it wants to be taken seriously as a standard.
edflsafoiewq 5 hours ago [-]
Presumably the same problems exist for avif/jxl?
gruturo 5 hours ago [-]
It's frankly pointless. Pretty much nothing produces them natively, so it's usually a generation loss from JPEG, not enough compression gains without annoyingly visible loss of quality, still has format many format and functional limits so it solved nobody's problem at any time, pretty much.
And much (though not all) of its improved compression (before it damages the image too badly) was anyway matched by the better JPEG encoders which were released and improved over time. It sure benched very well against a 30+ year old JPEG encoder implementation though.
JXL has a pixel-accurate JPEG-input mode with no generation loss which already beats WebP, a native mode which is way way better even, it addresses many more use cases and is not Google's pet project (saying this while thanking them for all the foundational work from which modern image/video codecs benefit - JXL itself first and foremost!) so it DOES have better than a snowball's chance in hell of becoming the defacto standard of the next 10-30 years and we'll soon see it in silicon.
cmplxconjugate 10 hours ago [-]
Poor support in some instances. Apple lagged for a long time for iPhone support. Discord mobile still does not support animated webp's.
slashink 10 hours ago [-]
(I work for discord)
Discord Mobile absolutely supports animated WebP (in fact I just tried uploading one to make sure I wasn't hallucinating here).
aquova 8 hours ago [-]
Well while you're here, there definitely are some issues with animated image support. Just earlier this week I attempted to use an animated .avif as my avatar image. It uploaded fine, the preview showed it fine, but the actual applied image was static again. Not sure if there's some issues with in the pipeline to handle those.
tasuki 10 hours ago [-]
Surely support is even worse for both .jxl and .avif? If the annoying thing about .webp was lack of support, I don't think .jxl nor .avif solve any of that - just the opposite.
F3nd0 9 hours ago [-]
One thing to note is that even when WebP did eventually get support in many places, it often look a very long time because there just wasn’t that much motive or interest to support it. So for years it was the weird format you’d accidentally download from the web and have little luck getting to work off-line.
The non-exhaustive table linked below shows how long it took for different programs to support different image formats since their introduction. Outside of Chrome, Chrome in disguise, and whatever has become of Firefox, adoption of JPEG XL has been far more enthusiastic than it ever has for WebP—or AVIF, for that matter. So we are very unlikely to have a long period when JPEG XL only works on the web and nowhere else.
Right, due to slim support outside of browsers, webp files kinda turned into lumps of coal when downloaded, going from the image you wanted to a chunk of data that nothing but the browser knew what to do with. It was like the file format version of those fake-transparent PNGs with checkerboard background.
nemomarx 8 hours ago [-]
> even at the time of writing, inserting a WebP in a Google Docs results in “unsupported image type.”
This is pretty wild. Google can't align their own tools for it?
dopa42365 8 hours ago [-]
webp = VP8 image
Nothing wrong with that per se, it's just old and limited, especially compared to avif/AV1 which would be like a theoretical VP10 at this point.
groundzeros2015 7 hours ago [-]
Poor support makes it feel like a form of DRM.
kelseydh 12 hours ago [-]
Every time a new image format comes out, I think about the compatibility crisis between apps.
E.g. Telegram still doesn't have sane support for .webp, it treats them as stickers. MacOS can take a long time to update with support for new formats. Image viewer apps even longer, many never updating to support new formats.
pmarreck 12 hours ago [-]
JPEG-XL is not particularly patent-laden and its license is correct for the use-case.
Other than the complexity of its implementation, there is very-little-to-no business nor technical reason not to use it or include it.
It has every right to be "the" image format for the next 20-odd years. Excellent compression, excellent lossless mode, transparency, etc. etc.
And probably my favorite feature- progressive rendering, which means you never have to make thumbnails ever again, you just truncate the output stream at the right proportion of pixel data (!)
iOS also now supports it natively for the photos it takes... but only if you have a newer iPhone than mine (a 15 Pro Max).
crote 11 hours ago [-]
I think the bigger driver is that, due to it being the next PDF image format, most platforms will already be forced to add some form of support to it.
When literally every OS already comes with a form of libjxl pre-installed there is no good reason not to add support for it.
> you just truncate the output stream at the right proportion of pixel data
Does the format have explicit support for this? As in, is there any easy way to do, say, an exact Range request after reading the file header?
yangm97 10 hours ago [-]
That doesn’t seem related to the codec itself but rather how you fetch said image.
Worst case scenario you should be able to add some smarts to the server and a query string such that the client can request 5% of the file or whatever simply by fiddling with the url.
crote 32 minutes ago [-]
Yes, but figuring out the "5% of the file or whatever" is the hard part!
Let's say JXL does progressive decoding by encoding the image as a checkerboard (it doesn't but for the sake of argument): First you send the average of each 8x8 block, then you send the adjustments needed for the 4x4 blocks within that, then you send the adjustments needed for 2x2, and then 1x1.
If the client knows that it is going to display the image at a low resolution, anything beyond 8x8 might be completely useless, so it would be valuable to know where the 8x8 section starts and the 4x4 section begins. Under-guess and you don't have all the data needed to display it, over-guess and you're fetching data you are going to throw away.
This makes it very useful if it is trivial to analyze the image to determine that, say, the first 5kB are needed for 500x500px display, the first 150kB are needed for 1000x1000px display, and the full 500kB for 2000x2000px and above - either to dynamically generate a <picture> srcset server-side, or to have the browser determine when to abort the fetch after parsing its header.
Dylan16807 6 hours ago [-]
Knowing where to truncate before you get there is related to the codec itself. Can I figure out where the quarter resolution data ends from the header alone?
weberer 11 hours ago [-]
>JPEG-XL is not particularly patent-laden and its license is correct for the use-case.
The same could be said for .webm, but Apple refused to support it because they wanted to patent-laden alternative to thrive.
alwillis 8 hours ago [-]
> Apple refused to support it because they wanted to patent-laden alternative to thrive.
Where do people get this stuff?
Apple finally supported WebP in 2020, 10 years after it was released by Google. Firefox added WebP support in 2019, a year before Safari. Was Mozilla also part of conspiracy to undermine WebP? Come on now.
Seems to me neither Apple or Mozilla wanted to be forced to support a format they had no say in developing. Usually there's a process for coming to consensus on standards.
WebP is ubiquitous now, not the case in 2010 when it was released.
It had advantages compared to JPEG, but not enough at the time to justify changing workflows, etc. WebP initially had better compression than JPEG, but as encoders/decoders improved (MozJPEG, Jpegli, turbo-libjpeg, Guetzli) the lead WebP had mostly went away regarding compression and visual fidelity.
Going forward, WebP is becoming less relevant by the day; it doesn't support wide gamut color; it only supports RGB. It's max pixel count is quite limited compared to AVIF and JPEG XL. Newer formats have use cases beyond the web; WebP doesn't.
zigzag312 8 hours ago [-]
Can progressive loading be made less fine-grained? With too many levels you don't know, if image is still loading or is just low-res.
Loading vs loaded difference needs to be clear.
youngtaff 8 hours ago [-]
AFAIK that's just a case of choosing how many scans to use at encode time
bmacho 8 hours ago [-]
> you never have to make thumbnails ever again, you just truncate the output stream at the right proportion of pixel data (!)
It's an attack vector for images to have different thumbnail/first bytes than the final image so software still have to decode the whole image.
Gander5739 7 hours ago [-]
How would that work in an attack?
bmacho 6 hours ago [-]
For serious, general purpose programs when thumbnails are shown people expect them to correspond to the full images, and not something else. Windows explorer, android gallery, gnome file picker etc can't show made-up thumbnails, or people would send or delete the wrong images, or would have no idea what images do they actually have.
png/webp (just as jxl) can store thumbnail in their meta, but no operating system, gallery, browser etc uses that because it has no usage that is safe.
I am not sure how easy it is to create a jxl image that starts differently from how it ends. If it is super easy then I expect programs not relying on it for thumbnailing (especially that they already have a way to generate and store thumbnails). Maybe browsers will support progressive loading, but it has no use for local images.
Gander5739 5 hours ago [-]
I believe the image would need to be present in the full size image, so I think that would limit to some extent the attack vector, but I don't know how far you could push it.
esafak 8 hours ago [-]
The problem with progressive rendering is that the user never knows when downloading is complete unless you add loaders to each image.
weinzierl 12 hours ago [-]
True, but in my opinion JPEG XL has the right balance of features to become a true replacement of almost every relevant image format we use today, on the web and elsewhere.
Nothing is perfect and niche formats will always be necessary but I think JPEG XL has a good chance to become the USB of image formats.
cubefox 11 hours ago [-]
Yeah. Here is a surprisingly readable article on all the supported features and design decisions of JPEG XL:
https://arxiv.org/abs/2506.05987
The format is designed to be as general as possible, potentially replacing many common (JPEG, GIF, PNG) and professional image formats.
For example, JPEG XL supports pages (e.g. for comic books), layers (with variable frame sizes, positions and blend modes) and timed animations.
yangm97 10 hours ago [-]
I wish they had kept the support for progressive decoding of animations just like FLIF had but I guess they had to draw the complexity line somewhere.
Unai 10 hours ago [-]
That was indeed surprisingly readable and very in-depth at the same time. Thanks for sharing!
shevy-java 11 hours ago [-]
How about AVIF?
I have not read that many direct comparisons here.
andrewaylett 6 hours ago [-]
In my experience, it's competitive on output size but not on compression speed. If you're not compressing online then that's fine, but we're running a service that resizes and recompresses on the fly. We serve JXL if the client indicates support for it, JPEG using JXL's jpegli, WebP, or PNG, depending on various factors.
spider-mario 11 hours ago [-]
Much worse at lossless at least.
farlight 10 hours ago [-]
Depends on who you listen to, or what you test it on. It goes either way, and avif is typically significantly better at small files sizes where loading speed (or saving data) is the priority.
Broiler9437 5 hours ago [-]
Definitely not with lossless. It consistently lose to JXL and WebP
spider-mario 10 hours ago [-]
On lossless? No.
mort96 8 hours ago [-]
Really? The lossless comparisons I've seen has JXL winning over AVIF, do you have a link to the comparisons you've seen where AVIF wins in lossless?
alwillis 10 hours ago [-]
> MacOS can take a long time to update with support for new formats.
Apple added JPEG XL support for macOS, iOS, iPadOS, and watchOS in September 2023 [1]; iPhone 17 Pro/Pro Max added support for JPEG XL Lossy and Lossless compression for ProRAW pictures last year [2].
When Apple adopts jxl-rs, Safari, Chrome and Firefox will use the same JPEG XL decoder.
When Apple adopts jxl-rs? Any source for them doing that? I can’t think of any Rust code that Apple is shipping.
alwillis 57 minutes ago [-]
I didn't intend to give the impression that Apple was definitely going to use jxl-rs. You're correct; there's been total radio silence from the Safari/WebKit team regarding anything related to Rust.
But it makes so much sense for Apple, Mozilla, and Google to support jxl-rs. Of course, that doesn't mean it's going to happen.
Keeping quiet and then adding jxl-rs to a dot release like Safari 27.4 or something is also a very Apple thing to do.
Gormo 11 hours ago [-]
It's too bad that the concept of having a system-wide plugin architecture for importing/exporting formats never caught on outside a few niche platforms. AmigaOS had DataTypes back in the '80s, and BeOS had Translators back in the '90s.
The Linux/FOSS world kind of approximates this just because applications are often built against the same underlying libraries and utilities, e.g ImageMagick or FFMpeg, rather than implementing their own import/export filters, but it'd be nice to be able to install a single system-wide datatype library for a specific format, and have all of my existing software instantly be able to read and write it.
WIC is reasonably widely used since it's used by WPF to load images. The problem is that a plugin codec structure exposes you to bad codecs. We had a tool at work break because someone installed a fast image viewer that overrode the default WIC JPEG decoder with a faster one that crashed loading our tool's splash screen image.
etatester 11 hours ago [-]
Codecs have been a thing on both major OSes, Windows Media Player could open DivX and QuickTime could open MKV. I think they were only limited to videos however.
Gormo 3 hours ago [-]
That's true, Windows has had an OS-managed codec system since 3.x. Only applies to video and audio formats, though, not a general system for any data type.
TheAmazingRace 3 hours ago [-]
Gives me fun memories of installing the Intel Indeo codec on Windows 3.x and Windows 95 PCs to play videos from a CD-based encyclopedia.
kccqzy 11 hours ago [-]
I think QuickTime 7 had that capability (I remember installing a codec to make it play wmv video) but Apple removed the plugin architecture in QuickTime X.
10 hours ago [-]
zarify 12 hours ago [-]
Ugh. Every time I accidentally put a HEIC on my Windows machine, or one of my students tries to upload a WEBP to our school's LMS :/
childintime 11 hours ago [-]
The user's OS or the LMS should offer to convert it on the spot. Worst case to .bmp
11 hours ago [-]
AlienRobot 12 hours ago [-]
If I remember correctly Instagram didn't support WebP either.
cyberrock 12 hours ago [-]
The tortoises have somehow outrun the hare because Safari still hasn't turned on progressive loading in libjxl (which had this feature since before Safari added the feature), while FF (non Android) and Chrome shipped with it enabled. The 3 year long chess clock is now flipped.
tepmoc 11 hours ago [-]
One downside is that you cannot tell if format lossy or lossless by looking at its extension.
AshleysBrain 11 hours ago [-]
That's true of WebP and AVIF as well. I think all modern image codecs have both lossy and lossless modes - the separation between JPEG for lossy and PNG for lossless seems to be a historical oddity.
spider-mario 11 hours ago [-]
And a nominally “lossless” image may have been reencoded from a lossy source.
debazel 10 hours ago [-]
You can’t really do that with PNG today either, because of all the PNG optimizers that quantize images before encoding them to PNG for better compression.
unglaublich 10 hours ago [-]
Independent preprocessing doesn't make PNG itself lossy.
spider-mario 9 hours ago [-]
The point is that you can’t tell whether it’s a lossless image by looking at the extension.
deathanatos 6 hours ago [-]
By that definition, all formats are lossy, because any preprocessing could be lossy, and the word loses all meaning … which is why we don't use that definition.
spider-mario 3 hours ago [-]
By what definition? I didn’t say anything was lossy; I said you couldn’t be sure that the image was lossless just from the extension. Of course, it might still be, and you might have other reasons to know it to be.
Dylan16807 6 hours ago [-]
The word doesn't lose definition, it has different definitions for codecs and images.
If you reencode a jpeg to a png, you used a lossless format but your image is very lossy.
mnw21cam 8 hours ago [-]
It's not the PNG encoding that causes the loss. The optimisers are literally creating a different image and then losslessly encoding it as PNG.
But it's also a valid point.
arthur-st 10 hours ago [-]
Yes, but a lossless encode of a lossy copy of an image results in a lossy image functionally.
adzm 11 hours ago [-]
This is indeed frustrating, though realistically not that big of a deal for most users, especially if you consider lossless as just highest quality. Though personally I think it makes sense to have different extensions by convention for lossless and animated images.
nananana9 10 hours ago [-]
It's a big deal :(
JPEG artifacts are literally a meme, normal people are aware of this stuff.
I hold the extremist view that had we decided to use .png for lossless webps, it would have been an overall net gain - in people's minds "png" maps roughly to "whoever last touched this image didn't do anything evil to it" - very few people care how the data is actually encoded.
Broiler9437 6 hours ago [-]
I mean we are already dealing with that nowadays. Many PNGs are either JPEG in a different package or straight up lossy compressed. Unfotunately extensions have never been safe for judge
eviks 9 hours ago [-]
You cannot tell it just from the extension either. If you like extensions, you can use a '.lossless.jxl'. And in general for most formats, you can use metadata to store that info (also doesn't guarantee anything)
pmarreck 11 hours ago [-]
ah, that's a good point.
perhaps use .ll.jxl to indicate "lossless jpegxl" informally?
prior art: I've been using .frontmatter.md or .fm.md for markdown files with frontmatter
chaosharmonic 11 hours ago [-]
I've been wishing for years that all of these codecs with hybrid lossless/lossy modes would just add a single l to their file extensions, purely for the annoyance of it.
Like, you can do this individually, but it's not the same thing as actually having it in the standard.
rozab 10 hours ago [-]
Does the L stand for lossy, or lossless? Or large, as in this case?
adrianmonk 6 hours ago [-]
The L in JPEG XL stands for "long-term"[1]!
But people are definitely going to assume "eXtra Large". Lots of people. I guess a few will think "excel" (as in JPEG XL comes out ahead and is superior).
Does the one at the end of .JXL count toward the total? Nobody knows what it stands for anyway.
chaosharmonic 10 hours ago [-]
See I would think lossless is the one you have to specify. (Also, it stops being "large" when you extend this gripe to similar formats like AVIF and WebP.)
chaosharmonic 5 hours ago [-]
And no, L isn't for large, we have W for that
(You know... for "Wumbo")
hmry 6 hours ago [-]
When writing GPU shaders it's not uncommon to use extensions like ".vert.glsl" = "vertex shader written in GLSL", ".frag.hlsl" = "fragment shader written in HLSL", etc.
Levitating 10 hours ago [-]
Multiple extensions typically denote nested filetypes.
Like files.tar.xz may be decompressed with xz and then extracted with tar to get the directory "files".
I think in your case .md.fm would be a greater fit, as the front matter is read first. Or just .fmd
yhjc2692 8 hours ago [-]
This is something that can be addressed by file managers - showing a metadata entry on whether it's lossy or lossless. File extension (along with the bifurcated mainstream adoption of JPEG and PNG) has been a great proxy to do this, but like others noted, can be deceptive, which is arguably worse.
Levitating 10 hours ago [-]
I can't really think of a scenario where that would be useful? File-size is more indicative of quality anyway.
flockonus 6 hours ago [-]
Interesting win for a cool format, i remember there was a rather arbitrary closing of the issue in Chromium forum despite big support for its addition, more strange yet is that Chrome team was pushing it's technical advancement forward.
Linking that is really missing the point, that the number is going to have a massive jump in a few weeks.
flockonus 3 hours ago [-]
Not really.. caniuse is quite literal to its name, as a web dev that's what orients what tech i pick up to deploy today.
Anything below ~90ish% is no go, unless i have a fallback strategy of some sort.
Dylan16807 2 hours ago [-]
> Not really.
Are you saying that the percent it'll be in six months isn't relevant to you, or something? You'll probably be working on most of the same projects, even. If you do care about the future then yes caniuse is missing that point.
> Anything below ~90ish% is no go, unless i have a fallback strategy of some sort.
Once a few more versions of chrome roll through it'll jump up to almost 80%, and you can have a fallback easily.
flockonus 1 hours ago [-]
> Are you saying that the percent it'll be in six months isn't relevant to you, or something?
It absolutely is relevant.. but only in about 6 months :)
Suppose the obvious case, i have some resizing pipeline for images. Would i include support today in my resizing pipeline today and pay a few extra cycles and storage for someone that my clients can't read?
It would be cool to have a subscribed alert for when the tech crosses a certain % threshold adoption so i can look at it again, otherwise it just relies on my brain's flawed long term cron job
spartanatreyu 27 minutes ago [-]
> Suppose the obvious case, i have some resizing pipeline for images. Would i include support today in my resizing pipeline today and pay a few extra cycles and storage for someone that my clients can't read?
Yes, this is literally what the <picture> element is for.
Your hypothetical pipeline would be able to convert <img> elements into <picture> elements with multiple <source> elements for different user resolutions and format supports.
YesThatTom2 12 hours ago [-]
Drat! I hoped this was going to cover the internal battle where Google executives trying to stop JPEG XL and how engineers finally convinced them to change their minds.
My guess: the engineers didn’t win the argument. The executives just gave up once all the other browsers had added support.
pwg 12 hours ago [-]
> The executives just gave up once all the other browsers had added support.
The big turning point seemed to have been Adobe adopting JpegXL as an approved image compression algorithm for the upcoming PDF spec. update. With that, since all browsers seem to also want to be PDF renderers, meant they had no choice but to include a JpegXL decoder. The win, if there was one here, was that the decoder they have to ship anyway now was exposed for use by <img> tags as well as by the PDF renderer.
JPEG XL is largely a Google effort including in creating the specification, the reference implementation and later a safer Rust implementation. Why would Google executives want to stop it? From what I gather it's Chrome engineers that didn't want it because it was huge, had little adoption (at the time), and was rather redundant with AVIF and WebP (for Web purposes). Not saying they didn't have related mandates from executives but they also have a lot of say in what goes in and what doesn't.
bmacho 8 hours ago [-]
> Why would Google executives want to stop it?
Google and Mozilla executives. The 'why' is not public knowledge. Maybe someone has a personal vendetta against some people involved in jxl.
surajrmal 11 hours ago [-]
It's interesting how different theories come about when there is a lack of information and a high degree of preexisting bias. Reality is a lot simpler - it wasn't deemed worth the cost of addressing the security problems in the existing library so someone chose to abandon the format. However as industry adoption increased and a newer safe library appeared, the decision was changed. Also, note that while Google developed the new rust library, it wasn't the chrome team who made the investment.
F3nd0 10 hours ago [-]
> Reality is a lot simpler - it wasn't deemed worth the cost of addressing the security problems in the existing library so someone chose to abandon the format.
As evidenced by what? When first rejecting JPEG XL, Google did share their reasoning, but security problems hardly figured in it.
pmarreck 11 hours ago [-]
My guess is that Apple supporting it natively in iOS (there's an option in iPhone 16+ to save taken photos as JPEG-XL instead of Apple's proprietary format) likely also pushed the needle
etatester 11 hours ago [-]
You made me check. iOS only supports JXL in ProRAW mode, which (I hope) most people don't use.
giancarlostoro 9 hours ago [-]
Doesn't that mean you can natively render JXL anyway? Which is what I think they were suggesting.
moebrowne 8 hours ago [-]
I think it might have something to do with a Rust based decoder becoming available. IIRC one of the reasons for not implementing it before was expanding the attack surface.
nikanj 11 hours ago [-]
They added enough fear/uncertainty/doubt around jpeg xl that no sane organization will adopt it now. God Google might decide to remove support again in 2027
SillyUsername 11 hours ago [-]
I thought the reasoning was Google wanted to cartel their own fledgling webp format and didn't want to promote competition?
JimDabell 11 hours ago [-]
WebP is 15 years old, and Google cares about it less than anybody else. Pretty much everybody else supports WebP but Google can’t even be bothered adding support for it to Google Docs.
mda 11 hours ago [-]
Google is one of the main developers of Jpeg XL.
tniemi 12 hours ago [-]
Watching the example image load I had this flashback of the past, where images were 256 color interlaced GIFs, downloading slowly, line by line...
etatester 11 hours ago [-]
I have a feeling that progressive loaders got downgraded along the way for whatever reason. I remember seeing progressive JPEGs and PNGs also load... progressively. JPEG even often had a grayscale-like first layer.
yangm97 9 hours ago [-]
Yeah, the conservative loaders took over.
I’ll see myself out.
Synaesthesia 12 hours ago [-]
So it's supported now by all the major browsers (Firefox support coming soon) as well as all the major OSes.
pmarreck 11 hours ago [-]
I believe it's been available in Firefox for a while now, just behind a feature flag
Next up: Phones and cameras. It would be so great to have a common image format again after years of fragmentation.
arthur-st 10 hours ago [-]
iPhones have supported it for 3 years.
lxgr 9 hours ago [-]
Taking photos in JPEG XL? That's what I meant; the consumer side is nice, but if everybody keeps taking AVIF, HEIC, and JPEGs, we're missing an important part. (Sure, smaller websites are nice too, but I can have that today with WebP, as CDNs need to serve multiple formats anyway.)
eviks 9 hours ago [-]
Took them long enough with a few embarassing detours, but a welcome news nonetheless! Has anyone ~blogged about some of the internal dynamics that lead the G ship to course-correct, would be curious to read?
cube00 9 hours ago [-]
I doubt anyone that wants to keep their job in big tech would ever publish something like that.
Nice. I added support for JXL to a low traffic chan board after Firefox added experimental support. I would honestly be surprised if anyone ever upload anything in that format but I can see some use cases for it after reading this thread. I am curious if some day JXL would ever be as popular as JPG or PNG and what would drive that change. Art sites perhaps? Maybe DeviantArt could add support for it.
Broiler9437 7 hours ago [-]
Art sites get the biggest gain with JXL. They can losslessly repackage every single JPEG uploads they have for practically zero cost. Existing PNG can also be losslessly compressed to JXL too, and just wrapping JXL around PNG yields improved compression (Note for last part: it is still in proposal status)
herf 8 hours ago [-]
I love the codec and am glad to see it supported again. They overcame the security issues using a rust SIMD port. I wonder what "approximately as fast as the best non-memory-safe alternative" means - the wording suggests they didn't beat the C++ implementation, but how close is it?
mort96 8 hours ago [-]
Here's a benchmark over time of jxl-rs (Rust) vs libjxl (C++) across both memory usage and performance: https://jxl-rs-perf.lucaversari.it/. I'm inclined to trust that it's a decent benchmark since it's from Luca Versari, a key person in the original JPEG XL standardization effort and development of libjxl, and is now the main developer of jxl-rs.
Seems to be between a little and a lot faster in almost all of the tests.
herf 5 hours ago [-]
looks great - jxl-rs is faster since June 2026 (using just a bit more RAM)
boutell 11 hours ago [-]
Are they switching it on in Android Chrome? That would complete the picture of at least baseline support... eventually... when a decent percentage of Android phones actually get that version.
But Safari (MacOS or iOS) still doesn't support the progressive rendering shown here, nor animation, if caniuse is up to date:
Not to be a downer — it's one necessary step on the road.
Waterluvian 8 hours ago [-]
I'll kind of miss (not actually) the early 2000s codec vibe I get when I share an image with people on Signal and half of them say, "I can't view it."
Evidlo 9 hours ago [-]
Wanted to use this for building a viewer for astronomical imagery but the decoder resamples to 8 bits internally unfortunately.
Have to stick with AVIF which supports up to 12 bits.
arikwald 5 hours ago [-]
Excellent, I wanted to ask whether this release will support in Android WebView and iOS WKWebView components as well? Or only the Google Chrome browser will support this feature?
gen2brain 11 hours ago [-]
After some time, this seems to be the first image format, now in production, not being just the nus product of some video format.
tsuru 9 hours ago [-]
Any way for those who enjoy dynamic languages (non-Python) to call it via FFI?
anonymous344 7 hours ago [-]
how about an option to block that "update address?" dialog on domain basis???
chuliomartinez 9 hours ago [-]
Is jpegxl support in canvas toBlob planned?
codingjoe 12 hours ago [-]
Is this the same patent/license nightmare as JPEG2000 ?
videah 12 hours ago [-]
No, JPEG XL is an open standard.
201984 11 hours ago [-]
"open" in the sense that you have to pay $200 to read it, anyway.
codingjoe 12 hours ago [-]
That's good to hear. Let's hope there's hardware adoption on the camera end soon. As an image lib maintainer the codec wars were driving me nuts.
llm_nerd 6 hours ago [-]
Kind of orthogonal, but note that JXL creation tools are still uneven. Affinity, for instance, has terrible JXL creation. I don't know what they're using, but it's glitchy, and yields horrible compression levels relative to the quality, and I know a number of people that were soured on JXL purely because Affinity is a poor source for it.
For that tool you need to output an uncompressed target and use the reference command line tools, preferably libjxl and cjxl (which is still the reference, while jxl-rs remains the experimental), to create the JXL. You will have better compression with better quality, minus the glitches.
shevy-java 11 hours ago [-]
About three years ago I had to find a replacement for old .jpg files and .png files.
The main two contenders were .avif and .webp. For a few reasons, I selected .avif and in hindsight I think it was the better, choice. Both would be objectively better than jpg or png.
With JPEG XL ... hmmm. AVIF is not perfect, in particular when the compression rate is very high I noticed that some photos lose a lot of intrinsic quality that is not instantly obvious; I noticed this when I took various pictures over the years from outdoors. Still, AVIF beats jpg and png just about on every metric when compression is required. With JPEG XL I guess I have to re-evaluate, but right now I am still sticking to avif. The two factors that will be important for me is compression ratio and quality. I am ok with a bit of loss of quality, if the compression is better, but I am not sure JPEG XL beats AVIF here clearly either, so I am not sure what to do with JPEG XL.
F3nd0 9 hours ago [-]
Both JPEG XL and WebP far exceed AVIF when it comes to lossless. For lossy, AVIF used to do better at low quality and JPEG XL at high quality. But apparently AV1 encoders have improved a lot since then, closing the distance. An article comparing the two was posted recently:
The author, who has worked on said AV1 encoders, has expressed doubt that JPEG XL encoders could improve much with only reasonable amounts of effort, but that was also only their personal (if educated) guess. With JPEG XL finally seeing adoption on the web, we will hopefully see work on the reference encoder resume in earnest soon.
So for now, I’d say you’re fine with AVIF. Unless you’re doing lossless, because AVIF sucks at lossless. (And JPEG XL has the unique feature of supporting lossless JPEG transcoding, too.)
sylware 12 hours ago [-]
I thing the endgame is lossless PNG with 16bit color components with basic compression like gzip or at best bzip2. Or a format without the weirdness of PNG 'line based loading' which is obsolete nowdays. The "expensive part", apart from the compression algorithm, being the meta data storage without kludge.
mrob 12 hours ago [-]
>without the weirdness of PNG 'line based loading' which is obsolete nowdays
How? Line-based loading is a very simple way to exploit 2D spatial coherence. A 1D format like gzip loses this advantage for minimal gain in simplicity.
groundzeros2015 7 hours ago [-]
You can’t just ignore signal compression algorithms unless you are fine allocating 4-5x more bandwidth to images.
pmarreck 11 hours ago [-]
I believe 7zip outdoes bzip2 these days along every metric
And lossless jpeg-xl exceeds your idea
ciupicri 9 hours ago [-]
7zip meaning what, LZMA (xz)?
dist-epoch 8 hours ago [-]
and zstandard outdoes 7zip (LZMA)
apopapo 12 hours ago [-]
These days I favour lossless WEBP instead of PNG. I often save around 30%~40% of file size compared to PNG, especially when the PNG is encoded with lots of bits per pixel (i.e 48 bits or 24 bits).
F3nd0 9 hours ago [-]
I think that’s why they were advocating for gzip or bzip2 instead of just relying on PNG’s built-in compression.
atomicthumbs 3 hours ago [-]
how about lossless JPEG XL
rfgplk 10 hours ago [-]
Fun fact, I needed JPEG XL support for my C++ pipeline and I didn't feel like including any official libraries. Roughly $500 tokens later I had a fully working optimized JPEG XL spec compliant en/de/coder that outperformed the official codepaths (both cpp and rust) by 70% (lower runtime). Took literally 5 hours to build out. Can someone tell me what Google is doing?
groundzeros2015 7 hours ago [-]
So do you think your implementation is better? Or there are finer parts of the spec it’s missing?
Your llm has JPEG xl programs in the training data. You copied from GitHub.
dtf 10 hours ago [-]
Does it satisfy the rule of two?
BugsJustFindMe 9 hours ago [-]
> Does it satisfy the rule of two?
One to embody power, the other one to crave it?
I'm confused about the connection.
erikvanoosten 9 hours ago [-]
Two safety protection mechanisms. For example: Rust + Sandbox.
groundzeros2015 7 hours ago [-]
If it’s sandboxed why do I need rust?
What counts as a “safety mechanism”?
dtf 7 hours ago [-]
It's the "rule of two" safety guideline mentioned and linked to in the article:
If you use a safe language like Rust, you can afford untrusted input and no sandboxing.
If you use an unsafe language such as C++, you must chose between trusted inputs or sandboxing.
I was curious as to where rfgplk's implementation lay within the Venn diagram.
groundzeros2015 7 hours ago [-]
What counts as two safety mechanisms?
> you can afford untrusted input and no sandboxing.
I would not trust a rust program un-sandboxed! There are security bugs in rust itself.
rfgplk 8 hours ago [-]
Yep.
tristor 6 hours ago [-]
Now I just want Flickr to support uploading JXL since I do JXL export as my primary long-term storage format for final images. Would be great if Canon also added JXL support to their photo printer software.
8 hours ago [-]
mschuster91 11 hours ago [-]
> built-in HDR support
Oh hell no. HDR is already bad enough in Youtube on iOS where there seems to be no way to turn it off - you tune your brightness to something decent in bed... and then some video by some showoff dingus scrolls across the feed frying your eyeballs.
Fuck HDR or at the very least give people an option to turn it off!
this does not help me against malicious or incompetent website authors. Mobile browsers usually do not have support for user stylesheets.
nemomarx 9 hours ago [-]
Mobile Firefox let's me add Stylus and I assume other extensions like whatever the modern Greasemonkey is. So at least one of the good mobile browsers does support it.
If you're using a mobile browser without extension support, you should tell the devs of it to work on that.
k12sosse 10 hours ago [-]
I will say windows implementation of HDR - at least the way Chrome handles it within Windows is somewhat of an abomination - so I'm sure Apple's iOS is just as poor!
but sometimes it's not HDRs fault - it's just the segura effect. People with cameras exceeding their capability levels, not understanding what you need to do after you shoot video in LOG.
I mix multi-monitor some-HDR some-SDR in Windows, it's bad.
yangm97 9 hours ago [-]
Nah iOS really cranks up the screen brightness to display HDR content.
k12sosse 5 hours ago [-]
Interesting. That's one way to get the nits difference between black and white :/
AVIF is still better at 1 bit per pixel and less. (JPEGXL is more efficient at more than that.) Is it possible for JPEGXL to beat that?
adrian_b 9 hours ago [-]
I do not know if JPEG XL is competitive with AVIF for very compressed images, because that is mostly a concern for those who want to host at a minimum cost Web pages with embedded images. I assume that AVIF must be better for that purpose.
On the other hand, AVIF cannot compete with JPEG XL for high-quality photographs, which is something much more important for me, because it is a format suitable for storing my own photographs and it is a format that would make me appreciate positively a Web site that would have beautiful images in this format.
gcr 12 hours ago [-]
That isn’t my experience. I tried compressing conference proceedings into thumbnails with tiny file size and for this purpose I found that JPEGXL is far better than AVIF
mococa 12 hours ago [-]
They need to relay on Rust to write safe code…
r_lee 12 hours ago [-]
is that a bad thing?
mococa 6 hours ago [-]
Everytime someone in the world tells the truth about Rust, a lot of "crustracians" went bad...
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.
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.
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.
I'm assuming that for more persistent, cachable types of images, there wouldn't likely be that type of problem, right?
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.
https://groups.google.com/a/mozilla.org/g/dev-platform/c/3YM...
"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."
Years ago, both Chrome and Firefox had experimental support. In October 2022, Chrome suddenly announced their decision to drop it (citing dubious reasons like lack of interest or improvements over existing formats). [1] It was only later, in January 2023, that Mozilla announced their formal position of not really caring about the format. [2]
In October 2023, one of the JPEG XL devs said that the responsible team at Google was ready to write a decoder in Rust if that was the only reason holding adoption back, even offering to work on browser integration. [3] One month later, another dev confirmed that a different pre-existing decoder written in Rust was already standard-conformant. [4]
It wasn’t until September 2024, nearly a whole year later, that Mozilla changed their official position from not caring to waiting for a suitable decoder written in Rust. [5] And it was only then that jxl-rs development really picked up. [6] Only later on, Chrome decided to change their position as well, but we can only speculate on what actually changed their mind.
There was no Google shoving JPEG XL down everyone’s throat like they once did with WebP. There was no Mozilla taking a clear, principled stance from the get-go. Whether or not JPEG XL was worth it, neither of these companies has acted in a transparently fair, exemplary way. And of course the first major browser to ship JPEG XL support to users was Safari, which may well have played a role in the others’ decision-making.
We may not be able to say for certain, but Google’s massive influence is by far the most plausible explanation I can think of. And if the first step in your decision making is looking at what Google is doing, then ‘following marching orders’ is suddenly not such a bad description. (One can argue that with 3 % market share they don’t have much choice, but that’s beside the point.)
The case against JPEG XL https://giannirosato.com/blog/post/case-against-jxl/
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
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!
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.
WebP and AVIF and HEIC had similar advantages but also some disadvantages (honestly chief disadvantage to WebP in my humble opinion was that nothing except web browsers -- to this day -- seem to support it!).
Another important point in its favor is that JPEG XL is designed as a royalty‑free, open standard, and Google provides a perpetual, worldwide, royalty‑free patent license for its reference implementation.
Avoiding JXL (once the rollout is sufficiently complete) seems, to me, like still shipping (non-animated) .GIF files where .PNG is better and smaller.
Even if it cannot, getting the same quality as 'classic' JPEG in fewer bits is still useful. So you have:
* better quality in the same number of bits
* same quality in fewer bits
But I’m sure there are some that will say 64k of RAM is all anyone will ever need!
Things in these categories have colorful packaging with spot colors, metallic inks, coatings, as well as store displays with carefully designed lighting. The added cost is justified because it increases sales. It makes sense to carry that over online.
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.
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.
TIFF is not simple at all. There is a joke that it stands for “Thousands of Incompatible File Formats”.
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.
For me now, its marginal.
For a past customer, not at all. That customer really cared about delivering image-heavy pages quickly. There was a fairly big difference in customer perception at a timing threshold.
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?
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.
[0]: https://github.com/dropbox/lepton And Lepton is dead.
JPEG XL is marketed as a high end format for photographers and already has support in most editing software.
The bees and reindeer visiting my web site will be very happy to see UV images.
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!).
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.
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
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.
I think JXL is a cool image format, but was being held back by the most popular browser not supporting it, limiting its use (in the web especially) by a lot.
[1]: https://issues.chromium.org/issues/40270698
I have a feeling now JXL is here to stay, finally.
I have to think this is a substantial reason for the backflip here as adding a new huge C library to browsers is a huge concern.
More likely the Google eng. director who tried to get rid of it because of not-invented-here syndrome (it was built in a different org) got a new job or changed company.
https://security.snyk.io/vuln/?search=libjxl
I remember Project Zero cautioning Google's browser team against adding insecure decoders/encoders.
Somebody could think of the web as primarily a platform for consumption, in which case it is OK for it to support a limited number of formats, actually desirable because it reduces the attack area.
Another is that the web is connected to general purpose computing in which that case the web browser competes with GUI shells (e.g. explorer, finder) and should be able to support every image format that is commonly used on the platform.
Back in the 1990s most platform supported a lot of file formats that weren't JPEG or GIF but browsers didn't support them and only a small set of formats have been added since then.
A long time ago I ran some sites that hosted large image collections and I struggled with costs so I did a lot of thinking about how to optimize storage and transfer. I came to the conclusion about 5 years ago that WebP is consistently a win over Jpeg, but I've never been a fan of AVIF. Yeah, it does great for big blog hero images that people don't look at closely, but it makes my mirrorless shots look like they were shot on a cheap Android. Yeah, I've seen that picture of the F1 car and it is superficially impressive but if you look closely at the highlights you can see that it erased the real highlights and replaced them with something plausible but... different.
I'm on the other side, I hate webp because if I download such an image a lot of apps don't support it. So typically I need to screenshot it instead to get a usable jpg/png.
Now one more format to hate.
I would say webp/jxl/avif is anti-general compute, since they require very recent software.
I know that end-users making memes or whatever aren't a demographic that will matter for adoption, but it seems really weird that this is still a problem on Windows and Mac in 2026. I've searched for browser extensions to no avail.
I just tried it out now, using Waterfox on macOS 27. The save image dialog literally already has a Format dropdown. But I'm guessing it's just a weird part of some native dialog, it lets me select between "WebP Image" and "All Files". This kind of design could've been used to allow the user to save it as a different format than what it was served as.
If you have support for multiple file types, you're already using multiple libraries or you're using a library that handles several kinds of file, either way you can and should update that.
Imagine if installing libzstd meant that every program on your computer suddenly knew how to use ZSTD compression, or adding libjpegxl added support to every browser, word processor, and age editor you’d already installed.
Some parts of AmigaOS were wonky, like lack of memory protection. Others would still be phenomenally useful today.
https://developer.chrome.com/blog/jpeg-xl-in-chrome#safety_f...
right?
While I'm happy for the reversal, it would be helpful to have a corresponding explanation addressing what changed leading to this reversal just two years later (assuming the decision to support was made 9-12 mos ago). Since significant decisions are usually harder to make in big companies (due to many competing prioritities, stakeholders, and processes), they tend to also be harder to reverse (especially in just two years, when most of original deciders are still in the same roles). I suspect the real thing that changed is more interesting than "the technology or people changed" or "our prior assessment was wrong".
Removed because no one from Google benifits from supporting it then.
Re-added because someone could get a promotion by supporting it now.
Do you mean the users of the browsers not benefitting, or specific Google employees/stakeholders?
They always abandon shit like this.
Google apparently wanted to be one of the "cool kids" supporting AVIF. When they removed the JPEG XL code from Chrome, they created the excuse that there was little demand for it, along with some other disingenuous talking points that didn't quite make sense. Ironically the project that ended up becoming JPEG XL was started by Google employees in Switzerland.
Anyway, I’m glad Google is supporting JPEG XL now. I wanted to use JPEG XL files for a project I started a month ago, but it was a non-starter with global usage under 20% at the time.
Another giant codec is only a huge risk if you run the decoder in the renderer process, which they say in the linked thread they do, but I don't see a sane reason why.
I'm sure if they asked the secret Gemini 4.0 AGI to use their existing very good sandbox to throw all the decoders in their own process and only share the image buffers, it could do it in a few hours.
Removed because trillion dollar advertising company don't bother, which also happens to be the browser vendor monopoly.
How many man-hour effort does it take to create jxl-rs ?
https://github.com/libjxl/jxl-rs/graphs/contributors
Flashbacks to DataTypes on the Amiga: https://wiki.amigaos.net/wiki/Datatypes_Library
I got my A1000 in late '85 and only had prior exposure to 8-bit home computers (C64, Atari, etc), CP/M and DOS (no mainframes, minis or workstations). I didn't actually use Macs or early Windows until the early 90s and it was shocking how backward they still seemed in some ways. I'd sort of the assumed the other major platforms were making similar advancements throughout by the late 80s and shocked to find out how wrong I was. It wasn't until the mid-90s that PCs and Macs felt like they mostly caught up on QoL and OS features.
That's how it works on macOS; the bundled apps (Preview, Photos, etc.) gained support for JPEG XL.
I saw this recently with Balena etcher. It's a firmware flashing app with about 10 buttons total. It's over 400mb because it's written in node and has an electron GUI.
Good jerb.
My life improved measurably after I contributed that '-o' flag to pv and it then made its way into all my systems through regular OS updates :)
Another example clown app: the MacOS downloads of TuxGuitar, a Java app, used to just ship as a zip with a big jar in it. Now it ships an entire Java Runtime environment specific to your processor architecture. It's 480MB. Derp.
MacOS used to include Java out of the box, and then they stopped doing that. How else should an app reasonably behave to keep supporting new versions of the system?
What you're saying is it's the ideal kind of application for not obsessing over its background resource consumption, given that it's only going to be running for 10 minutes once or twice a year.
The thing is that it's still just a library, it just happened to be pre-installed. CGImage is just a helper in the Core Graphics library, not some magical "native"/"core" functionality in the OS that would be different than any other library with the same features.
An equivalent library for Linux (glycin for example), or per-format libraries like jxl-rs, are not "included in the OS", and tend to be the very same libraries one would use for Windows. If that does the trick on most platforms, then why have the maintenance burden of doing something different on macOS if all it does is save a few bytes on disk?
From Google's perspective, they would likely not want Chrome for macOS to gain support for jxl as the sole platform anyway, even if they are using CGImage and could decode it that way...
Browsers have also largely switched to handling most aspects of TLS and certificates themselves, despite there being OS libraries for those as well; the same applies to HTTP.
Shared libraries are a bad idea that is simply taking way too long to just die the horrible death it deserves.
Static linking is one and done, headache gone. People have large drives these days, so it's not a problem.
There are areas where the browser will dynamically link, but those are more OS-related than image and file format codecs.
Google set to deprecate JPEG XL support in Chrome 110 - https://news.ycombinator.com/item?id=33399940
JPEG XL support has officially been removed from Chromium - https://news.ycombinator.com/item?id=33933208
Chrome Jpegxl Issue Reopened - https://news.ycombinator.com/item?id=46033330
The case agains JPEG XL - https://news.ycombinator.com/item?id=49690554
The wider ecosystem support is still far from commonplace, but it is slowly changing. iOS 18 wouldn't work with .jxl in Photos, but 27 does. Similarly, quick look and preview works fine on MacOS 27, thumbnails show up properly etc. I also found no issues with .jxl on linux, and image editors are slowly adding support as well.
Plain old jpg will still be everywhere for the next decade, but I'm glad that we finally have superior options with no real downsides, and without all the patent bullshit to boot.
Personally I fully expect jxl to succeed where avif failed and webp floundered.
Seems like terrible branding if it wants to be taken seriously as a standard.
And much (though not all) of its improved compression (before it damages the image too badly) was anyway matched by the better JPEG encoders which were released and improved over time. It sure benched very well against a 30+ year old JPEG encoder implementation though.
JXL has a pixel-accurate JPEG-input mode with no generation loss which already beats WebP, a native mode which is way way better even, it addresses many more use cases and is not Google's pet project (saying this while thanking them for all the foundational work from which modern image/video codecs benefit - JXL itself first and foremost!) so it DOES have better than a snowball's chance in hell of becoming the defacto standard of the next 10-30 years and we'll soon see it in silicon.
Discord Mobile absolutely supports animated WebP (in fact I just tried uploading one to make sure I wasn't hallucinating here).
The non-exhaustive table linked below shows how long it took for different programs to support different image formats since their introduction. Outside of Chrome, Chrome in disguise, and whatever has become of Firefox, adoption of JPEG XL has been far more enthusiastic than it ever has for WebP—or AVIF, for that matter. So we are very unlikely to have a long period when JPEG XL only works on the web and nowhere else.
https://cloudinary.com/blog/2026-the-year-of-jpeg-xl#_strong...
This is pretty wild. Google can't align their own tools for it?
Nothing wrong with that per se, it's just old and limited, especially compared to avif/AV1 which would be like a theoretical VP10 at this point.
E.g. Telegram still doesn't have sane support for .webp, it treats them as stickers. MacOS can take a long time to update with support for new formats. Image viewer apps even longer, many never updating to support new formats.
Other than the complexity of its implementation, there is very-little-to-no business nor technical reason not to use it or include it.
It has every right to be "the" image format for the next 20-odd years. Excellent compression, excellent lossless mode, transparency, etc. etc.
And probably my favorite feature- progressive rendering, which means you never have to make thumbnails ever again, you just truncate the output stream at the right proportion of pixel data (!)
iOS also now supports it natively for the photos it takes... but only if you have a newer iPhone than mine (a 15 Pro Max).
When literally every OS already comes with a form of libjxl pre-installed there is no good reason not to add support for it.
> you just truncate the output stream at the right proportion of pixel data
Does the format have explicit support for this? As in, is there any easy way to do, say, an exact Range request after reading the file header?
Worst case scenario you should be able to add some smarts to the server and a query string such that the client can request 5% of the file or whatever simply by fiddling with the url.
Let's say JXL does progressive decoding by encoding the image as a checkerboard (it doesn't but for the sake of argument): First you send the average of each 8x8 block, then you send the adjustments needed for the 4x4 blocks within that, then you send the adjustments needed for 2x2, and then 1x1.
If the client knows that it is going to display the image at a low resolution, anything beyond 8x8 might be completely useless, so it would be valuable to know where the 8x8 section starts and the 4x4 section begins. Under-guess and you don't have all the data needed to display it, over-guess and you're fetching data you are going to throw away.
This makes it very useful if it is trivial to analyze the image to determine that, say, the first 5kB are needed for 500x500px display, the first 150kB are needed for 1000x1000px display, and the full 500kB for 2000x2000px and above - either to dynamically generate a <picture> srcset server-side, or to have the browser determine when to abort the fetch after parsing its header.
The same could be said for .webm, but Apple refused to support it because they wanted to patent-laden alternative to thrive.
Where do people get this stuff?
Apple finally supported WebP in 2020, 10 years after it was released by Google. Firefox added WebP support in 2019, a year before Safari. Was Mozilla also part of conspiracy to undermine WebP? Come on now.
Seems to me neither Apple or Mozilla wanted to be forced to support a format they had no say in developing. Usually there's a process for coming to consensus on standards.
WebP is ubiquitous now, not the case in 2010 when it was released.
It had advantages compared to JPEG, but not enough at the time to justify changing workflows, etc. WebP initially had better compression than JPEG, but as encoders/decoders improved (MozJPEG, Jpegli, turbo-libjpeg, Guetzli) the lead WebP had mostly went away regarding compression and visual fidelity.
Going forward, WebP is becoming less relevant by the day; it doesn't support wide gamut color; it only supports RGB. It's max pixel count is quite limited compared to AVIF and JPEG XL. Newer formats have use cases beyond the web; WebP doesn't.
Loading vs loaded difference needs to be clear.
It's an attack vector for images to have different thumbnail/first bytes than the final image so software still have to decode the whole image.
png/webp (just as jxl) can store thumbnail in their meta, but no operating system, gallery, browser etc uses that because it has no usage that is safe.
I am not sure how easy it is to create a jxl image that starts differently from how it ends. If it is super easy then I expect programs not relying on it for thumbnailing (especially that they already have a way to generate and store thumbnails). Maybe browsers will support progressive loading, but it has no use for local images.
Nothing is perfect and niche formats will always be necessary but I think JPEG XL has a good chance to become the USB of image formats.
The format is designed to be as general as possible, potentially replacing many common (JPEG, GIF, PNG) and professional image formats.
For example, JPEG XL supports pages (e.g. for comic books), layers (with variable frame sizes, positions and blend modes) and timed animations.
I have not read that many direct comparisons here.
Apple added JPEG XL support for macOS, iOS, iPadOS, and watchOS in September 2023 [1]; iPhone 17 Pro/Pro Max added support for JPEG XL Lossy and Lossless compression for ProRAW pictures last year [2].
When Apple adopts jxl-rs, Safari, Chrome and Firefox will use the same JPEG XL decoder.
[1]: https://webkit.org/blog/14445/webkit-features-in-safari-17-0...
[2]: "iPhone 17 Pro’s Camera Leap: JPEG‑XL, Cleaner Shots, and Pro Filmmaking Tools" - https://modernengineeringmarvels.com/2025/09/19/iphone-17-pr...
But it makes so much sense for Apple, Mozilla, and Google to support jxl-rs. Of course, that doesn't mean it's going to happen.
Keeping quiet and then adding jxl-rs to a dot release like Safari 27.4 or something is also a very Apple thing to do.
The Linux/FOSS world kind of approximates this just because applications are often built against the same underlying libraries and utilities, e.g ImageMagick or FFMpeg, rather than implementing their own import/export filters, but it'd be nice to be able to install a single system-wide datatype library for a specific format, and have all of my existing software instantly be able to read and write it.
If you reencode a jpeg to a png, you used a lossless format but your image is very lossy.
But it's also a valid point.
JPEG artifacts are literally a meme, normal people are aware of this stuff.
I hold the extremist view that had we decided to use .png for lossless webps, it would have been an overall net gain - in people's minds "png" maps roughly to "whoever last touched this image didn't do anything evil to it" - very few people care how the data is actually encoded.
perhaps use .ll.jxl to indicate "lossless jpegxl" informally?
prior art: I've been using .frontmatter.md or .fm.md for markdown files with frontmatter
Like, you can do this individually, but it's not the same thing as actually having it in the standard.
But people are definitely going to assume "eXtra Large". Lots of people. I guess a few will think "excel" (as in JPEG XL comes out ahead and is superior).
---
[1] https://en.wikipedia.org/wiki/JPEG_XL
Does the one at the end of .JXL count toward the total? Nobody knows what it stands for anyway.
(You know... for "Wumbo")
Like files.tar.xz may be decompressed with xz and then extracted with tar to get the directory "files".
I think in your case .md.fm would be a greater fit, as the front matter is read first. Or just .fmd
Sadly, still far from adoptable today's web: https://caniuse.com/jpegxl = 17% https://caniuse.com/?search=webp = 97%
Anything below ~90ish% is no go, unless i have a fallback strategy of some sort.
Are you saying that the percent it'll be in six months isn't relevant to you, or something? You'll probably be working on most of the same projects, even. If you do care about the future then yes caniuse is missing that point.
> Anything below ~90ish% is no go, unless i have a fallback strategy of some sort.
Once a few more versions of chrome roll through it'll jump up to almost 80%, and you can have a fallback easily.
It absolutely is relevant.. but only in about 6 months :)
Suppose the obvious case, i have some resizing pipeline for images. Would i include support today in my resizing pipeline today and pay a few extra cycles and storage for someone that my clients can't read?
It would be cool to have a subscribed alert for when the tech crosses a certain % threshold adoption so i can look at it again, otherwise it just relies on my brain's flawed long term cron job
Yes, this is literally what the <picture> element is for.
Your hypothetical pipeline would be able to convert <img> elements into <picture> elements with multiple <source> elements for different user resolutions and format supports.
My guess: the engineers didn’t win the argument. The executives just gave up once all the other browsers had added support.
The big turning point seemed to have been Adobe adopting JpegXL as an approved image compression algorithm for the upcoming PDF spec. update. With that, since all browsers seem to also want to be PDF renderers, meant they had no choice but to include a JpegXL decoder. The win, if there was one here, was that the decoder they have to ship anyway now was exposed for use by <img> tags as well as by the PDF renderer.
JPEG XL is largely a Google effort including in creating the specification, the reference implementation and later a safer Rust implementation. Why would Google executives want to stop it? From what I gather it's Chrome engineers that didn't want it because it was huge, had little adoption (at the time), and was rather redundant with AVIF and WebP (for Web purposes). Not saying they didn't have related mandates from executives but they also have a lot of say in what goes in and what doesn't.
Google and Mozilla executives. The 'why' is not public knowledge. Maybe someone has a personal vendetta against some people involved in jxl.
As evidenced by what? When first rejecting JPEG XL, Google did share their reasoning, but security problems hardly figured in it.
I’ll see myself out.
Seems to be between a little and a lot faster in almost all of the tests.
But Safari (MacOS or iOS) still doesn't support the progressive rendering shown here, nor animation, if caniuse is up to date:
https://caniuse.com/jpegxl
Not to be a downer — it's one necessary step on the road.
Have to stick with AVIF which supports up to 12 bits.
For that tool you need to output an uncompressed target and use the reference command line tools, preferably libjxl and cjxl (which is still the reference, while jxl-rs remains the experimental), to create the JXL. You will have better compression with better quality, minus the glitches.
The main two contenders were .avif and .webp. For a few reasons, I selected .avif and in hindsight I think it was the better, choice. Both would be objectively better than jpg or png.
With JPEG XL ... hmmm. AVIF is not perfect, in particular when the compression rate is very high I noticed that some photos lose a lot of intrinsic quality that is not instantly obvious; I noticed this when I took various pictures over the years from outdoors. Still, AVIF beats jpg and png just about on every metric when compression is required. With JPEG XL I guess I have to re-evaluate, but right now I am still sticking to avif. The two factors that will be important for me is compression ratio and quality. I am ok with a bit of loss of quality, if the compression is better, but I am not sure JPEG XL beats AVIF here clearly either, so I am not sure what to do with JPEG XL.
https://news.ycombinator.com/item?id=49690554
The author, who has worked on said AV1 encoders, has expressed doubt that JPEG XL encoders could improve much with only reasonable amounts of effort, but that was also only their personal (if educated) guess. With JPEG XL finally seeing adoption on the web, we will hopefully see work on the reference encoder resume in earnest soon.
So for now, I’d say you’re fine with AVIF. Unless you’re doing lossless, because AVIF sucks at lossless. (And JPEG XL has the unique feature of supporting lossless JPEG transcoding, too.)
How? Line-based loading is a very simple way to exploit 2D spatial coherence. A 1D format like gzip loses this advantage for minimal gain in simplicity.
And lossless jpeg-xl exceeds your idea
Your llm has JPEG xl programs in the training data. You copied from GitHub.
One to embody power, the other one to crave it?
I'm confused about the connection.
What counts as a “safety mechanism”?
https://chromium.googlesource.com/chromium/src/+/main/docs/s...
If you use a safe language like Rust, you can afford untrusted input and no sandboxing.
If you use an unsafe language such as C++, you must chose between trusted inputs or sandboxing.
I was curious as to where rfgplk's implementation lay within the Venn diagram.
> you can afford untrusted input and no sandboxing.
I would not trust a rust program un-sandboxed! There are security bugs in rust itself.
Oh hell no. HDR is already bad enough in Youtube on iOS where there seems to be no way to turn it off - you tune your brightness to something decent in bed... and then some video by some showoff dingus scrolls across the feed frying your eyeballs.
Fuck HDR or at the very least give people an option to turn it off!
If you're using a mobile browser without extension support, you should tell the devs of it to work on that.
but sometimes it's not HDRs fault - it's just the segura effect. People with cameras exceeding their capability levels, not understanding what you need to do after you shoot video in LOG.
I mix multi-monitor some-HDR some-SDR in Windows, it's bad.
50 times smaller than JPEG 2000.
AVIF is still better at 1 bit per pixel and less. (JPEGXL is more efficient at more than that.) Is it possible for JPEGXL to beat that?
On the other hand, AVIF cannot compete with JPEG XL for high-quality photographs, which is something much more important for me, because it is a format suitable for storing my own photographs and it is a format that would make me appreciate positively a Web site that would have beautiful images in this format.
Folks, it's just a tool