image
Why the web needs JPEG XL
Our response to Chrome decision to drop support for JPEG XL.
Laurent Cazanove November 9, 2022 · 5 min read
Since the advent of JPEG in 1992, it took nearly 20 years for formats like WebP and AVIF to deliver a major shakeup to images on the web. But those formats always came with limitations inherent to the video codecs they were derived from. Recently, the industry has been rallying behind JPEG XL, a new format designed to meet modern needs in terms of image delivery. But on October 31st, the Chrome developers announced their decision to remove support for JPEG XL.
JPEG XL: the one image format to rule them all?
Before discussing Chrome's decision, let’s take a look at the benefits this new JPEG XL format has to offer.
First, it comes with high-fidelity encoding, which obviously is a priority for still images. As a rule of thumb, JPEG XL is the most efficient codec for higher quality, lossless images.
"JPEG XL is excellent for those who want to share lossless photos. However, for web delivery [...]"
— Jon Sneyers (@jonsneyers) July 24, 2021
For web delivery jxl is excellent too. Most images on the web are (the equivalent of) libjpeg q60-90. Avif beats jxl below the equivalent of q40. Above q50, jxl is better.
Moreover, JPEG XL supports progressive decoding, which enables low-quality image placeholders to be rendered before downloads are finished. Both these features are made possible because JPEG XL is a codec built for images, not videos.
Another area where JPEG XL consistently outperforms other modern codecs is encoding and decoding speeds, particularly in multi-threaded architectures.
| Codec | Encoding speed (MP/s) | Decoding speed (MP/s) | ||
|---|---|---|---|---|
| Single core | Four cores | Single core | Four cores | |
| JPEG (libjpeg-turbo) | ~50 | ~100 | ~200 | ~110 |
| WebP | ~5 | ~10 | ~140 | ~70 |
| AVIF | ~1 | ~3 | ~20 | ~50 |
| JPEG XL | ~15 | ~50 | ~30 | ~130 |
Finally, JPEG XL allows for lossless JPEG recompression. It is possible to recompress existing JPEG files to JPEG XL files that would be 20% smaller on average with no image degradation. To this day, the web is still full of servers hosting millions of JPEG files. Allowing them to transition to JPEG XL would result in massive savings in both storage and bandwidth usage. We believe these environmental issues should not be overlooked.
Demonstrating ecosystem interest for JPEG XL
Considering the undeniable improvements brought by JPEG XL, Chrome’s decision to remove support for JPEG XL was met with skepticism, particularly when Chrome developers said that “there [was] not enough interest from the entire ecosystem to continue experimenting”. In fact, major actors such as Adobe, libvips, Cloudinary, or Shopify had already manifested interest. Since the announcement, the comments blew up in the issue tracker.
“JPEG XL is the first image format to address the entire media management chain. On the storage front, it can transparently replace JPEG with no loss in quality. On the distribution front, it has better compression with better image fidelity than AVIF on birates ranges that count. Finally, it is not the power-hungry, carbon-emitting disaster that AVIF proved to be which makes JPEG XL suitable for dynamic image generation.” — Julian Aubourg, Chief Product Officer at TwicPics
Chrome’s decision does not make sense to us. On a technical level, they advanced that the benefits were not sufficient compared to existing formats. But research shows that the improvement from AVIF to JPEG XL is comparable to the improvement from (traditional) JPEG to WebP, or WebP to AVIF. And both WebP and AVIF enjoyed Chrome’s support – which was critical to their adoption.
Moving forward
Through this article, we hope to modestly contribute to the ecosystem effort urging Chrome developers to reconsider their decision. If you’re a tech company or ecommerce owner that has interest in JPEG XL support, we can only encourage you to make your voice heard.
Edited on Nov 10th (fixed encoding speed benchmark for JPEG and WebP)