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

JPEG XL had so much going for it. Kinda sad it was killed off just like that.

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.

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.