> And 4:2:0 is just a poor fit for certain categories of images (like various kinds of illustrations, screenshots, etc).

I'd go even further and say that 4:2:0 is unsuitable for still images, period. Even for cases where it would be a suitable tradeoff for video. And even for video there's a significant chunk of content where it's undesirable.

In general I think we've come to accept some pretty gnarly limitations on image quality that really should not be such a given. 8 bits per channel is another one. You actually really do notice the banding with the naked eye in a fairly large range of situations, and if everything is 8 bits per channel then it gets really easy to exacerbate the problem on edit. Dithering in 8 bits per channel isn't really a solution because it's hard to do and it gets lost in compression quickly.

Browsers already fully support 4:4:4 AVIF and are not going to regress on this, as it would be a huge compat issue.

It isn't clear whether AVIF hardware decoding will ever be an advantage, but for video formats, Firefox and Chrome already pick between hardware and software decoders to ensure the content plays correctly. Safari is much flakier here, but again, for images, they're not going to regress on 4:4:4 AVIF support.

There have been a number of experiments to use hardware decoders for images in browsers, all of which have fallen flat; not even Safari does it for AVIF or WebP. Thus, 4:4:4 AVIF is supported absolutely everywhere. Feel free to try it now. I can see how hwdec is compelling for JPEG XL in theory, given how slow decoding is.

In the modern age image decoders need to handle untrusted inputs, and the big players rarely use hardware image decoding, even when it's available, because it's so hard to rely on its memory safety.

Several 'zero click exploits' have involved image/document format decoder bugs, as messaging apps and file browsers will often generate preview images the moment an image arrives.

Wait, DAIZ!? I genuinely did not expect to see you here chiming in. Still appreciate much of your 10 bit anime advocacy from way back.

I don’t think hardware decoders are used for images. They are light enough you can do it in software.

AVIF's support for non-photographic images is covered in the article. It supports lossless.

I'm not super familiar with AV1/AVIF but I do have extensive experience using h264 for desktop streaming, and all major implementations support 444 in hardware and software, and I doubt more advanced codecs/image formats have a limitation like this. Asked ChatGPT and it also claimed there's no problem with 444 and AVIF/AV1.

