jaffathecake

A fix is being released. Thanks for reporting! https://blog.mozilla.org/security/2026/10/20/protecting-fire...

Yep. Look at the replies. He's challenged on it, and doubles down. It's not a joke.

The Cloudinary one is written by one of the leads of the JPEG XL project.

I disagree. Making things slower for everyone due to this edge case is a bad tradeoff. Web APIs exist to let you know when zooming in happens. You can swap to a higher resolution, or even tiled image in these cases if you really care about this use-case.

Browser vendors want their browser to be safe to use. If we encourage users to essentially bake their own browser from a hodge podge of unverified third party code running at high privilege, we don't meet that goal.

Plethora means an excessive amount, so I disagree.

Adding formats to the browser gives us more code to maintain, increases the binary size, and increases the attack surface area. That's why, at Firefox, we insisted on a Rust decoder.

Are you sure about that? Wouldn't that make the HDR example look bad in Chrome? The source image is 16 bit. https://jakearchibald.com/2026/jpeg-xl-vs-avif/#lossy---hdr

No. I'm working with Google on this. But you might be able to find a preview of the next version.

I'm not aware of any browser that cannot render AVIF 4:4:4. Given that avifenc outputs 4:4:4 by default, I don't expect that to change.

This is why I added the wasm fallback. The question was why I didn't serve PNGs to everyone.

That's what I'm talking about. JXL support landed in 158.

It's not mandatory. But if you don't use it, the browser may select a source it cannot play.

As someone putting an image on a web page, why would I make detection of artifacts easier?

The images in the article max out at the maximum size I'd want them displayed.

'high quality' and 'very high quality' are different things.

> AVIF images have a max size of 8192x4352

This isn't true btw. The format supports up to 64k x 64k, although browser decoders currently fail beyond 16k x 16k.

Not sure when you'd serve something like that on a web page though.

Sure but this is a technical post aimed at a technical audience.

It's an unreleased one. There's a whole section in the article about lossless, which includes data on those images, but not this mystery unreleased encoder https://jakearchibald.com/2026/jpeg-xl-vs-avif/#lossless

Happy to see your version of the cat illustration doesn't come with massive decoder overhead. Are you planning to open source this encoder?

tune=iq is the main bit https://aomedia.org/blog%20posts/Libavif_v1_4_0-Boasts-Major...

Oh, yeah, haha!

You're mistaking CSS pixels for device pixels https://jakearchibald.com/2021/serving-sharp-images-to-high-...

All browsers support AVIF and JPEG XL now. I was hoping to keep their download size benefits.

avifenc. The latest version.

Its creator (me) mentioned the smoothing as a negative.

Please read the article. All of the comparisons default to "high" quality, according to JXL's own metric.

jxl-rs is rust (used in Firefox and Chrome), and already faster than libjxl (used in Safari).

Offering different scalings is pointless because they're designed for a single largest size.

The original is a single photo.

Hmm, I haven't tested this, but I'm deeply sceptical. avifenc is now optimised very well for still images, and you're bypassing all of that here.

https://giannirosato.com/blog/post/case-against-jxl/ suggests JXL is fundamentally limited. We'll see. There's a race on and it's great!