6 ms·

The article makes a good point: JPEG XL is amazing but not specifically for the typical Web use cases, compared to AVIF. But the conclusion doesn't follow. Havi

by cbolton 21d ago

The article makes a good point: JPEG XL is amazing but not specifically 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 a lossless re-encoding of 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.

jaffathecake 21d ago
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.
- tzu321 21d ago
  That's a good point.
  - llm_nerd 20d ago
    It's an absolutely ridiculous point, and the guy you're responding to (who has commented almost 40 times in this discussion) has a hilariously slithery opinion that somehow always finds a way to hold every finding against JXL. Personally I don't like progressive rendering at all, but it's interesting that this same guy claimed elsewhere that it's super important on a very bad connection to get an early hint of what an image is. When someone points out that the "the results speak for itself" cherry picked example is absurdly misleading, and in most cases JXL is vastly superior at that case, instantly their opinion changes such that it shouldn't look like a poor quality image but it's somehow also a win that AVIF takes longer to give you anything at all to look at. Which is incredibly weird, given that AVIF also gives you a terrible quality image, it just takes longer to show it. So it sounds like they're completely against progressive rendering? Unless they think it gives AVIF a benefit? But it's an amazing demonstration of someone with an agenda. Utterly bizarre.
    - jaffathecake 20d ago
      I also called AV1 short-sighted for not including an alpha channel, and corrected someone who claimed jxl-rs was single-threaded. No agenda here - I'm just correcting misinformation and stating my opinions. I'm not against progressive rendering - I fought for it to be part of the jxl-rs integration in browsers. I've written articles about it https://jakearchibald.com/2025/present-and-future-of-progressive-image-rendering/ https://jakearchibald.com/2025/present-and-future-of-progres.... Just because someone has a different opinion to you doesn't make them part of some grand conspiracy.
- ZeroGravitas 21d ago
  The quality of the preview layer is somewhat under the control of the user though. And that comparison was made for a JPEG-XL focused site, and uses quite large images that are then scaled down dramatically (at least on mobile) for display which is probably not an ideal visual test anyway (but possibly necessary for there to be enough time to see any difference)
- JyrkiAlakuijala 19d ago
  Depends on the user. Some users are more sensitive for flashing images. Some users have very slow or unreliable network connection. Some sites have bigger images. Some sites (such as ecommerce) have higher quality and resolution needs. Some users have uncorrected astigmatism. In the general population, the average uncorrected astigmatism typically falls between 0.50 and 0.75 diopters (D), and ~15 % more than 1.0. The high astigmatism people will see images blurred in any case and don't benefit from the fine structural detail JPEG XL can give. People with glasses and the lucky ones with low astigmatism will see the details clearly. Sometimes passionate ends of different quality of vision seem to have a discussion on what makes sense as the web quality, with one emphasizing quality 40 being more than enough and another requesting a quality of 95. The same kind of individualism exist also in temporal cognition and perception.
shevy-java 21d ago
> 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.
- cbolton 21d ago
  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.
  - danudey 20d ago
    Worth mentioning that someone else in the comments converted their large library of JPEGs to JPEG XL for exactly this reason and only realized afterwards that they lost a ton of image metadata from the EXIF tags. This probably isn't what you would assume would happen for a bulk 'lossless conversion' so if you're going to do this then make sure you're validating the metadata too (if it matters to you).
janwas 21d ago
+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)
- computerbuster 21d ago
  I’ll just repeat another comment here: “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.” -jaffathecafe
  - eviks 20d ago
    > that they may mistake for complete but poor quality That's what UI is for - show an indicator that it's not complete and avoid the confusion, bringing back to the original issue But also, that's not "obviously a preview", so you have the same potential confusion here
  - janwas 20d ago
    I note you made no response to the objection about representing a temporal sequence with a single, nonrepresentative and cherry-picked, screenshot. As to bad experience, that seems like a legit personal preference, but disturbingly un-nuanced and absolutist if intended to apply to everyone. When on a train with spotty wifi or frequent tunnels, I would actually prefer to see whatever arrived. Someone on prepaid data might want to truncate at ~100 KB, no matter what the website owner or browser PM thought.