+1, this is super unfair to show the one point in time where AVIF progressive looks better - right after it receives its 'preview' (which as you say is 4x as big as JPEG XL's).

I value integrity, especially when communicating results. This is shameful.

(Disclosure: I worked on JPEG XL)

For progressive, I think it's better to show the user something that's obviously a preview, but still has enough detail to be able to know what the picture is of.

If you're showing the user something that they may mistake for complete but poor quality, that's a bad experience.

> Maybe re-encoding my website JPEGs to gain 20% size is not worth the 33% longer decode

I changed all my .jpg files to .avif a few years ago. The benefit I get is much more than 20%. Now there is some loss when I use high compression with .avif, in particular via gimp - but other than that, I gained a lot of file size here, definitely much more than 20%. It also depends on the image at hand; I noticed that images with a ton of details, such as if you photograph a garden, takes more space. But for simpler images, I have easily gains of about 60% or 70% compared to jpeg, with no or almost no loss in quality. Whereas if I were to use jpeg compression, the quality loss would be insanely high. When I noticed this, I decided to abandon .jpg for my own use cases. I had to choose back then between avif and webp and while webp is fine, I found .avif was slightly better for the use cases I had.

I don't quite know how much jpeg xl performs, but you mentioned JPEG so I had to comment on that 20% statement as I found it way too low.

I also find the claim "longer decode" not correct. I have some photographs of gardens and the file size is huge, in JPG. When I compressed and changed these into .avif, the resulting page loads soooooooo much faster now when having used avif and a considerable but acceptable compression of it. It is just no comparison at all - avif beats jpg with its eyes closed.

> Maybe a lossless re-encoding of my website JPEGs to gain 20% size is not worth the 33% longer decode,

And pray tell how much of the waiting for page is used on decoding image (vs transferring) and how much faster the image gets on the machine when it's 20% smaller on average connection?

My guess is that time saving from bandwidth decrease more than compensates for that

Agreed. JPG is the most popular format for photography. PNG, the lossless format is great for diagrams and stuff with sharp edges. It can be "compressed" via dithering and quantization.

GIF is there... because it will always be there because it's just a hit that will never go away. It's also lossless (when discounting colour depth).

The new formats are interesting webp, avif, JXL and so on.

Jpeg classic is the clear winner IMHO and will probably never be less relevant than the new fancier formats. JPG even does text and sharp edges, reds, and so on well if you tell your process to take into account chroma subsampling!

It's magic and it puts food on my table.

In the context of the world it's all hair splitting, you can have a big photographic picture in png, or 1% compressed jpeg, or 1% jpeg converted to png. No new format can change it.

"These should just be vector images instead" is an argument made by someone who has never in their life attempted to create a vector image.

When a format has so much flexibility, the world will glom onto the first thing that it solves and put it into the wild to solve that problem. The rest of the capabilities fall by the way side, yet not removed from the format. They're just ignored. MP4 can do so much more than the typical deliverable of a video stream and an audio stream. The spec allows for multiple video streams, multiple audio streams, subtitles, Flash like interactivity to allow self contained DVD style programming of menus to allow for chapter navigation, audio/sub selection, multiangle, etc.

I wonder if similar hacks apply to zlib and .png as well.

I got an impression JPEG XL is not a single format, but many formats put under one brand (same as webp), you still need to choose these formats and transcode between them.

I've always found it annoying how most cameras only let you save their photos as some combination of JPG/PNG/HEIC/RAW, often without any adjustable quality settings or option to save several copies in different formats.

It would be great if their behavior could be customized in a more modern web-friendly way, like "Save the original photo as a 95% quality AVIF in this folder, and also as an 70% quality resized WebP in this other folder".

I personally find AVIF more versatile. I just throw images at it, and it does a great job. As the article identifies, JPEG XL performs worse than AVIF in general, but it's particularly bad at things like illustrations and screenshots. With AVIF I don't need to worry about that.

It is getting its try, actively, in libjxl. People like to pretend AV1 got infinite resources; the reality is myself and one other contributor produced the vast majority of the image gains. I built Iris-WebP and aperture-alpha myself, from scratch. As a compression engineer, I think JXL is way, way harder to work with, and it would've taken me a lot longer. libjxl has community contributors, it is just an uphill battle with a codec like that. Same as WebP is an uphill battle due to its format restrictions.

> It won’t be know until it’s been tried

We can reevaluate when and if improvements are made. The problem with statements like this, is its really easy to miss the showstoppers when imagining what something could be. All plans are amazing until you have to actually do them in the real world.

As the saying goes: Never fall in love with potential.

"We don't want to support another pile of security bug ridden C++ library" absolutely aren't "dubious grounds".

You'd rip a new one to Google if there would be a CVE in a new C++ library in Chrome because of it.

Now that Rust library is available, they will continue adoption, as it should be.

I knew about the lossless JPEG to JPEG XL compression story before, but had no idea that it was a two-way road. That's truly f* impressive. Boggles my mind even more the fact this format hasn't been adopted widely yet.

Just demosaiced JPEG XL? That's not raw.

Lossless JPEG XL is in the DNG spec since three years (v1.7). So, you can convert your proprietary camera raw files to smaller ISO standard compliant JPEG XL compressed DNG raw files (mosaiced, not linearized).

Raw isn’t an image though, it’s pre-image. And we have an open raw format already. DNF I think. With pretty decent adoption.

it's even flexible enough to represent images pre de-bayering

Lossy Modular isn't efficient enough to compete with even JPEG.

Also, look at the graphs – Iris-WebP beats JPEG XL.

In the post, I say "I think WebP was a bit too narrowly scoped"

This is not a coincidence, but I don't think it was that devs looked at WebP and thought "huh, the lack of 4:4:4 and 10-bit support makes this less compelling for our product despite being all over the internet" – I think it was just a matter of not keeping up. Except for Apple, not sure why they took so long to implement it.

"Web optimised" really means "internet transfer optimised". Eg, the benefits would also be there for native apps that are downloading images from the internet, and they're not the web.

Encoding time is one of the things that JPEG XL has claimed over AVIF for years, but in the latest encoders, it doesn't seem to be the case.

How ergonomic are the modern AVIF encoders? I like libjxl (and cjpegli) because they are really good at generating reasonably compact, high-quality images.

For every other image encoder I used I couldn't find one setting that would make compact, high-quality images across the gamut of inputs (e.g. things like comics that have extremely visible high-frequency content would look terrible at quality settings that looked good for many photographs).

Lossless was discounted due to webp, but doesn't webp lossless only use 8bit depth RGB? (I think it is important to have a separate file extension for lossless stuff anyway, otherwise it gets confusing quickly)

What do you think about the fact that most perceptual quality improvements in SVT-AV1 have been almost only driven by external, non-paid enthusiasts such as yourself while the maintainers have been basically only targeting VoD and RTC?

Compared to JXL (which admittedly has almost nobody working on except veluca these days...) which was focused on it since the beginning, I think it really matters.

We have to apply some weight to the fact that one is open, one isn't, right?

EDIT: Oh! Of course. AVIF is based on AV1. For some reason I was thinking HEIF the entire time I was reading the article. Man... withdrawn!

Really good read, btw. Very good points.

What do you think the best use cases for jxl are? Where does it still have an advantage over other formats?

I have a lot of basic questions about the CVVDP graph. Is the X axis encoding or decoding speed? Is higher better on the Y axis? What format is Aperture? I assume "aom" is AV1 but it wouldn't hurt to document it.

It would be nice to see the actual R-D curves for the codecs instead of compressing them into a single number. Also, what is BD-rate computed with respect to, jpegli at p0?

I would argue that even if JPEG XL isn't the best choice for Web images, if browsers don't support it then that will widely hinder its adoption for its non-Web use cases. Would you agree?

The scenario I'm thinking of is sending a photograph by email. Let's say Sally has just had her second baby, and wants to send baby pictures to her mother, the baby's grandmother. Neither Sally nor her mother are computer professionals, and they don't want to care about image formats. Sally wants to upload a file from her camera, attach it to an email, and send it. Her mother wants to click on the email and see pictures of her new grandchild. Neither one of them wants to have to convert the image themselves.

Let's say it's a few years in the future and Sally's camera produces JPEG XL files by default. (Which I don't think would happen if browsers didn't support it, for exactly the reason I'm about to articulate). If Sally's mother's browser doesn't support displaying JPEG XL, then although Sally (who uses a different browser than her mother) sees the picture in the email when she sends it, her mother writes back an email saying "the picture didn't show up, can you resend it?" And they spend a few back-and-forth emails before finally getting tech support from a friend who helps Sally convert the picture to old-school JPEG so her mother can see it.

