Post

Great article. And it’s amazing how much both formats get out of a few kb. Honestly unless I zoomed in really, really close, and flicked back and forth I couldn’t really tell difference between low quality and the top one! 100kb is more than enough for most web images IMHO. And maybe even 30-50kb?

Jake Archibald@jakearchibald.com

JPEG XL has arrived on the web, but how does it stack up against AVIF? jakearchibald.com/2026/jpeg-xl...

jakearchibald.comJPEG XL vs AVIF for web use-casesJPEG XL has landed, but how does it compare?

John Mueller

@johnmu.com

FWIW if you're hoping to get images shown in Google Images & as previews in Discover, etc - JPEG-XL is currently not supported: developers.google.com/search/docs/...

developers.google.comImage SEO Best Practices | Google Search Central | Documentation | Google for DevelopersGoogle Search helps users visually discover information on the web. Explore image SEO best practices such as image captions and badges.

Barry Pollard

@tunetheweb.com

Good to know! But people should provide fallbacks anyway since it’s newly supported in Chrome and Firefox. I presume Search would similarly handle that in <picture> and via Accept-Encoding? Also presume Search will consider this now it’s become Baseline newly available!

John Mueller

@johnmu.com

The picture element includes an img element, so that would work for any search engine (or other page parsing setup). I have not heard of any problems with people doing this kind of progressive enhancement (I think it's "progressive enhancement" here too, right?).

15/10/26, 2:21 pm0 reposts4 likes

Barry Pollard

@tunetheweb.com

Yup <picture> has progressive enhancement build in! Providing you use it right of course. You could just have the <img> being a JPEG-XL format, but that would be kinda silly IMHO.