Why Google Is Removing JPEG-XL Support From Chrome

Following yesterday's article about Google Chrome preparing to deprecate the JPEG-XL image format, a Google engineer has now provided their reasons for dropping this next-generation image format. Phoronix reports: As noted yesterday, a patch is pending for the Google Chrome/Chromium browser to deprecate the still-experimental (behind a feature flag) JPEG-XL image format support from their web browser. The patch marks Chrome 110 and later as deprecating JPEG-XL image support. No reasoning was provided for this deprecation, which is odd considering JPEG-XL is still very young in its lifecycle and has been receiving growing industry interest and support.

Now this evening is a comment from a Google engineer on the Chromium JPEG-XL issue tracker with their expressed reasons: "Thank you everyone for your comments and feedback regarding JPEG XL. We will be removing the JPEG XL code and flag from Chromium for the following reasons:

- Experimental flags and code should not remain indefinitely
- There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL
- The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default
- By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome"

Good

[Anonymous Coward]

I don't use Chrome and I never even heard of JPEG-XL until seeing this article. As far as I can tell, it's just some more silly nonsense that someone dreamed up and shoved into a web browser because .... because fuck you, that's why.

Glad to see that one small bit of pointless bullshit is being removed. Hopefully this will become a trend.

Re:

[Anonymous Coward]

Glad to see that one small bit of pointless bullshit is being removed. Hopefully this will become a trend.

You'd end up with a no code web browser. As in, a zero byte executable. A softlink to your gopher viewer, maybe.

I wouldn't mind, really. Just saying.

Google Graveyard it goes

[Kisai]

This is why Google/Chrome should not be the browser people develop around, because Chrome will remove things without notice.

Do you know how god damn long it took MSIE to support PNG's properly?
Netscape supported PNG as of 4.04, because of the entire GIF LZW patent boondoggle.
MSIE supported displaying PNG's as of MSIE4 (1997,) but didn't display transparency until MSIE7 in 2006 (MacOS version supported in MSIE5.)

So it took 9 years for MSIE to catchup to Netscape Navigator.

JPEG-XL has only been out since 2021! How the heck is anyone expected to use JPEG-XL in the web browser if it's been out for less than a year.

Re:

[DontBeAMoran]

And with JPEG-XL not being enabled by default, most Chrome users wouldn't be able to display those images either. Web developers won't add support for something until most browsers support it by default, so it's a catch-22 situation here and Google are fully aware of that fact. So whatever reasons they gave, they clearly didn't want JPEG-XL to become a new standard.

The fact that they're also dropping WebP2 on top of that means they probably have something that they think is much better than both of those in

Re:

[arglebargle_xiv]

As far as I can tell, it's just some more silly nonsense that someone dreamed up and shoved into a web browser because .... because fuck you, that's why.

No you're thinking of WebP there, not JPEG-XL. Please update your records accordingly.

Re:

[Megane]

Nah, webp is silly nonsense that got shoved into web servers. More than a few times when I wanted to save an image, I had to go into about:config and turn off the "browser knows webp" option, then reload. There's nothing like saving a file with a name of ".jpg" or ".png" and it's a fucking auto-converted webp.

Re:

[arglebargle_xiv]

You can get extensions that will convert webp into something sane on download... my comment was a snarky comment alluding to the fact that Google forced the webp crap down everyone's throats because it's their format, while the JPEG-XL that they're discontinuing isn't.

Re:

[arglebargle_xiv]

Oh, forgot to add the webp is also a magical miracle format that tests as clearly better than the competition when Google is doing the testing but no better than the competition when someone who isn't Google is doing the testing. Such magic!

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:

[jonadab]

In other words, it's something we *could* use instead of PNG, if we had any reason whatsoever to stop using PNG, which we don't.

And don't even talk about slight improvements in compression rates. Websites send petabytes of javascript frameworks that are not even *vaguely* optimized, reducing performance on contemporary hardware to roughly what it was twenty years ago. The incremental benefits of slightly better compression on images would be a rounding error, and the cost of making hundreds of pieces of e

Better but Irrelevant

[crow]

So from the JPEG XL Wikipedia page, it sounds like they created a format that combined all the features of JPEG, GIF, and PNG, plus tossed in newer compression algorithms to get smaller files. So you can have animated images, lossless compression, lossy compression, and various other features, all using fewer bytes than older file formats. That sounds pretty good. However, everyone still uses the older file formats because every web browser supports them, and since we're well past the dialup days, the difference in bandwidth doesn't matter to most users. Who cares about bandwidth enough to invest in the coding to serve JPEG XL images to the browsers that support it to save bytes where possible, especially after considering the cost to code and maintain it? I don't suppose Google even bothered to use it for things like image search, maps, or YouTube thumbnails, all of which probably consume in aggregate tons of bandwidth.

So it's better, but irrelevant.