If that's the experience for end-users, cameras would hesitate to switch to JPEG XL as a default format. Because nobody wants a hostile review from a user saying "My mother couldn't load my baby pictures, what kind of lousy camera are you making?"

So even if it's not the best format for the Web, I'm still persuaded that having universal browser support for a format intended for photos is an important factor, and devices like cameras will not switch to it as a default format until manufacturers are certain that browser support (and OS support, and electronic photo frame support, and so on) is nearly universal.

None of that takes away from the argument "Other image formats are better for saving space on the Web", which is the main thrust of your post. But I do disagree with the last line, "I'm just not personally convinced we need it in browsers any time soon." I believe that if browser adoption is lacking, adoption of the format in places where it makes lots of sense (like cameras) will also be slow.

What are your thoughts on that argument?

What format would you recommend for archiving photos if I don’t mind slight quality loss?

Very compelling and thoughtfully written article. Thank you!

What about the current AV1 patent issues, like Sisvel/Access Advance and Dolby vs Snap? Does that change the AVIF vs JXL comparison at all?

Something is fishy here.

The JPEG XL report [1] measured between 240-270 Megapixels/s on 6 cores using the C++ implementation (disclosure: I was responsible for its SIMD/threading), about twice as fast as the then-current libaom.

Measuring on a single core is deeply misleading because our code was designed to scale well. I believe AVIF requires tiling in order to parallelize, which causes artifacts at tile boundaries.

