upvote
No, that was not part of the reason the Google Chrome team gave: https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc...
reply
There are very interesting values here.

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.

reply
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.

reply
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.
reply
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.

reply
Copy image puts a bitmap on the clipboard but nobody wants to bloat the menu with saving in alternate formats.
reply
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.

reply
Personally I get mad at the programmers who sit there not updating their image decoding library for over a decade.
reply
However many decades you wait, libpng is not gonna add support for WebP
reply
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.

reply
We had plug-ins to support them all.
reply
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".
reply
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.

reply
that's what firefox said, not chrome
reply
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.
reply
Probably why Google implemented their own decoder in Rust

https://developer.chrome.com/blog/jpeg-xl-in-chrome#safety_f...

reply
“Their own” is a bit misleading. It’s largely a subset of the people who implemented libjxl in the first place, but this time in Rust.
reply
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?

reply
The top three contributors to the reference implementation are also Google employees. https://github.com/libjxl/libjxl/graphs/contributors?all=1
reply
That’s what I was getting at, yes. (I contributed to both and am sitting with another core contributor right now.)
reply
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".

reply