And since it wasn't catching on, best to yank the code in case some security vulnerability is discovered, which would be embarrassing for the browsers that included it.

Re:

[im_thatoneguy]

Especially since HEIC is actually broadly supported now on mobile.

Re:

[FickleTrickle]

HEIC is a patent nightmare though, so doubtful it'd get widespread support in browsers (though Chrome recently added HEVC decode, so who knows; I doubt Firefox would adopt it).

Re:

[thegarbz]

No one cares for the same reason no one cares about JPEG-XL. Image formats are not leaving anyone wanting. We have had better compression than JPEG available for well over 2 decades, but it's hard to beat good enough, especially in a world where bandwidth and storage is increasingly getting cheaper.

Re:

[FickleTrickle]

Those serving images could gain a fair bit from aggregate bandwidth savings, as well as reduced storage costs. Also helps those on metered connections. There's also other features JPEG-XL has, such as resistance towards generation loss, which is useful regardless of compression benefits. Finally, keep in mind that it was Google who pushed hard on their WebP format, despite criticism that it didn't really bring about much improvement (and had its own set of limitations, e.g. limited chroma subsampling sup

Re:

[DontBeAMoran]

You won't save storage costs if you also need to have older JPEG files around for older browsers or platforms that don't support the new format (ex: it took quite a long time for Apple to add WebP support in Safari).

For example, today if you still want to support older Safari versions, you would need to have JPEG, WebP and JPEG-XL files, which is almost triple the storage space.

Re:

[FickleTrickle]

today if you still want to support older Safari versions, you would need to have JPEG, WebP and JPEG-XL files

Or just ditch WebP, store only JPEG-XL and assemble JPEG on-the-fly (from the JPEG-XL source) when requested. So yes, you can get the full benefit of space savings.
(keep in mind that JPEG-XL was explicitly designed to be able to reconstruct JPEGs)

Re:

[DontBeAMoran]

You do save storage space that way, but you just increased the server load for 99.999% of users.

Re:

[FickleTrickle]

if you still want to support older Safari versions

you just increased the server load for 99.999% of users.

What website are you running where older Safari clients are 99.999% of your hits?
(of course, JPEG-XL adoption is mostly beneficial when most of your clients support it, hence the discussion here)

Even if none of your clients support it, depending on the access pattern, you could minimise server load increase if you can employ effective caching. I've done on a site where a lot of images are stored, but the vast majority of accesses only touch the latest images - most of these get served from cache, and on

Re:

[DontBeAMoran]

Your argument above was "store only JPEG-XL and assemble JPEG on-the-fly (from the JPEG-XL source) when requested".

Since the only browser that could potentially support JPEG-XL was Chrome but support was disabled by default, it basically means nearly 100% of users would request the regular JPEG file.

Re:

[DontBeAMoran]

edit: my post above was a reply to your "What website are you running where older Safari clients are 99.999% of your hits?", which I never implied was the case.

You're right about caching though. But since it looks like JPEG-XL will never become a Web standard, this discussion is pointless.

Re:Better but Irrelevant

[Waccoon]

Developers have wanted support for alpha channels in JPEG for... oh, about 30 years. The only reasonably modern file format with lossy compression to support that is WebP, which fucking sucks for a ton of reasons I won't get into here (I tried writing my own WebP parser before. I was shocked at how many hoops I had to jump through just to reliably get the width and height of an image).

Yes, we really could use something newer than PNG and JPEG. I'm sick of seeing people upload 30+ MB PNG files when the same image would be a 2 MB JPEG. Don't even get me started on blank alpha channels, which bloats image size for no reason and apparently is a pretty pervasive thing.

Google is just butthurt that JPEG XL uses some techniques from their PIK proposal, and people would rather choose an ISO standard instead of the ridiculously inconsistent, overly-complicated, and poorly-supported Google offerings. It's all politics and we all know it.

Re:Better but Irrelevant

[AmiMoJo]

A lot of those 30+ MB PNG files are because people use copy and paste, and Chrome always copies and pastes as a PNG. People often copy and paste images into forums and social media, and all those JPEGs become PNGs in the process.

Firefox keeps the image as a JPEG, even preserving the original filename. People have been complaining about Chrome's behaviour for years, but nothing has been done.

Re:

[Waccoon]

Well, I was specifically referring to artists posting digital artwork to online galleries, not people taking screenshots. Most art software will default to a JPEG compression level less than 80%, so JPEG files look terrible and artists will insist on using PNG files even when it's not appropriate for online galleries. Really, all software needs to be a bit more intelligent as to what formats to use and what compression levels to use for a given purpose.

Hence, my complaint about "blank" alpha channels. If

Re:

[drinkypoo]

Developers have wanted support for alpha channels in JPEG for... oh, about 30 years.

Serious question, have developers ever just asked for CSS support for a separate alpha channel image, a strategy that would work with any file format forever and ever amen? It seems like the obvious solution.

Re:Better but Irrelevant

[sg_oneill]

Nah. Heres the real reason:

Microsoft ratf*cked Google and the creator of ANS on a patent. To be clear, ANS existed BEFORE the patent, but then microsoft went and patented ANS even though it was someone elses creation.

https://jpegxl.io/articles/ran... [jpegxl.io]

Not the issue

[jensend]

No, the MS patent is not the real issue here.

MS recognizes that Jarek Duda did the initial work on ANS, their patent is supposed to be on a refinement/extension of the technique, and they have zero plans to use the patent against implementors of open formats like JPEG-XL. [reddit.com]

(Link is to Reddit rather than to the MS statement directly. That's because Duda, the inventor of ANS, is responding directly to your concern, and he interprets the MS response, which gives a little more weight to it than just the Polish ar

Re:

[Putins Boyfriend]

Fun fact: JPEG supported lossless mode before but nobody ever used it.

Re:

[thegarbz]

So it's better, but irrelevant.

And since it wasn't catching on

You just described the network effect. It's unsupported because no one uses it, and no one uses it because it's not widely supported. This is the reason why no new image formats succeed.

Of course Google could force the issue like they did with webp and webm and gather universal support by using it on their platforms. But nope.

Re:

[account_deleted]

Comment removed based on user account deletion

Re:

[crow]

I'm not sure why "you dumb twit" was called for, but leaving your immaturity aside, better has never been a guarantee for winning. It has to be not just better, but compelling. When existing solutions are broadly considered to be good enough, it's very difficult to get any momentum to shift to something better. The engineering cost of switching often outweighs any cost benefits of the better solution.

I haven't followed the various new image formats closely, but if it's widely agreed that this is the righ

Could security be an issue as well?

[shoor]

I've read where some of these image formats include executable code that has been used as an attack vector. Every new thing that comes down the road has to be vetted carefully in that regard.

Re:

[The MAZZTer]

There have been image decoders that have had bugs which lead to arbitrary code execution. The easiest way to smuggle in said code is in the image file itself somewhere. If that's what you're talking about, there's nothing particularly special about that attack vector, you could do the same with any image format with the right bugs in the image decoder.

Re:

[Gunegune]

Well up until the most recent release (v0.7.0) the JPEG XL reference implementation was focused on performance and quality improvements and was meant for evaluation purposes only. SECURITY.md explicitly stated, "At this time, we don't provide security and vulnerability support for any of these releases. This means that the source code may contain bugs, including security bugs, that may be added or fixed between releases and will not be individually documented."

The Security and Vulnerability Policy is much

Re: Could security be an issue as well?

[sectokia]

No, itâ(TM)s just lost to AVIF. Unless you have big content creators or big hardware ASIC no one is going to use the format, Compare jpeg XL to AVIF. AVIF came later, but got enabled in chrome earlier and is used by mega players like netflix and there is $$$$ in it.

Assholes

[locater16]

Complete assholery.,
There's no interest because YOU DON'T SUPPORT IT.
Dimwitted ass programmers that have never talked to anyone in media in their entire life are quashing the life out of any progress whatsoever. We sat there and got HDR support, a thing artists and creators love but can't use because drooling programmers keep doing shit like this. They only sit there and think in terms of what gets them the next promotion or if its worth it to save "a few bytes" because they're cooped up basement dwellers

WebP and AVIF

[NimbleSquirrel]

JPEG XL is effectively competition to the WebP and AVIF image file formats. Google controls the WebP standard, and is a member of the Alliance for Open Media which contril the AVIF standard, but Google have the same control over JPEG XL. I believe it really is that simple. Google have been quietly pushing WebP on users for a while now.

Re:

[Carewolf]

WebP isn't much of a format, it is like a proof-of-concept released too early. There are too many things it can't do right.

Just because they're removing it now

[John Allsup]

Just because they're removing it now doesn't mean they can't put it back if the format catches on. Though having just looked: I have GIMP which doesn't allow exporting to .jxl (yet, apparently support is in the 2.99 nightly); I have Affinity Photo which doesn't export to .jxl either. So at present I don't even have software that lets me create .jxl. It is perhaps too soon to really integrate it into browsers.

Re:

[DontBeAMoran]

For the web community to support something, browsers have to support it first. Google already supported it but decided to remove it instead of making it enabled by default.

As usual, flawless Google logic there, killing something before it has any chance of taking off. It's a miracle that company is still here today with such ass-backward decisions.

Re:

[bill_mcgonigle]

> As usual, flawless Google logic there, killing something before it has any chance of taking off

Their excuse is bad logic so you know that's not the reason.
JPEG-XL competes with Google's control of web standards.

And yet, if they enabled it

[Merk42]

You'd all bitch that it was bloat and JPG is good enough so why add yet another format???