PunchyHamster 21d ago
> 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
- jaffathecake 21d ago
  Well it obviously depends on the connection, but at 3g speeds and higher, the decoding time outweighs the fairly minor bandwidth saving. And if you're displaying a cached image, the bandwidth use is zero, but the decoding still happens.
  - bjoli 21d ago
    I dont know how you calculate that, but for my phone I get the payoff (given a 30% size reduction) to be positive below anywhere from 30-43Mbps. When on celular, even 5g, I am pretty often below that.
    - jaffathecake 21d ago
      https://random-stuff.jakearchibald.com/apps/img-decode-bench/ https://random-stuff.jakearchibald.com/apps/img-decode-bench... Taking bike.jpg and bike-repackaged.jxl in that demo, on my Pixel 10 Pro in Firefox Nightly, the size and decoding times are: bike.jpg - 147 kB - 10ms bike-repackaged.jxl - 126 kB - 33ms So, I save 21 kB, but pay 23ms. That extra 21 kB isn't part of a new request, so when it comes to download performance, we're talking about an active response. At 3g speeds, in 23 ms you can download somewhere between 20-118 kB, so at best, it evens out. If it's a lower end device, the decode delta increases. If it's a faster connection, the 21 kB saving matters less. If the image was cached, then I'm just paying the decode overhead.
      - Joker_vD 21d ago
        People really, really like to try to save up on the matches, so to speak. Sometimes literally: there was a short period of time during Khrushchev's rule in the USSR when the natural gas was made free for the populace. Well, the matches still cost money (1 kopeck for a box of 50 matches), so lots of people would just not turn the stove off, instead always having it burning the smallest possible flame when not in use. All that to say, "I save 21 kB, but pay 23ms"? You'll save more if you stop sending your favourite web font over with your page and use the system fonts, and trim down your site's JS.
kps 21d ago
Agreed. Browsers should support general-purpose image formats. I'm not interested in another “web codec” that's not good for anything but passive delivery.
llm_nerd 20d ago
The entire article is extremely cherry picked, and it's notably that there are a couple of people leaving dozens of comments in here each (which is odd as normally HN gates that sort of gross overrepresentation). Like >10% of comments in this 300+ comment discussion is one single person, endlessly changing positions based upon what makes JXL worst. It's bizarre. I've never seen a format see such ridiculous attacks.
- Sabinus 20d ago
  If you're going to make claims of bad faith about other users like that you should link and quote.
innocent_name 20d ago
>Maybe a lossless re-encoding of my website JPEGs to gain 20% size is not worth the 33% I was unpleasantly surprised when jxl's reference encoder dropped critical exif tags for no reason whatsoever from my personal archives. Turns out their lossless preset wasn't really lossless. And then webp to JXL conversion also produced different viewing experience results as ffmpeg's webp decoder wasn't handling ICC correctly. I'm now very cautious of any "lossless" re-encodes.

by cbolton 21d ago

jaffathecake 21d ago

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.

tzu321 21d ago
That's a good point.
- llm_nerd 20d ago
  It's an absolutely ridiculous point, and the guy you're responding to (who has commented almost 40 times in this discussion) has a hilariously slithery opinion that somehow always finds a way to hold every finding against JXL. Personally I don't like progressive rendering at all, but it's interesting that this same guy claimed elsewhere that it's super important on a very bad connection to get an early hint of what an image is. When someone points out that the "the results speak for itself" cherry picked example is absurdly misleading, and in most cases JXL is vastly superior at that case, instantly their opinion changes such that it shouldn't look like a poor quality image but it's somehow also a win that AVIF takes longer to give you anything at all to look at. Which is incredibly weird, given that AVIF also gives you a terrible quality image, it just takes longer to show it. So it sounds like they're completely against progressive rendering? Unless they think it gives AVIF a benefit? But it's an amazing demonstration of someone with an agenda. Utterly bizarre.
  - jaffathecake 20d ago
    I also called AV1 short-sighted for not including an alpha channel, and corrected someone who claimed jxl-rs was single-threaded. No agenda here - I'm just correcting misinformation and stating my opinions. I'm not against progressive rendering - I fought for it to be part of the jxl-rs integration in browsers. I've written articles about it https://jakearchibald.com/2025/present-and-future-of-progressive-image-rendering/ https://jakearchibald.com/2025/present-and-future-of-progres.... Just because someone has a different opinion to you doesn't make them part of some grand conspiracy.
ZeroGravitas 21d ago
The quality of the preview layer is somewhat under the control of the user though. And that comparison was made for a JPEG-XL focused site, and uses quite large images that are then scaled down dramatically (at least on mobile) for display which is probably not an ideal visual test anyway (but possibly necessary for there to be enough time to see any difference)
JyrkiAlakuijala 19d ago
Depends on the user. Some users are more sensitive for flashing images. Some users have very slow or unreliable network connection. Some sites have bigger images. Some sites (such as ecommerce) have higher quality and resolution needs. Some users have uncorrected astigmatism. In the general population, the average uncorrected astigmatism typically falls between 0.50 and 0.75 diopters (D), and ~15 % more than 1.0. The high astigmatism people will see images blurred in any case and don't benefit from the fine structural detail JPEG XL can give. People with glasses and the lucky ones with low astigmatism will see the details clearly. Sometimes passionate ends of different quality of vision seem to have a discussion on what makes sense as the web quality, with one emphasizing quality 40 being more than enough and another requesting a quality of 95. The same kind of individualism exist also in temporal cognition and perception.