[1]: https://arxiv.org/pdf/2506.05987

The time would be less, but you still need to power those cores. Single thread performance can be a good indicator of what it'll do the battery on your phone.

> If JPEG XL doesn’t become useful on the web, is it really likely to become popular with camera manufacturers, professional image editing tools, etc?

I suspect that eventually, the browser makers that are reluctant to add JpegXL support will do so, even if reluctantly, and so it will eventually "become useful on the web".

The reason why is Adobe added JpegXL as a compression format for PDF's, and as every browser maker wants their browser to also be a "PDF viewer", this means they must include a JpegXL decoder to be able to support PDF's going forward. If they must have a JpegXL decoder anyway, it is not that difficult to also add it as another supported format for the <img> tag.

Most people using dedicated cameras shoot in RAW, then use a program to process and export the photos afterwards. So camera manufacturer buy-in isn't super important.

I've been exporting in JXL from Lightroom for a little while now, you get slightly smaller image sizes and HDR with no real downsides. On the web I imagine this will translate to higher quality images on social media since platforms can get more out of the same file size. It will also likely be the end of HEIF which is a pain to deal with due to patents.

I’ve been shooting with semipro to pro cameras for decades across brands, and I haven’t came across a single camera that supports shooting JPEG XL.

HEIF is what is getting support in recent models; but JPEG still rules supreme for its compatibility.

Web publishers should definitely be stripping metadata at least, and transcoding isn't much harder. For anyone who cares about bandwidth, transcoding to efficient formats is non-negotiable; if you don't, then why do anything? Just ship PNG, who cares?

I think one of the compelling use cases for camera manufacturers would be an interoperable format for editors. Since JXL has support for so many channels, you could load your image into an editor, edit it, add layers, etc., and export as JXL, which could be used for other things.

iPhones have been using it for its ProRAW format since 2024.

It has 3 options:

JPEG Lossless (most compatible)

JPEG-XL Losless

JPEG-XL Lossy

Depends on your location. While I have a decent internet connection at home, the mobile one is trash. Good for IM and not much else.

Most of the people I know only have the mobile connection, pay a lot for the privilege, and while speeds are generally good (LTE and up), the monthly cap for almost all of them is 10-20 GB.

Just to put some numbers to this, I looked at an image I recently took with my phone:

Original image (JPEG): 3072×4080, 2.6 MB. Transcoded to JPEG XL: 2.1 MB.

To display at 2x density on my web page, it would be 1598×2122.

Lossless JPEG XL: 2.5 MB. Web-quality JPEG XL: 93 kB. Web-quality AVIF: 70 kB.

It still seems worth it.

AVIF is royalty-free, with open-source implementations not developed by Google. Google's implementation is libaom; as you can see, SVT-AV1 beats it. SVT-AV1 is developed by a number of companies – historically Meta, Netflix, Intel, independent contractors, and others. I worked on SVT-AV1 myself. I don't see how this is a bad thing for everyone, even if Google drove standardization of AV1?

> You can't let one Fruit Company's format be the thing either, so it's basically a L for engineering but a W for pleasing everyone TBF.

What exactly is "Fruit Company's format"?

There exist lossless use cases, for sure. I think most people would be well-served by high-fidelity lossy that saves a lot of bits while still looking perceptually identical. Whoever isn't served by that most likely doesn't care about size savings, and can stick with lossless PNG.

