I think it is a potentially good camera format, good medical & scientific imaging format, good RAW compression format (Apple uses it in some newer iPhones for this), good media interchange formats for tools like Photoshop (think about storing all of your layers inside of one JPEG XL that's fully compatible with .psd files), and more. It is incredibly expressive and versatile, which is what makes it so risky on the Web.
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.
> 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.
Both Firefox and Chrome [1] have committed to shipping JPEG XL later this year. Safari has supported JPEG XL since 2023, though their implementation doesn't support progressive images yet.
So the major web browsers will support JPEG XL later this fall.
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.
x-axis is encoding speed, Y-axis is BD-rate where higher is better. aperture-alpha is an upcoming encoder from Halide Compression, no more details than that. libaom and SVT-AV1 are both for AVIF; libaom is the AV1 reference encoder.
Bit of a nit, but can you add that as a note to the legends/graphs in the future? As a layperson, it helps us to orient to graphs with unknown metrics.
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).
those issues aren't real. they're nuicense suits by a patent troll. a couple companies will settle cause it's easier and cheaper, but if they ever try to go after someone big they'll fight it and get the patents invalidated for covering 30 year old work
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.
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?
"For non-photographic images, the argument that “they should be vector images” doesn't hold up because many images could be vector images but aren't, and they can't be vectorized perfectly. “The world should be different” is not a justifiable defense against optimizing for the way the world actually is."
This is a good paragraph. I see people forget to apply that last sentence all the time.
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!
Gif is a weird one because it's silently been replaced while keeping the name around. Virtually every software using the term "gif" actually uses a h264/vp9 video with no sound.
Modern video formats are so much better that they are a no brainer to use while the word gif just got used to refer to looping video without sound rater than the literal gif image format.
Reminds me of when Imgur started trying to push changing gifs over to gifv, which were just mp4 with a strange new file extension. I didn't like their approach but it really was such an improvement on file size and quality.
Not to mention if you for some odd reason wanted to do gif-style animations, you can also do it with apng or webp. You shouldn't, real video format makes more sense, but even if you did there is still no reason to use gif.
also, don't forget - actual video format is better for animated stuff. Current default approach is .webm which is standardized .mkv container + vp9 (or av1) video + opus audio (usually no audio to as a feature parity to gif). IMO animated picture formats like .avifs are very backwards and don't add much
> Gif is a weird one because it's silently been replaced while keeping the name around. Virtually every software using the term "gif" actually uses a h264/vp9 video with no sound.
Then, long live the iMessage and Whatsup exploits, because SW developers are not able to do things right.
I began a dispute on the English Wikipedia which revealed that more than a few people use “GIF” to describe, not a file format, but a visual style of looping animation.
The major blunder here is browser refusing to support silent videos in <img> tags etc. so we end up with all these hacks. Instead we got animated webp that you can't use for progressive enhancement because it doesn't have its own mime type and browsers reported support for image/webp before implementing animation support. And webp is also very limited when it comes to inter-frame compression for no good reason at all.
PNGs will persist because I know that they're lossless by looking at the filename. When I hit File > Save as .png, I don't have to inspect output metadata (that image viewers don't expose) or play around with exporter settings.
It's unfortunate that we didn't give lossless webps a separate extension. Frankly I think even saving them as .png would've better than what we have now - people roughly understand that a .png is an image without artifacts, and any self-respecting image viewer will inspect magic bytes before opening a file anyways.
Being lossless is a function of the whole pipeline from an input image to an output image. The last step being encode to PNG doesn't guarantee anything about losslessness.
I do not know whether this has anything to do with any limitation in the WebP format, because it is more likely that this is some kind of bias in the kind of authors of Web pages who choose the WebP image format, who might also choose more aggressive compression settings, but for me WebP is a synonym for "low-quality image".
This means, that at least for the Web sites that I happen to access frequently, whenever I see PNG or JPEG images they typically have a better quality than when I see WebP images.
I do not know whether when browsing the Web I see frequently any AVIF images. They are either rare or they have a similar quality with JPEG images, so they did not stand out like WebP, where I perceived a degradation, so I noticed that the image format was different.
I do not care much about the speed of decoding Web images, because the speed of loading Web pages is determined mostly by the amount of junk JS that is included and not by the loading and decoding of the included images. So for me the quality of the included images is more important, thus WebP is something that I dislike, while JPEG is far too limited, so I would prefer JPEG XL images.
The arguments in TFA do not seem entirely honest, because the presented data confirms the low quality of WebP, and because the 2 compared JPEG XL implementations differ in their performance by a factor more than 2, so it is likely that they are both immature and one could still accelerate the decoding of JPEG XL by at least 2 or 3 times in comparison with the best of them.
Png is still being updated, just last year it was updated to support a wider color space than any other web format. This shipped in all browsers before the official spec was publicly so you’ve been seeing Png upgrades without even realizing it
We all know these aren't purely technical reasons, it's to break the monopoly of one Internet Company's decoder format portfolio. 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.
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.
What exactly is AVIF doing in this case that I can't do with two <img> tags at a smaller size? I can easily create a thumbnail that beats the AVIF quality in less than the 5KB delta between the static and progressive version in Squoosh.
The quick answer is: you can have up to four passes. With progressive AVIF, you let the browser avoid rendering previous passes if a subsequent one has already been downloaded. It's more efficient and saves battery.
why? in jpeg xl i get an image quicker and i can see it getting better, so i know it's still loading while the avif one looks stuck for the majority of the time, which makes it look already done loading and just low quality to me.
Progressive AVIF is very flexible: it supports up to four passes, at configurable quality and dimension scaling levels. You can have any given pass reference up to two previous ones for refinement (thanks to AV1's strong inter-encoding capabilities), and you add filters to non-final passes (like blurring) to achieve a desired loading aesthetic.
That JXL page happens to use two passes, but the knobs are there to customize the experience to fit the use case.
I find it misleading to call AVIF's "up to four passes" "very flexible".
It seems quite limited compared to the JPEG XL ability to truncate the bitstream anywhere, or send the progressive updates for salient regions first [1].
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.
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.
Well, JpegXL does have one really cool feature: you can transcode jpeg to jpegxl (and back) losslessly. For jpeg to jpegxl it'll save something like 15-20% in size.
That JPEG XL prime computation is a pretty ugly DoS. Just selecting it in Finder, with the preview pane open, maxed out every core on my Mac inside a QuickLookSatellite that also ate 4GB of RAM while doing so - for a good 15 seconds. Not bad for a 2KB picture. It seems like Apple did not set sane limits on their JXL previewer.
Probably not; for PNG, the image size is declared in the header, so a decoder can decide immediately if it wants to decode the image or not. The output is bounded by the size of the image times the bit depth, and decompression runs in time proportional to output size. zlib bombs exist, but they don't affect png because a decoder can simply refuse to decompress past the size of the pixel buffer.
The infamous PIL DOS errors, rooting from the library refusing to process images larger than a hard limit. Does this mean though JXL does not have that data accesible quickly?
The problem is that JXL has a ridiculously versatile modular mode which enables high-complexity “prediction” computations. These were designed to encode reusable, custom predictors that could reduce the prediction error and thus the number of bits needed to encode the error. However, the predictors can be abused to perform very complex computations instead. The prime image is only 4kx2k, but encodes a very complex prediction algorithm that happens to generate prime numbers.
In principle, a decoder could refuse to process images with predictors above a certain complexity limit, but it’s hard to know how to set such limits accurately.
I mean "mild" bombs where the final output bytes looks normal, a regular sized image, but the decompressing steps takes unnecessarily long, eating CPU or/and RAM
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.
None of that has fallen by the wayside though? I have seen examples of all of those in the wild except for interactive menus and multiangle. Multiple video streams is incredibly rare to encounter but I have run into it a few times.
The argument in favor of flexibility (and jxl) is that if you optimize things for the "average" web user (as the essay seems to be suggesting) then fairly mundane usecases require you to start juggling formats, support becomes spotty, and things start breaking. It's nice to have generous limits within which you can be confident that things will "just work" for the end user. Even just on my own system I'd much rather use a single format rather than dealing with app x not supporting format y.
tl;dr jxl is the mp4 of image formats and that's exactly why I like it.
The only things I agree with the essay about are progressive decoding and decoding speed. Particularly the latter badly needs to be improved.
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?
What does it offer there that existing workflows can’t support? Do those advantages make up for the transcoding that every web publisher would need to do to make the outputs useful on the web?
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.
> 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.
The second paragraph doesn’t follow from my question, because it assumes JPEG XL does become useful on the web. The author believes AVIF is too far ahead already.
I suspect the name alone will help drive adoption, especially from non-technical people. Heck, I'm reasonably technical myself (but not expert in image formats) and my first instinct on encountering AVIF was to say "AVIF? Does that stand for AVI File?" And I would have assumed that it's a video format, not an image format. Whereas JPEG XL would have everyone who has ever used a digital camera saying "Ah, it's got JPEG in the name, that means it's a photo format".
Never underestimate the power of a well-known brand name in communicating things to people who know nothing else about the subject. The name is a big part of why I suspect JPEG XL will take off in popularity. (The lossless conversion to and from classic JPEG format is the other main reason).
There’s also a migration path where jpeg can be converted to jpeg xl losslessly. You can convert a jpeg to jxl then back to jpeg and its byte for byte identical.
For me, the name JPEG XL evoked a feeling of “this is going to be a lossy-only format with visible artifacts when used on raster images”, so I don’t think it’s a good name.
JXL is moments away from having almost universal web support. Safari supports it already, Chrome and Firefox are already set to turn the flag on by default in the next releases.
I wasn't really sold on the argument initially, given they admit there's some real lossless usecases, but this is a good bit from the conclusion:
> Not to mention an additional compatibility headache now exists for anyone just trying to download an image from the Internet and use it somewhere – it was hard enough to get widespread WebP adoption, and I don't think it's worth doubling the pain by having to climb the same hill for AVIF and JPEG XL. Especially when JPEG XL doesn't appear to add anything to the Web platform.
It is very annoying downloading an image for the web and then trying to upload it somewhere else also on the web during these transition periods.
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.
Much like WEBP, JPEG-XL is two different codecs in one. There's VARDCT mode, and Modular Mode. Modular Mode is normally used for lossless, but it can also be used for lossy as well. When you use Lossy Modular Mode, you get different kinds of compression artifacts than what you'd see in a JPEG file.
For Lossless: JPEG-XL wins, then WEBP, then PNG. (Sometimes lossless WEBP wins)
For Lossy: AVIF wins, then JPEG-XL, then WEBP, then JPEG.
> Progressive rendering (which AVIF supports) decodes a low-fidelity rendition before the full image arrives. AVIF didn't support progressive rendering for a while, and during that time I believe it was deeply oversold. Now that libavif has implemented it (it was always possible), the conversation appears to be over.
This is false. AVIF does not support progressive decoding/rendering. What the author is referring to here is image layering. A lower resolution image layered below the full resolution image, which is loaded and rendered first. That is not progressive decoding/rendering. It is a thumbnail.
Unlike AVIF's false advertising, JXL truly supports progressive decoding/rendering. With JXL, you do not first load a thumbnail before loading the actual image. The lower-quality image that JXL shows while decoding is derived from the data of the actual, full-resolution image.
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.
Thumbnailing happens in a background process and shouldn’t block the main thread; rather hangs are usually because fetching xattr over SMB is slow and Finder will block until it’s enumerated the metadata of every file in a folder.
Preview actually does use progressive rendering for large enough images, even from SSDs. You can tell because opening an image will be blurry for several seconds, even when the full size image could have been decoded in a quarter second or less.
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.
> 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.
> 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.
It seems to me that AV1 (the codec used in AVIF) has seen a lot more development in recent years, by virtue of being widely adopted for video. JPEG XL has not seen comparably massive adoption, perhaps owing in large part to Chrome rejecting it on dubious grounds (in spite of eagerly forcing the adoption of both WebP and AVIF earlier on). The pace of the reference implementation’s development has grown very slow, and most of the modest attention it’s been getting seems to have recently moved to the new Rust decoder, once the browsers finally made up their mind that’s what they wanted from the devs.
That considered, I don’t think it’s a fair comparison between the codecs. JPEG XL used to be far more impressive than AVIF; it’s great people (author included) have managed to push AVIF forward, but until similar efforts have been made for JPEG XL in earnest, I don’t feel like a comparison between their encoders says much about the codecs themselves. The author does take a guess on how much the JXL encoder could be improved, but that’s just that: a guess. It won’t be know until it’s been tried. And especially given the whole unfortunate history, I think JPEG XL really, really deserves a try.
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.
I feel like JPEG XL could be a good RAW format for mirrorless cameras... something with huge flexibility but with the perk of being easier to view casually on other devices. And then that in turn could make it a more useful web format? Camera vendors are of course notoriously proprietary/stubborn.
True. I would love to have lossless images (and video) out of my devices still. Not as a replacement for RAW but as a middle ground between RAW and lossy JPEG.
Not for quality reasons primaily but because keeping the first stages of the processing pipeline and the archival branch lossless solves some headaches.
You are thinking of DNG which is more of a container format. It can use multiple image formats internally to record the actual image, one of them being JPEG-XL.
iPhone raw images are actually a jpeg xl inside the DNG.
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).
Nobody has brought it up yet, but JPEG XL seems to be close in potential and flexibility to OpenEXR. It seems more a competitor to something like that--for use in image processing and digital art pipelines--than something like JPEG, WEBP, or PNG.
That said, I have converted my personal JPEGs to JPEG XL, because you can losslessly convert back and forth between the two for smaller filesize in JPEG XL with no quality loss, so I get free storage savings and can get the byte-for-byte original JPEG back if I need it.
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.
JPEG is a lossy frequency-space compression stage followed by a lossless Huffman coding stage. The second stage is quite generic as such, essentially compressing a stream of bits.
So you can relatively easily replace the second stage with something better. And since it's lossless you can easily go back.
Dropbox[1] and others have exploited this for reducing storage requirements, converting back on-demand so the client doesn't notice.
A potentially major issue I have with AVIF is that because it is based on a video format, any hardware decoding support AVIF will get is likely to be restrained to common video scenarios. This can result in eg. only 4:2:0 YUV being supported by hardware decoders, as that's the upper limit of AV1 Main Profile (and thus the limit of AVIF Baseline Profile). And 4:2:0 is just a poor fit for certain categories of images (like various kinds of illustrations, screenshots, etc). I would not be very happy about a web where lossy 4:4:4 image compression would be heavily discouraged with modern formats.
Also, good lossless compression absolutely does matter for the web as well. Lossy images just cannot be used in all circumstances - like when comparing compression quality (especially of videos), for example!
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.
Then chatgpt missed an obvious issue, nvidia definitely have had shortcomings in the hardware implementation of coder/decoders only supporting 420 in nvenc/nvdec. One obvious problem with that was that it affected premiere.
Yes, I know the format supports it. The question is, will hardware decoders built primarily around video use cases? And if those kind of hardware decoders end up forming the majority of hardware decoders for AVIF, will we end up in a future where using the full range of the format is heavily discouraged because it won't be supported by hardware decoders?
For comparison, it was possible to do 10-bit video with H.264, but 10-bit video didn't see any mainstream adoption with it because hardware decoders generally didn't support 10-bit H.264 video. Only when newer formats came around and specced 10-bit support as a baseline necessity did we start to see wider adoption for it. And well, the baseline specs (main profile) for AV1, which AVIF is based on, are limited to 4:2:0...
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.
The factor is latency.
Software decoding takes milliseconds.
Depending on CPU and the video/image resolution, performance drops means the eye perceives lags when the 50ms threshold is reached. For videos, especially at 60fps that matters.
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.
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.
> 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.
4:2:0 is the main reason why most games look like crud once they've passed through any mainstream video encoding pipeline. That being said, the bitrates used for streaming games and VoDs are so low everything looks like mush anyway and millions still watch that.
I agree that the choice for JPEG XL is mostly politically motivated: it isn't Google. And its name is derived from JPEG, which is an IETF standard which gives it more clout.
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.
Note, that JPEG XL was added as a possible compression method for DNG files (Digital Negative - stores raw images with raw sensor data of a camera).
Because of it, for the past couple of years, all new iPhones and almost all Android phones (mostly Samsungs) already contain a JPEG XL encoder / decoder (to generate these DNGs).
I'm sure this is right about all the technical things, but the stuff about the requirements of a format for the web misses the mark IMO.
Normal people don't pick an image format based on whether it is suitable on the web or not. They want a format that works everywhere. If I download or upload a photo I don't want to have to do a lossy format conversion. If I'm writing an image processing tool it would be great if I can make it just support one input format that everyone uses, rather than "web" formats and "non-web" formats.
So I think a large part of the attraction of JXL is that it is a single format that works both for 10000x10000 lossless scientific images, and for 256x256 lossy web photos. You don't have to be an image format expert any more. Just always use JXL.
Definitely a shame about the technical flaws listed here though - especially decode time.
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.
> I believe Web codecs should be purpose-built, efficient, and narrowly scoped to the needs of the Web.
The post downplays the usefulness of versatility. I disagree. I'd prefer not to play the "which image format is best for this image and this use case" game and having to transcode between them. For instance, it would be great if I could have an HTML gallery showing pictures of my files as I store them on harddisk. Today these are JPEG, because it's the lowest common denominator. WEBP, AVIF are not supported photography tools (e.g. https://support.captureone.com/hc/en-us/articles/36000262921...) and I don't expect support to ever be added since it is not formats intended for photography.
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.
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 like how every time we have a codec fight no one seems to care very much about how long it takes to encode these files. Like I get it, the amortization schedule often works out, but there are scenarios where images need to be generated dynamically and will only ever be downloaded once.
It's very hard to beat the encoding performance of libjpegturbo, even with an asic.
The chart showing jxl-rs taking 1209ms to decode a 5456x3632 image in a single thread is a little damning, but is there an equivalent benchmark showing multithreaded decode performance? Clients tend to have an abundance of threads these days.
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.
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.
The article makes a good point: JPEG XL is amazing but not so much for the typical Web use cases, compared to AVIF. But the conclusion doesn't follow. Having an excellent and versatile format supported by browsers is very useful!
Maybe re-encoding my website JPEGs to gain 20% size is not worth the 33% longer decode, and maybe the website doesn't need very high resolution images or more than 12 bits per channel. But my personal archives can definitely use that and it's great that such files can be viewed everywhere without specialized tooling, including served on the intranet and indeed the Web.
In summary JPEG XL easily beats AVIF on the not-so-long tail of use cases and having compatible viewers everywhere is quite useful. And with JPEG XL becoming part of PDF, it will soon be common use cases too.
As for the rest of the article: there are interesting points in the benchmark section but I think it's too early in the JPEG XL adoption cycle to draw conclusions. One thing bothers me though: There is a single picture comparison (with tag line "results speak for themselves") and I find it quite misleading: it's just picking one point on the "bytes received" line that looks best for AVIF compared to JPEG XL. Try it yourself and you'll see JPEG XL shows something already at 2KB while AVIF has nothing until 8KB, and JPEG XL looks better than AVIF after 100KB.
> 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.
Sorry if that was confusing, I have edited my post to clarify a bit: That sentence was about a feature specific to JPEG XL, which is that if you have JPEG files you can re-encode then as JPEG XL to save space without any loss of quality. It's nice for peace of mind, you can bulk convert a large archive and you know you still have the same pixels everywhere (later you can even turn them back to JPEG without loss if you want). AVIF cannot do that. Now if you are OK with some loss in the conversion, you can also do much better than 20% with JPEG XL.
+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.
> This rules out JPEG XL's lossless advantage, which in practice is only roughly 11.9% smaller than lossless WebP anyway
> It cannot be worth bringing a new image codec to browsers to save 12%
160 comments
[ 8.3 ms ] story [ 130 ms ] threadEDIT: 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.
(.heif is sometimes used as a file extension generically, but HEIF is itself a container that can support various payloads.)
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?
Both Firefox and Chrome [1] have committed to shipping JPEG XL later this year. Safari has supported JPEG XL since 2023, though their implementation doesn't support progressive images yet.
So the major web browsers will support JPEG XL later this fall.
[1]: "Intent to Ship: JPEG XL" - https://hacks.mozilla.org/2026/08/intent-to-ship-jpeg-xl/
It doesn't support progressive images or it doesn't support progressive decoding of images?
The former would be a massive compatibility issue, the latter would only be a quality of implementation issue.
Bit of a nit, but can you add that as a note to the legends/graphs in the future? As a layperson, it helps us to orient to graphs with unknown metrics.
Thanks for the article, btw!
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).
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.
This is a good paragraph. I see people forget to apply that last sentence all the time.
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.
Modern video formats are so much better that they are a no brainer to use while the word gif just got used to refer to looping video without sound rater than the literal gif image format.
Then, long live the iMessage and Whatsup exploits, because SW developers are not able to do things right.
But also pointless when lossless WebP exists and is supported everywhere. Lossy WebP does not make as much sense though since jpegli entered the game.
OP has made https://halide.cx/iris/ which could make WebP make sense, but it's not open source or generally available.
It's unfortunate that we didn't give lossless webps a separate extension. Frankly I think even saving them as .png would've better than what we have now - people roughly understand that a .png is an image without artifacts, and any self-respecting image viewer will inspect magic bytes before opening a file anyways.
I suppose it's not very useful nowadays as most any image will load fast, though.
This means, that at least for the Web sites that I happen to access frequently, whenever I see PNG or JPEG images they typically have a better quality than when I see WebP images.
I do not know whether when browsing the Web I see frequently any AVIF images. They are either rare or they have a similar quality with JPEG images, so they did not stand out like WebP, where I perceived a degradation, so I noticed that the image format was different.
I do not care much about the speed of decoding Web images, because the speed of loading Web pages is determined mostly by the amount of junk JS that is included and not by the loading and decoding of the included images. So for me the quality of the included images is more important, thus WebP is something that I dislike, while JPEG is far too limited, so I would prefer JPEG XL images.
The arguments in TFA do not seem entirely honest, because the presented data confirms the low quality of WebP, and because the 2 compared JPEG XL implementations differ in their performance by a factor more than 2, so it is likely that they are both immature and one could still accelerate the decoding of JPEG XL by at least 2 or 3 times in comparison with the best of them.
What exactly is "Fruit Company's format"?
That JXL page happens to use two passes, but the knobs are there to customize the experience to fit the use case.
It seems quite limited compared to the JPEG XL ability to truncate the bitstream anywhere, or send the progressive updates for salient regions first [1].
[1]: https://opensource.googleblog.com/2021/09/using-saliency-in-...
E.g. for official Windows support by Microsoft you need to buy the codec from the Microsoft App Store for $0.99
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.
In principle, a decoder could refuse to process images with predictors above a certain complexity limit, but it’s hard to know how to set such limits accurately.
None of that has fallen by the wayside though? I have seen examples of all of those in the wild except for interactive menus and multiangle. Multiple video streams is incredibly rare to encounter but I have run into it a few times.
The argument in favor of flexibility (and jxl) is that if you optimize things for the "average" web user (as the essay seems to be suggesting) then fairly mundane usecases require you to start juggling formats, support becomes spotty, and things start breaking. It's nice to have generous limits within which you can be confident that things will "just work" for the end user. Even just on my own system I'd much rather use a single format rather than dealing with app x not supporting format y.
tl;dr jxl is the mp4 of image formats and that's exactly why I like it.
The only things I agree with the essay about are progressive decoding and decoding speed. Particularly the latter badly needs to be improved.
What does it offer there that existing workflows can’t support? Do those advantages make up for the transcoding that every web publisher would need to do to make the outputs useful on the web?
HEIF is what is getting support in recent models; but JPEG still rules supreme for its compatibility.
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.
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.
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.
Never underestimate the power of a well-known brand name in communicating things to people who know nothing else about the subject. The name is a big part of why I suspect JPEG XL will take off in popularity. (The lossless conversion to and from classic JPEG format is the other main reason).
It has 3 options:
JPEG Lossless (most compatible)
JPEG-XL Losless
JPEG-XL Lossy
> Not to mention an additional compatibility headache now exists for anyone just trying to download an image from the Internet and use it somewhere – it was hard enough to get widespread WebP adoption, and I don't think it's worth doubling the pain by having to climb the same hill for AVIF and JPEG XL. Especially when JPEG XL doesn't appear to add anything to the Web platform.
It is very annoying downloading an image for the web and then trying to upload it somewhere else also on the web during these transition periods.
For Lossless: JPEG-XL wins, then WEBP, then PNG. (Sometimes lossless WEBP wins)
For Lossy: AVIF wins, then JPEG-XL, then WEBP, then JPEG.
This is false. AVIF does not support progressive decoding/rendering. What the author is referring to here is image layering. A lower resolution image layered below the full resolution image, which is loaded and rendered first. That is not progressive decoding/rendering. It is a thumbnail.
Unlike AVIF's false advertising, JXL truly supports progressive decoding/rendering. With JXL, you do not first load a thumbnail before loading the actual image. The lower-quality image that JXL shows while decoding is derived from the data of the actual, full-resolution image.
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.
Preview actually does use progressive rendering for large enough images, even from SSDs. You can tell because opening an image will be blurry for several seconds, even when the full size image could have been decoded in a quarter second or less.
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.
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.
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.
That considered, I don’t think it’s a fair comparison between the codecs. JPEG XL used to be far more impressive than AVIF; it’s great people (author included) have managed to push AVIF forward, but until similar efforts have been made for JPEG XL in earnest, I don’t feel like a comparison between their encoders says much about the codecs themselves. The author does take a guess on how much the JXL encoder could be improved, but that’s just that: a guess. It won’t be know until it’s been tried. And especially given the whole unfortunate history, I think JPEG XL really, really deserves a try.
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.
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.
It is when that didn't stop them YOLO'ing in webp and then avif support.
> it was hard enough to get widespread WebP adoption
That's not a coincidence! And because these newer codecs are better outside the Web, it's not really "the same hill"
Not for quality reasons primaily but because keeping the first stages of the processing pipeline and the archival branch lossless solves some headaches.
iPhone raw images are actually a jpeg xl inside the DNG.
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).
That said, I have converted my personal JPEGs to JPEG XL, because you can losslessly convert back and forth between the two for smaller filesize in JPEG XL with no quality loss, so I get free storage savings and can get the byte-for-byte original JPEG back if I need it.
So you can relatively easily replace the second stage with something better. And since it's lossless you can easily go back.
Dropbox[1] and others have exploited this for reducing storage requirements, converting back on-demand so the client doesn't notice.
https://github.com/dropbox/lepton
Also, good lossless compression absolutely does matter for the web as well. Lossy images just cannot be used in all circumstances - like when comparing compression quality (especially of videos), for example!
But it turns out you are right, 444 decoding with H264 doesn't seem to be supported up until recently:
https://developer.nvidia.com/video-encode-decode-support-mat...
Never noticed, seems like a strange omission, but in any case doesn't seem to apply to newer codecs like AV1.
For comparison, it was possible to do 10-bit video with H.264, but 10-bit video didn't see any mainstream adoption with it because hardware decoders generally didn't support 10-bit H.264 video. Only when newer formats came around and specced 10-bit support as a baseline necessity did we start to see wider adoption for it. And well, the baseline specs (main profile) for AV1, which AVIF is based on, are limited to 4:2:0...
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.
Depending on CPU and the video/image resolution, performance drops means the eye perceives lags when the 50ms threshold is reached. For videos, especially at 60fps that matters.
For still images it doesn't.
If it ain't broke why fix it.
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.
In cases where you need lossless, WebP is there. It's close to JPEG XL's performance, sometimes beats it, and is orders of magnitude faster to decode.
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.
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
Because of it, for the past couple of years, all new iPhones and almost all Android phones (mostly Samsungs) already contain a JPEG XL encoder / decoder (to generate these DNGs).
Normal people don't pick an image format based on whether it is suitable on the web or not. They want a format that works everywhere. If I download or upload a photo I don't want to have to do a lossy format conversion. If I'm writing an image processing tool it would be great if I can make it just support one input format that everyone uses, rather than "web" formats and "non-web" formats.
So I think a large part of the attraction of JXL is that it is a single format that works both for 10000x10000 lossless scientific images, and for 256x256 lossy web photos. You don't have to be an image format expert any more. Just always use JXL.
Definitely a shame about the technical flaws listed here though - especially decode time.
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.
The post downplays the usefulness of versatility. I disagree. I'd prefer not to play the "which image format is best for this image and this use case" game and having to transcode between them. For instance, it would be great if I could have an HTML gallery showing pictures of my files as I store them on harddisk. Today these are JPEG, because it's the lowest common denominator. WEBP, AVIF are not supported photography tools (e.g. https://support.captureone.com/hc/en-us/articles/36000262921...) and I don't expect support to ever be added since it is not formats intended for photography.
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".
It's very hard to beat the encoding performance of libjpegturbo, even with an asic.
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
Maybe re-encoding my website JPEGs to gain 20% size is not worth the 33% longer decode, and maybe the website doesn't need very high resolution images or more than 12 bits per channel. But my personal archives can definitely use that and it's great that such files can be viewed everywhere without specialized tooling, including served on the intranet and indeed the Web.
In summary JPEG XL easily beats AVIF on the not-so-long tail of use cases and having compatible viewers everywhere is quite useful. And with JPEG XL becoming part of PDF, it will soon be common use cases too.
As for the rest of the article: there are interesting points in the benchmark section but I think it's too early in the JPEG XL adoption cycle to draw conclusions. One thing bothers me though: There is a single picture comparison (with tag line "results speak for themselves") and I find it quite misleading: it's just picking one point on the "bytes received" line that looks best for AVIF compared to JPEG XL. Try it yourself and you'll see JPEG XL shows something already at 2KB while AVIF has nothing until 8KB, and JPEG XL looks better than AVIF after 100KB.
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.
I value integrity, especially when communicating results. This is shameful.
(Disclosure: I worked on JPEG XL)
What? 12% is huge.