JPEG XL, the New Image Format Nobody Wanted or Needed

JPEG XL is a new next-generation image format courtesy of The Joint Photographic Experts Group.

Because, you know, that's what we need. More goddamn image formats with inconsistent software support…

Like AVIF, it aims to tackle everything and, like AVIF, it manages to do so with mixed success.

Hoping to avoid the fates of sibling formats JPEG 2000, AI, AIC, LS, Pleno, Systems, XR, XS, XT — which never managed to take off — the JPEG folks are marketing JPEG XL aggressively. The spec was only frozen a few months ago, but already there are open feature tickets with nearly every open source browser, operating system, programming language, image editor, CMS, etc., asking for its inclusion.

The first browser to support JPEG XL, albeit behind a feature flag, is likely to be the upcoming Google Chrome v.91, currently in beta. Until then, .jxl images will be a bit difficult to actually preview.

If you want to start playing around with the technology immediately, you can clone the JPEG XL development repo, install all the build dependencies, and manually compile the documentation, libjxl libraries, and cjxl/djxl conversion tools.

But enough about that. The real question is, is it worth it?

How's JPEG XL Lookin'?

TL;DR, JPEG XL is okay.

Like any image format — including oldsters like JPEG and PNG — it is optimized for certain types of image data and will come out better or worse depending on the nature of the source.

It does usually produce smaller output than JPEG and PNG sources, but falls somewhere in between the next-generation WebP and AVIF formats on average.

JPEG XL encoding speeds are typically much faster than AVIF's, but that advantage begins to disappear as images get larger than a few thousand pixels on a side, at which point performance falls off a cliff.

That's the overview, anyway. Let's take a look at some actual data!

In the Wild

On a whim, we added JPEG XL support to our guided image conversion tool refract and recrunched all of the images on this web site in WebP, AVIF, and JPEG XL.

This isn't a particularly image-heavy site, but it has images in a range of sizes and composition, including all the combinations of greyscale, color, and alpha.

Anyhoo, here's how everything turned out for us:

This chart simply compares the overall file sizes, selecting the smallest for each given source.

For our site, AVIF is the clear winner, producing the smallest output roughly half the time. The star of this article, JPEG XL, comes in second with about twice as many wins as WebP.

Interestingly, PNG managed to take home a win with the following image, which none of the new kids could improve upon:

Update 2021-10-22 Jon Sneyers demonstrated it is possible for JPEG-XL to improve upon this PNG by leveraging the advanced group size setting:

cjxl poe.png -q 100 -s 9 -g 3 poe.jxl

# 30090 poe.png
# 26519 poe.jxl

The Poe sprite is an exception, though.

For the most part, all three formats provide consistent savings compared to JPEG and PNG:

Had we opted for "good enough" rather than "visually indistinguishable" compression, the totals would have been even more impressive, but 30-50% ain't bad.

The ordering is still the same as in the first chart, but here AVIF and JPEG XL sit much closer to each other than either does to WebP.

But there's nuance to consider…

The Curse of Chronology

JPEG XL, being the newest new format on the block, comes with a severe disadvantage that moots most of its compression wins relative to WebP.

Consider the following code, prioritizing sources based on the average savings in the previous chart.

There's a logical flaw. Can you spot it?

<picture>
    <source src="image.avif" type="image/avif">
    <source src="image.jxl" type="image/jxl">
    <source src="image.webp" type="image/webp">
    <source src="image.jpg" type="image/jpeg">
</picture>

As written, no browser would ever select the image.jxl source for the simple reason that any browser supporting image/jxl would also support image/avif.

Put another way, to actually use JPEG XL to any benefit, it has to beat every other format, a problem compounded by the fact that <source> elements actually require srcset rather than src.

By contrast, WebP only needs to beat the original JPEG/PNG source to be useful.

With that in mind, the final chart shows the total number of uses site-wide for each format.

In this view — the one that ultimately matters! — JPEG XL drops to a distant third. It simply doesn't beat AVIF often enough to warrant much inclusion.

Should You Use It?

Probably not.

Given its mediocre compression savings relative to AVIF and its terrible performance relative to WebP, it is hard to imagine a use case for the new format.

Maybe if you're working on a small bleeding-edge microsite that, once live, will never change, JPEG XL could save you a few bytes. But even then, the added time and complexity required to integrate the format would be hard to justify.

We added JPEG XL to our own site because we're obsessive — and don't have to pay for development! — but the encoding process took hours to complete and resulted in only a handful of usable images.

But hey, it gave us a blog post, so wasn't a total loss. Haha.