The JPEG XL Image Coding History, Features, Coding Tools, Design Rationale

It wasn't "killed", it was always disabled by default in Chrome, and removed for really quite reasonable reasons: literally every other image decoder has had serious vulnerabilities. Enabling it by default would expose a gigantic attack surface that almost certainly will be exploited sooner or later.

This is also why Firefox doesn't support it by default (IIRC it doesn't even link against libjpegxl by default in release builds – only nightly ones).

There is nothing preventing the Chrome or Firefox people from revisiting all of this in the future.

It seems to me the Rust implementation of JPEG XL is by far the best path forward for broad JPEG XL support in Firefox, Chrome, and other browsers. While Rust is of course not a complete guarantee there will never be any security issues, it does eliminate virtually all of the major exploits that have targeted image decoders in the past. Both Firefox and Chrome have expressed interest in this.

And because they wanted to push WebP

...which overall is a pretty mediocre image format.

VHS was a pretty mediocre medium for video. It didn’t stop JVC.

WebP got added about 15 years ago or so. Chrome (and Firefox) learned the lessons from the problems that caused.

And "push WebP" for that purpose? Google as a whole benefits hugely from reduced image sizes.

Firefox also doesn't implement JXL as I mentioned. Are they trying to "push WebP" too now? This is such conspiratorial nonsense. No evidence for it at all. Doesn't even make any logical sense. Google literally worked (and continues to work) on JXL.

if anything is being pushed these days, it'd be avif

WEBP is two image formats bolted together.

First, there's Lossy WEBP, based on VP8 video compression. It is better than JPEG, but mediocre by today's standards. Lossy AVIF and Lossy JXL greatly outclass lossy WEBP.

Second, there's Lossless WEBP, which is not in any way based on VP8. Lossless WEBP is a stellar image format that not only compresses very well, but also decompresses very quickly. Its biggest competition is Lossless JXL, which usually compresses to a smaller file, but decoding that image is slow enough to be annoying. Sometimes lossless WEBP produces a smaller file than lossless JXL.

Then why did they develop libjxl, and why are they working on jxl-rs? https://github.com/libjxl/libjxl/blob/main/AUTHORS https://github.com/libjxl/jxl-rs/blob/main/AUTHORS

Maybe their stated reason for not enabling support in Chrome is the actual reason.

Yes, you are right that the lossless format is much more notable but also much less common than the lossy one. It is quite an improvement over PNG which is the only real competitor on the web.

Thank you. I agree with the sentiment that WebP lossless has stand the test of time better than WebP lossy. In some comparisons even Jpegli is more attractive from compression density point view than WebP lossy.

Disclaimer: I am the designer of WebP lossless and Jpegli.