On October 6, 2026, Google announced that Chrome 155 will officially support decoding the JPEG XL (.jxl) image format. Users will be able to view JPEG XL images directly in Chrome without enabling an experimental feature. The format, which Google chose not to support in 2022, is returning with a new decoder written in Rust.
JPEG XL can recompress existing JPEG images without any loss of quality, and it can show the overall picture while a file is still downloading. However, it does not always produce the smallest file for images used on websites, and in some cases formats such as AVIF have the advantage.
With official support in Chrome, web developers will find it easier to choose an appropriate format, considering not only image quality and file size but also how quickly an image can be displayed. Drawing on Google's official announcement and the public discussions during development, we look at JPEG XL's characteristics and the challenges ahead.
JPEG XL, Once Withdrawn, Returns to Chrome With a Rust Decoder
Chrome's earlier decision not to support JPEG XL was driven not only by compression performance but also by concerns about processing speed and the development and maintenance burden.
In November 2022, Google's Jim Bankoski explained that adopting a new image format requires a comprehensive evaluation, including compression performance across a variety of images and decoding speed when displaying small images.
Important factors also include how much time and computing resources are needed to compress an image, and whether other browsers and operating systems support the format.
As the number of supported formats grows, the burden of continuing to support each additional format falls not only on website operators but also on browser and device developers.
After weighing these factors, Google announced a plan to end the experimental JPEG XL implementation at the time and remove the related code.
The conditions for reintroducing the format became clear in November 2025.
Chrome's Rick Byers said the team would welcome the integration of a fast, memory-safe JPEG XL decoder. He explained, however, that enabling it by default would require securing a long-term maintenance structure and meeting the usual release standards.
The public discussions in 2022 and 2025 show that what Chrome required was not only JPEG XL's compression performance but also an implementation that could be integrated safely into the browser and maintained over the long term.
The decoder adopted to meet those conditions is jxl-rs, a JPEG XL decoder developed in Rust.
The Chrome 145 release notes record that jxl-rs was introduced as an experimental feature. Now, Google has announced that it will be enabled by default starting with Chrome 155.
In other words, the JPEG XL format itself has not been redesigned. Official adoption in Chrome became possible because a decoder that can process the existing specification safely and quickly is now available.
Rust Aims to Combine Safety and Speed
An image decoder is a program that parses the data of an image file received over the internet and converts it into a form that can be shown on screen.
Because it directly processes data sent from outside, a crafted image that triggers unauthorized memory access could lead to security problems.
With jxl-rs, the developers use Rust's memory-safety mechanisms while also incorporating the optimizations needed for fast image processing.
Particularly important is the use of SIMD instructions, which process multiple pieces of data at once.
Google explains that it achieved fast processing while maintaining safety through extensions to Rust's capabilities and a dedicated SIMD processing foundation.
The developers have also limited the operations that require particular care in managing memory safety to a small number of thoroughly reviewed locations.
However, adopting Rust does not mean the program as a whole is free of vulnerabilities.
This change does not sacrifice processing speed for safety, nor is it a declaration that every security issue has been resolved. Aiming to deliver both safety and performance is what led to official adoption.
JPEG XL's Strengths: Exact Restoration of Existing JPEGs and Progressive Display
One of JPEG XL's major features is that it lets you make direct use of the widely used JPEG images that already exist.
According to the JPEG standardization committee, JPEG XL can recompress existing JPEG files without losing information.
If necessary, it can also restore a JPEG file that is identical to the one before conversion.
For example, a server could store images in JPEG XL and deliver them as JPEG XL to supporting browsers, while converting them back to the original JPEG format for environments that do not support JPEG XL.
The key point here is what "restorable" means.
It does not simply mean that an image that looks the same can be regenerated. The distinctive feature is that the original JPEG file can be restored exactly, data unit for data unit.
According to the technical documentation for the reference implementation libjxl, in addition to the image information contained in the original JPEG, JPEG XL can retain information called "jbrd," which is needed to reconstruct the original file, along with the necessary metadata.
Even when representing the same image, JPEG files can differ in their internal data structure. Reproducing the original file itself, not just the appearance of the image, therefore requires additional information.
jbrd is not needed simply to display an image, but it is essential for fully restoring the original JPEG file.
Therefore, when adopting JPEG XL as a storage format, you need to confirm not only that the converted image displays correctly but also that the information needed for restoration is retained.
This feature does not recover image quality that was lost when the JPEG was first compressed.
It is a mechanism that recompresses an image already saved as a JPEG without losing any more information, and that can return it to the original file when needed.
Showing the Overall Image Before the Download Completes
Another feature is that an image can be displayed progressively before the download finishes.
With JPEG XL's VarDCT mode, low-frequency components representing the rough brightness and color of the whole image can be sent first, followed by detailed information.
As a result, a blurry image is shown at first and gradually sharpens as more data is received.
On web pages with large photos, users can grasp the content of a photo at an early stage without waiting for the image to finish downloading.
Traditionally, image display speed has been evaluated with an emphasis on download completion time and file size.
But if JPEG XL's progressive display is used, the time until users can recognize what an image shows also becomes an important evaluation criterion.
JPEG XL vs. AVIF: Which Compresses Better?
Although JPEG XL has high compression performance, it cannot make files smaller than AVIF under every condition.
In a comparison Mozilla published in August 2026, the ranking of the two formats reverses between lossy and lossless compression, even with the same photo.
The Mozilla comparison article uses a photo of a fox sleeping on grass.
For lossy compression, which discards some pixel information, the comparison was made with the visual-quality metric SSIMULACRA 2 matched at 62.8.
For lossless compression, the comparison was made under the condition that the original pixel information is fully preserved.
| Compression condition for the same photo | AVIF | JPEG XL | JPEG XL size relative to AVIF |
|---|---|---|---|
| Lossy (SSIMULACRA 2 = 62.8) | 116kB | 134kB | 15.5% larger |
| Lossless (pixel information fully preserved) | 1.76MB | 1.45MB | 17.6% smaller |
The size difference was calculated with AVIF as the baseline, using "(JPEG XL size ÷ AVIF size − 1) × 100," rounded to one decimal place.
With lossy compression, JPEG XL is 15.5% larger, whereas with lossless compression it is 17.6% smaller.
In other words, even for the same photo, changing the compression conditions reverses which format produces the smaller file.
The result suggests that the best image format may differ between saving a photo at high quality and delivering it on an ordinary web page.
When the pixel information must be fully preserved, JPEG XL's lossless compression is a strong option.
On the other hand, when you want to keep quality at a certain level while making the file smaller, AVIF can sometimes be the better fit.
Google also recommends trying both JPEG XL and AVIF to get the best results.
However, the figures Mozilla published are only the results of a comparison using one specific photo.
The article does not show every encoder version and detailed setting, and the figures do not represent average compression performance across all photos.
It is important to compare using the images you actually serve, with the target quality matched.
Is JPEG XL Decoding "30 Times Slower"? A Measurement Corrected Among Developers
When choosing an image format, you need to consider not only file size but also the time the decoding process takes to display the image.
In the public discussion about official adoption in Chrome, the processing load of displaying losslessly compressed JPEG XL images became a topic of debate.
In August 2026, Sergey Davidoff, a participant in the discussion, reported that when he losslessly compressed an image of about 100 million pixels and compared decoding speeds using a single-threaded command-line tool, JPEG XL was about 30 times slower than lossless WebP.
In response, developer Luca Versari pointed out that in the test setup used for the measurement, the decoding process is run twice by default.
Davidoff acknowledged the point and corrected his original figure of "about 30 times" to "about 15 times."
Versari also explained that JPEG XL offers ways to prioritize decoding speed through compression settings, and that for very large images like this one, parallel processing across multiple threads is effective.
In other words, measurement results can vary widely depending on the type of image, the compression settings, the number of times decoding is run, and whether parallel processing is used.
Furthermore, what was used in this discussion was an implementation still under development and a huge losslessly compressed image of about 100 million pixels.
It does not mean that photos displayed on ordinary websites in Chrome 155 will be uniformly 15 times slower than WebP.
Nor is it a result of directly measuring actual display time in the browser or battery consumption on devices such as smartphones.
Still, the discussion points to an important issue in evaluating image formats.
Smaller files reduce the amount of data transferred over the network. But if displaying the image requires heavier processing, CPU load and power consumption on the device may increase.
The savings in delivered data and the burden of decoding therefore need to be verified separately.
Ultimately, it is important to measure the time from receiving an image to rendering it on screen on the devices actually in use, and to judge whether the experience is truly better for users.
Differences Between Browsers Remain Even After Chrome's Official Support
Chrome 155's JPEG XL support is a major step forward for the format's usability across major browsers.
However, being able to display an image is a separate matter from being able to use all of JPEG XL's features in the same way in every browser.
According to the implementation status a Mozilla developer presented in August 2026, the JPEG XL support that began with Safari 17 does not include progressive image display or animation.
It was also explained that Firefox converts HDR images to SDR for display.
Such differences cannot be seen from a simple table of supported and unsupported browsers.
Google and Mozilla have adopted the same Rust decoder, but the way images are processed on actual web pages differs by browser, so behavior needs to be verified in each environment.
To address this issue, JPEG XL has also been selected as a subject of investigation in Interop 2026, an effort to improve compatibility between browsers.
The Interop 2026 JPEG XL investigation covers color management and HDR as well as progressive display and animation.
There are also plans to test its use not only in HTML image elements but also in CSS background images and Canvas.
Efforts continue to make the features built into the JPEG XL specification usable on actual web pages regardless of the browser.
Websites Will Need to Adapt Too
With official support in Chrome 155, website operators will find it easier to generate JPEG XL images and serve them directly to supporting browsers.
However, browser support for an image format does not automatically change how a website generates and delivers its images.
To adopt JPEG XL, sites need to prepare alternative images such as JPEG or AVIF for older browsers that do not support it.
It is also essential to choose a format according to the type of image and the quality required, and to check display speed and processing load on actual devices.
For example, if the goal is to store original JPEG images without losing information, JPEG XL's recompression feature is a major advantage.
On the other hand, on web pages with large photos, progressive display, which lets users grasp an image's content partway through the download, could be useful.
For ordinary web delivery images, AVIF can sometimes produce smaller files, so the formats need to be used according to purpose.
Chrome 155's official adoption does not mean JPEG XL will replace every other image format.
What matters is that the range of image formats web developers can choose from expands, depending on whether they prioritize image quality, file size, or display speed.
Once compatibility between browsers and delivery environments are in place, JPEG XL could see wider adoption across a broad range of uses, from storing high-quality images to displaying images efficiently on web pages.