In particular, I don’t think there was significant progress on compression between libjxl v0.10.0 and v0.12.0, and there some regressions from earlier versions still remain. The article also measures the quite recent jixel, which is derived from the older libjxl-tiny and apparently does better in many cases. So JPEG XL encoders definitely have lots of room for improvement. With JPEG XL finally gaining wider adoption on the web, perhaps they’ll catch up or get ahead again. AV1 encoders are also still being improved, though.

As the article points out, this might change yet again in the future, depending on how much AVIF keeps improving and whether JPEG XL development picks up steam again and how far it’ll go.

AVIF uses the AV1 codec. For the past several years, AV1 has been enjoying a wide interest and a continuous stream of improvements as the best, open, royalty-free video codec around that pretty much everyone had agreed to support from the get go.

JPEG XL started out with a smaller group behind it and took a massive hit when Google decided not to support it in Chrome (and by extension, the entire web, because market share). That made JPEG XL’s future as the universal format very uncertain for a few years. Excitement waned, development slowed down and was further divided to develop a new encoder which Mozilla later said they wanted.

So for a good while, AVIF was steadily improving and approaching its full potential, while JPEG XL was not. The article compares the current state of the current encoders; in no way does it indicate how good the formats themselves are. The article makes note of this. [2] It’s been known for years that JPEG XL compression can still be improved by quite a bit, so I imagine the current encoders are still far from reaching the format’s full potential. (Heck, they don’t even make use of all its features from what I know!) Back when it was first proposed, JPEG XL was very competitive. With interest in the format hopefully renewed, we might see it catch back up with AVIF and overtake it again. Or we might not. We have no way of knowing for sure right now.

  [1]: https://news.ycombinator.com/item?id=50128587
  [2]: https://jakearchibald.com/2026/jpeg-xl-vs-avif/#:~:text=Both%20AVIF,in%20future

Not to call into question the article’s author’s expertise, just to point out that they are a single individual and not an authoritative source (which you haven’t implied, but some people might read that way).

Have you tried encoding with JPEG XL’s modular mode? By default, libjxl only uses it for lossless and I haven’t tried with jixel, but in my experience, it often handles clean edges and smooth surfaces (the likes of which you might see in digital art) better.

> I'm a little nervous about this, because discourse around JPEG XL can get a little… weird.

As someone who’s been rooting for JPEG XL for years now, I also find the discourse a little upsetting. When first introduced, the format was very competitive with AVIF and steadily improving, until Google decided to single-handedly halt web adoption (de facto, because market share). No careful evaluation presented, no solid argumentation given.

My understanding is that the future of the format became uncertain at that point, because web adoption is regarded as crucial and no one wants to go all-in on a codec that may not end up filling the universal role it was designed for. Of course, AV1 encoders kept seeing lots of interest and improvement in the meantime, because everyone was already all-in on AV1 for video.

And now, when JPEG XL has finally painstakingly clawed its way back onto its original trajectory, now there are comparisons popping up showing how AVIF actually compresses better. People end up quoting them around social media, painting the picture that JPEG XL turned out to be the inferior format after all. It hasn’t, it just got a massive handicap.

Not that it’s a problem with your article. It’s informative, you compare the current state of available encoders for a specific use case, and you mention how they’re still evolving. It just sucks that we can’t really do a fair comparison of the formats at this point, yet that’s exactly what people will end up doing anyway, and it’ll really suck if it ends up hurting JPEG XL even more than Google already has.

Wikitionary adds the nuance of the prompter not understanding the generated code well. [4] If we go by that definition, Raku++ is not vibecoded. Would you say this definition is more correct? (I only go by what I’ve been hearing and able to find so far, so I might have missed something.)

  [1] https://www.merriam-webster.com/dictionary/vibe%20coding
  [2] https://dictionary.cambridge.org/dictionary/english/vibe-coding
  [3] https://www.collinsdictionary.com/dictionary/english/vibe-coding
  [4] https://en.wiktionary.org/wiki/vibe_coding

[1] https://github.com/ash/rakupp/

  [1] https://blog.mozilla.org/opendesign/arrival/
  [2] https://blog.mozilla.org/en/mozilla/mozilla-brand-next-era-of-tech/

To give a comparable example, I hate proprietary software, but I still run some of it on my computer, because avoiding all proprietary software everywhere is extremely impractical in current day and age. You can take a meaningful stance against something without being Stallman levels of principled.

By his standards, as I understand them, AI should respect and preserve the copyright of the data it’s trained on. Since that is not the current practice, he doesn’t want AI training on his works or generating derivative art, and prefers to avoid AI-generated works in general (including software). I don’t see any discrepancy or hypocrisy in that, nor do I see how your ComfyUI example relates. A clarification would be much appreciated!

> he’s quite happy not to even discuss that and instead take the position that the maintainers said it’s fine.

Where does he take that position?