Cloudinary clarity: Google ditches JPEG XL, where do we go from here?

This is a guest post for the Computer Weekly Developer Network written by Jon Sneyers in his role as senior image researcher at Cloudinary, a company that works with brands around the world to create, manage and deliver online experiences at scale. 

Sneyers is also the co-chair of the JPEG XL ad hoc group and co-creator of the Free Lossless Image Format (FLIF) – and he writes as follows…

Earlier this month, Google did something that really puzzled developers around the world: it rejected the JPEG XL image handling standard for Chromium (the open source project underpinning the Google Chrome browser and many others including Edge, Opera, Vivaldi and Brave).

Many developers who’ve had to work with images for the web or mobile devices have come to appreciate the new JPEG XL standard. A free raster-graphics file format that supports both lossy and lossless file compression and excels at image handling on the latter.

Using it saves about 60% in storage space when compared to the original, 30-year-old JPEG standard, while offering even higher perceptual quality. Like JPEG, XL is optimised for photography and does a great job at depicting qualities like texture and other fine details.

Google has said that its decision is down to what it sees as low JPEG XL adoption, insufficient technical benefits and that it sees its best way forward now for images on phones is to improve existing formats like WebP and AVIF. As a key contributor to JPEG XL, I respectfully rebutted these points on my company’s blog.

One point I’ll highlight here is the self-fulfilling prophecy in the Chromium team saying there’s “not enough ecosystem interest” these days. As things stand now, the decision will prompt any developers interested in JPEG XL to rapidly lose interest and so fatally undercut its potential.

But we are where we are.

It can’t be denied that Google’s decision has left a lot of professionals feeling a little high and dry as to where to go next. To help, I have pulled together some thoughts for teams that see great value in, or have put significant development resourcing into adding JPEG XL support in their project. 

So please consider the following points:

• A practical way forward, on the web at least, is to use a WASM-based workaround to load JPEG XL images – which is to say, developers can make a workaround (‘polyfill’) using Web Assembly code to provide support for JPEG XL. This code already exists as a demo and as I write, the JPEG XL team is currently working on making it easier to deploy such a solution. Of course, native browser support would be preferable, both performance-wise and in terms of developer convenience, but at least some of the benefits of JPEG XL could be obtained this way.
• Another way forward is to adopt JPEG XL outside the Web, e.g., in mobile apps that are not browser based. In principle, an app could ship its own JPEG XL decoder; as this only has a footprint of about 200 kb and thus quite small compared to typical app sizes, a package could still benefit from the significant file size reductions JPEG XL offers in its bundled image assets. Doing this will also more than compensate the cost of shipping a JPEG XL decoder, especially if there are additional images transferred over the network.
• Finally – and perhaps most importantly, I think – developers interested (or already invested) in JPEG XL should not just wait until browser support somehow happens. Instead, they must be vocal and explicitly ask browsers (and not only Chrome) to proactively commit to adding JPEG XL support.

Sneyers: Community involvement counts.

I do understand that browser devs understandably don’t lightly decide to add new things to their web platform; they are already complex enough. I also do get that it means they need to be convinced that it will actually be used by web developers; they can’t read our minds, so it’s important to speak up if developers who see value in JPEG XL want to be heard.