Chrome to Add JPEG XL Support Starting with Version 155

The Chrome team announced on October 6, 2026, that the browser will decode JPEG XL (.jxl) images starting with Chrome 155. Site owners should compare JPEG XL with AVIF using their own images and take browser support into account. The format offers another way to reduce file sizes, but the results need to be tested on actual content.

Chrome Will Support JPEG XL Starting with Version 155

JPEG XL is designed for photographs, among other uses. According to the Chrome team, it delivers 30–50% more efficient compression than JPEG and supports lossless compression, HDR, animation, and lossless conversion of JPEG files to the new format. For pages where images account for a significant share of downloaded files, the difference in size could be useful. But the figure cited in the announcement does not describe the results for every photograph on a site.

Developers are advised to try both JPEG XL and AVIF. The Chrome team expects JPEG XL to be particularly useful for photographs when high image fidelity or lossless compression matters. Another suitable use case is fine-tuning progressive decoding. Comparing the two formats matters more here than choosing one file extension for an entire site: different images and pages serve different purposes.

The announcement is about decoding—that is, the browser’s ability to open a .jxl file. It does not mean sites will automatically start serving images in the new format. Preparing and using those images remains the responsibility of the people who manage the site.

Why Chrome Chose a Rust Decoder

The browser receives images from the network and passes them to a decoder, which processes complex binary data. The Chrome team considers decoders an important security concern: memory-safety bugs in these components can lead to vulnerabilities. For JPEG XL, Chrome integrated jxl-rs, a decoder written in Rust. This change affects how the browser handles images internally, not how a designer prepares them.

Security alone was not enough: slow decoding could have made the format less useful in practice. The developers used SIMD instructions to take advantage of device capabilities and created a layer called jxl_simd for this purpose. They also confined unsafe operations to a small number of carefully reviewed sections. The implementation’s performance is monitored across different hardware platforms.

The decoder was tested using fuzzing and AI-assisted code analysis, among other methods. The team says it found no memory-safety bugs in jxl-rs during development. That describes the results of the work done so far; it is not a guarantee that no bugs will be found in the future.

Developer requests also influenced the decision to adopt the format: JPEG XL was a popular proposal in the Interop process in 2026 and earlier. Chrome took part in investigating the format as part of Interop 2026 so that browser tests would cover its capabilities and pass in Chrome. The announcement does not say when other browsers will implement JPEG XL.

What Site Owners and Teams Should Check

A good place to start is with images on important pages: prepare JPEG XL and AVIF versions, then compare them with the current files. Check both file size and whether the details visitors need are preserved. For photographs where losing detail is undesirable, it is also worth evaluating lossless compression separately. This will show the team where the new format helps a page do its job and where the difference is too small to matter.

The next question is how images will be shown to the site’s audience. Chrome has announced decoding support starting with version 155, but the announcement provides no information about support in other browsers. Before changing which files the site serves, the team needs to determine which browsers it is preparing images for and what visitors will see if their browser cannot open .jxl files. Chrome’s announcement alone is not enough reason to serve only JPEG XL to every visitor.

For a marketer, it helps to identify the images without which a page would communicate its message less effectively, along with the details that must survive compression. For a developer, the task is to check how preparing and serving .jxl files would fit into the site’s workflow. That way, the format comparison is tied to a specific page rather than a desire to use a new file extension.

My Take: Start with the Use Case, Not the Format

I wouldn’t start by replacing files across the board. I’d first choose a mobile use case and a few important photographs: on a small screen, it becomes clear more quickly which content should take priority. Then I’d compare the options and discuss the trade-off with the team: which image details need to be preserved, and where is a smaller file more valuable? The user’s needs should come before the choice of tool.

I like that Chrome suggests testing JPEG XL alongside AVIF rather than declaring a winner in advance. The format gives the team more options, but it does not decide what belongs on a page or how that page should behave in the browsers its audience uses. That product decision belongs to the people who understand the site’s purpose.

Sources

Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.

1. Shipping JPEG XL in Chrome developer.chrome.com

About the author

Ilya Fedorov

Experienced product designer

I design interfaces for financial and educational services and run design reviews within my team. My advice to beginners: name the user’s task first, then choose a tool.

All posts by the author