Worth noting that this progressive AVIF, when viewed in Chrome, has only two states: a "base layer" which pops in around 8KB, and the full image which appears 270KB later. The comparison JXL continues to refine during most of the download, so it winds up looking substantially better than the AVIF at around 95KB loaded, and looks pretty good (almost as good as the full 280KB AVIF) by 175KB. I suspect that there are a lot of knobs to turn for both progressive modes, but this particular case could definitely be cherry-picked to favour either codec.

Professional web developers want to create a great experience for their users, so they go beyond simply serving whatever comes off a digital camera.

As the article identifies, JPEG XL is kinda bad at certain types of images, whereas AVIF does well across the board, so if you feel compelled to pick a single format to use, AVIF would be a better choice, but it's definitely worth optimising your web images for the web.

Also, JPEG XL is two codecs bundled into one, VarDCT and Modular. So, even if you're picking JPEG XL as "the one codec", you're actually picking two, and you need to choose between them at encode time.

> A lower resolution image layered below the full resolution image, which is loaded and rendered first.

I'm curious, where did you learn progressive AVIF works like this? Have you actually read the spec, or does your understanding comes from somewhere/someone else and never challenged the truthfulness of it? Progressive AVIF is truly "progressive" -- it never involves "loading a thumbnail" or "layering an image over another".

In reality, each pass (up to 4) can refine previous ones (thanks to AV1's inter-encoding toolset), avoiding storing redundant information between passes. The viewing environment doesn't need to render a given pass if a subsequent one has already been downloaded. Finally, scaling is configurable -- you can have your first pass already be at full res, just at a lower quality.

Hope this helps clarify how progressive AVIF actually works under the hood.

> A lower resolution image layered below the full resolution image, which is loaded and rendered first.

Unlike a thumbnail, higher-resolution layers can be predicted from the lower-resolution layer, so those bits are not wasted. That is not possible by layering <img> elements.

You're wrong. AVIF does support spatial layering where the full-resolution image is derived from the lower-resolution layer, and cannot be decoded independently.

Yes, the format is not inherently progressive. But having the fine steps in progressive quality that JPEG-2000 and JPEG-XL have has less general usefulness than the amount of words complaining about it.

Not sure if the difference is materially relevant to UX at all. JPEG XL achieves progressive rendering at a great cost to its selection of coding tools, so I side with AVIF's approach.

Does the difference matter?

How does progressive rendering actually that most OS GUIS are not multithreaded ?

The preview in finder is still going to block. Im saying this as a MAC user speaking of experience browsing mounted drives that sometimes are slow and it feels like the window freezes up.

The author covers it:

> JPEG recompression is the ability to losslessly re-encode JPEGs as JXL images while saving bits; the oft-cited number is 20% savings. However, the user pays for this in decode time, as recompressed JPEGs take ~33% longer to decode

Yes but the decode time is orders of magnitude more.

HEIC has a very messy patent situation around it which limits what tools work with it.

E.g. for official Windows support by Microsoft you need to buy the codec from the Microsoft App Store for $0.99

You should never transcode lossy source files because there is generation loss in quality.

There is still a lot of reason for Apple to switch from HEIC to JXL for photos going forward since HEIC is patent encumbered so it will never see widespread use.

Formats that aim to be web standards should try not to be patent encumbered. There was a lesson to be learned from the Unisys debacle in the 1990s. If you don't want to reencode for the web, use a device that captures in a format that can be shared on the web.

Think about how many images large platforms deliver every day, and the benefits of saving bits on each of them.

Because you'll be hounded by patent pools and sued into oblivion if you dare to use it in your own software and aren't Apple, Microsoft or Samsung.

JPEG isn’t from IETF.

>it isn't Google.

It is Google. The JPEG XL standard evolved from a codec Google made, Google was involved in the standardization process, and Google heavily contributed to the reference implementation of JPEG XL.

https://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf

  Editors:
  Jyrki Alakuijala – Google, Switzerland
  Jon Sneyers – Cloudinary, Belgium
  Luca Versari – Google, Switzerland
  Jan Wassenberg – Google, Switzerland