shevy-java 21d ago

> 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.

cbolton 21d ago
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.
- danudey 20d ago
  Worth mentioning that someone else in the comments converted their large library of JPEGs to JPEG XL for exactly this reason and only realized afterwards that they lost a ton of image metadata from the EXIF tags. This probably isn't what you would assume would happen for a bulk 'lossless conversion' so if you're going to do this then make sure you're validating the metadata too (if it matters to you).

janwas 21d ago

+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)

computerbuster 21d ago
I’ll just repeat another comment here: “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.” -jaffathecafe
- eviks 20d ago
  > that they may mistake for complete but poor quality That's what UI is for - show an indicator that it's not complete and avoid the confusion, bringing back to the original issue But also, that's not "obviously a preview", so you have the same potential confusion here
- janwas 20d ago
  I note you made no response to the objection about representing a temporal sequence with a single, nonrepresentative and cherry-picked, screenshot. As to bad experience, that seems like a legit personal preference, but disturbingly un-nuanced and absolutist if intended to apply to everyone. When on a train with spotty wifi or frequent tunnels, I would actually prefer to see whatever arrived. Someone on prepaid data might want to truncate at ~100 KB, no matter what the website owner or browser PM thought.

PunchyHamster 21d ago

> 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

jaffathecake 21d ago
Well it obviously depends on the connection, but at 3g speeds and higher, the decoding time outweighs the fairly minor bandwidth saving. And if you're displaying a cached image, the bandwidth use is zero, but the decoding still happens.
- bjoli 21d ago
  I dont know how you calculate that, but for my phone I get the payoff (given a 30% size reduction) to be positive below anywhere from 30-43Mbps. When on celular, even 5g, I am pretty often below that.
  - jaffathecake 21d ago
    https://random-stuff.jakearchibald.com/apps/img-decode-bench/ https://random-stuff.jakearchibald.com/apps/img-decode-bench... Taking bike.jpg and bike-repackaged.jxl in that demo, on my Pixel 10 Pro in Firefox Nightly, the size and decoding times are: bike.jpg - 147 kB - 10ms bike-repackaged.jxl - 126 kB - 33ms So, I save 21 kB, but pay 23ms. That extra 21 kB isn't part of a new request, so when it comes to download performance, we're talking about an active response. At 3g speeds, in 23 ms you can download somewhere between 20-118 kB, so at best, it evens out. If it's a lower end device, the decode delta increases. If it's a faster connection, the 21 kB saving matters less. If the image was cached, then I'm just paying the decode overhead.
    - Joker_vD 21d ago
      People really, really like to try to save up on the matches, so to speak. Sometimes literally: there was a short period of time during Khrushchev's rule in the USSR when the natural gas was made free for the populace. Well, the matches still cost money (1 kopeck for a box of 50 matches), so lots of people would just not turn the stove off, instead always having it burning the smallest possible flame when not in use. All that to say, "I save 21 kB, but pay 23ms"? You'll save more if you stop sending your favourite web font over with your page and use the system fonts, and trim down your site's JS.

kps 21d ago

Agreed. Browsers should support general-purpose image formats. I'm not interested in another “web codec” that's not good for anything but passive delivery.

llm_nerd 20d ago

The entire article is extremely cherry picked, and it's notably that there are a couple of people leaving dozens of comments in here each (which is odd as normally HN gates that sort of gross overrepresentation). Like >10% of comments in this 300+ comment discussion is one single person, endlessly changing positions based upon what makes JXL worst. It's bizarre. I've never seen a format see such ridiculous attacks.

Sabinus 20d ago
If you're going to make claims of bad faith about other users like that you should link and quote.

innocent_name 20d ago

>Maybe a lossless re-encoding of my website JPEGs to gain 20% size is not worth the 33% I was unpleasantly surprised when jxl's reference encoder dropped critical exif tags for no reason whatsoever from my personal archives. Turns out their lossless preset wasn't really lossless. And then webp to JXL conversion also produced different viewing experience results as ffmpeg's webp decoder wasn't handling ICC correctly. I'm now very cautious of any "lossless" re-encodes.