Chrome JPEG XL Support: Choosing an Image Format in 2026

The Chrome developer blog says Chrome 155 arrives with JPEG XL decoding support. According to the post, the format offers 30-50% better compression than JPEG, lossless compression and built-in HDR support. Alongside these come lossless conversion of an existing JPEG and fine-grained progressive decoding; progressive decoding means an image sharpens piece by piece as it loads.

Two limits of the post are worth knowing. First, it covers decoding only: Chrome will be able to show a JPEG XL file, but producing the file is the job of your toolchain. Second, the method behind the 30-50% figure is not given. The decoder is the Rust-based jxl-rs, with the Chrome team citing memory safety, and interoperability is being verified through the Interop 2026 review. The team recommends trying both AVIF and JPEG XL.

For most business sites, no. The first reason is the spread of support: Chrome supports it, but the state of other browsers is not in our sources. You can see which browsers your visitors use in your own analytics, and the decision should follow that spread. The second reason is the toolchain: the program that prepares your images, your content management system and any CDN must be able to write and serve the format. Their state differs from site to site.

Third, a gain is not promised before it is measured. 30-50% is Chrome's wording; it does not guarantee the same result for your images. First measure your current file sizes with the rabbitclip image compression and site speed tools, and compare the JPEG XL trial against that reference.

Not every browser supports JPEG XL, so the general principle is this: do not use the new format as the only source. One way is to give several sources with the picture element and let the browser pick the one it supports. The other is for the server to read the request header and hand over the right file by content type; this is usually an image service or CDN setting.

Whichever method you choose, a conventional fallback file must always exist. Without one, a visitor whose browser does not know the format sees an empty box, and you can lose customers for weeks without noticing.

• Put the JPEG XL source first in the picture element and the widely used source last
• Or have the server choose the right file by content type
• Always keep and serve the fallback file
• Check that the cache layer does not mix up different formats

According to the Chrome developer blog, Chrome 154 came out on 22 September 2026. It brought an iframe that sizes itself to its content height (frame-sizing: content-height, with the embedded page agreeing through a meta tag), links and tabs modes for scroll-marker-group, and text-decoration-inset. It has no direct bearing on image formats.

It still carries a reminder for a business site: Chrome adds new features with every release, and most of them are not needed by you. If you write code by hand to set the height of an embedded appointment form, the iframe change may reduce that code; leave that judgement to your developer.

The most common mistake is treating the new format as a gain in itself. Even if file size shrinks, a missing fallback or a broken toolchain turns the gain into a loss. The second is deleting the original high-quality files and keeping only the converted copy.

The third is deciding without measuring. Changing the format without knowing on which pages image weight is a problem improves the wrong place.

• Serving the format as the only source with no fallback
• Deleting the original files
• Not measuring before and after
• Deciding without looking at the visitor spread

If your site has few images and your speed measurements show no problem, the work of changing the format may outweigh the benefit. If your toolchain cannot write JPEG XL, replacing the tool should not be the first step either. If you need neither HDR nor lossless compression, the format's strongest points do not touch you.

The wrong choice is this: converting every image overnight because the announcement appeared, and leaving no fallback. The right order: measure, try a few images, serve with a fallback, measure again.