JPEG XL Chrome becomes a reality with Chrome 155, released on October 6, 2026, but that does not justify immediately replacing WebP and AVIF. JPEG XL primarily offers potential benefits for faithful photographs, large images, and lossless recompression of JPEG files. For a production site, the right strategy is to test it while retaining several fallback formats.
What changes with the arrival of JPEG XL in Chrome 155?
Chrome 155 decodes JPEG XL by default since October 6, 2026, on ordinateur, Android, and Android WebView. The browser recognizes files .jxl served with the MIME type image/jxl. This development makes the format viable on a large scale, but its compatibility remains below that of WebP and AVIF.
JPEG XL is an image format standardized in the ISO/IEC 18181 series since 2021. It supports lossy compression, which removes certain informations to reduce file size, and lossless compression, which preserves all image data.
The format also supports alpha transparency, animation, HDR (extended brightness range), wide colorimetric color spaces, and progressive decoding. The latter progressively displays a usable image instead of waiting for the full download, a noticeable advantage for large photographs and slow connections.
JPEG XL implementation in Chrome relies in 2026 on jxl-rs, a decoder written in Rust and designed to limit memory-management errors. Mozilla selected the same component for Firefox. This shared choice simplifies technical maintenance, without guaranteeing that all features will be identical across browsers.
Should WebP and AVIF be replaced by JPEG XL?
JPEG XL should not systematically replace WebP and AVIF in 2026. Google recommends comparing AVIF and JPEG XL according to the images, while Mozilla also believes that the outcome depends on the content and the requested quality level. WebP and AVIF remain the safest options for compatible delivery.
JPEG XL is particularly interesting for high-fidelity photographs, large-dimension images, and lossless requirements. It can also recompress an existing JPEG file without modifying its pixels, with savings of approximately 20 % reported in the technical literature cited by Google in 2026.
AVIF often retains an advantage for photographs intended for the web and visuals combining flat areas, sharp edges, and details. WebP remains relevant lorsque the priority is simple processing and broad compatibility. Honestly, replacing an entire functional WebP library is not justified without measurements on the site's actual images.
The following table summarizes the results published by Mozilla on August 24, 2026. These are two samples, not a universal ranking: the encoder, quality setting, and content can reverse the result.
| Image and setting | JPEG XL | AVIF | WebP | Useful interpretation |
|---|---|---|---|---|
| Photography, medium to high lossy quality | 134 kB | 116 kB | Not reported | AVIF is lighter in this sample |
| Photography, lossless | 1.45 MB | 1.76 MB | 1.55 MB | JPEG XL is the lightest in this sample |
| Screenshot, very high lossy quality | 23.8 kB | 11.6 kB | Not reported | AVIF is significantly lighter here |
| Screenshot, lossless | 92 kB | 164 kB | 96 kB | JPEG XL slightly outperforms WebP |
These measurements show why an overall average can lead to a poor decision. Google indicates in 2026 that JPEG XL can produce files 30 to 50 % smaller than comparable JPEGs, but this gain does not predict its performance against a cororrectly encoded AVIF.
Which browsers support JPEG XL in 2026?
JPEG XL compatibility remains classified as “limited availability” by Web Platform DX in 2026. Safari 17 and iOS Safari 17 have supported the format since September 18, 2023, and Chrome 155 since October 6, 2026. Firefox 158 was scheduled to enable it on October 13, 2026, a future date as of October 10.
WebP and AVIF, for their part, are supported by current versions of Chrome, Microsoft Edge, Firefox, and Safari in 2026. A company therefore should not distribute only JPEG XL files until the browsers actually used by its audience have been checked.
The presence of a format in a browser does not always mean that every feature is available. On August 24, 2026, Mozilla noted in particular that Safari’s implementation did not yet support progressive rendering or animation. A static photo gallery and a marketing animation therefore do not carry the same level of risk.
On the agency side, the standard practice is to review audience data before modifying the image pipeline. A global average matters less than the actual distribution of browsers on a business extranet, an online store, or a site primarily accessed on iPhone.
How can JPEG XL be deployed without displaying broken images?
Reliable JPEG XL deployment relies on the HTML element , which provides multiple sources in a ordre-defined format. A browser ignores a MIME type it does not recognize and loads the next compatible source. A final JPEG or PNG must remain available to cover older environments.
A reasonable migration begins with a small set of representative visuals, not by converting the entire media library. The following steps reduce technical risk and make it possible to measure the actual benefit:
- Select photographs, screenshots, images with transparency, and large visuals corresponding to the site's uses.
- Encode each file in JPEG XL and AVIF with comparable visual quality, then retain WebP or JPEG as a fallback.
- Declare the sources in
, withtype="image/jxl", thentype="image/avif"andtype="image/webp". - Check the MIME type sent by the server, the amount of data transferred, decoding time, and rendering across the audience's browsers.
- Automate generation only after validating the settings, and plan for rollback.
This automation must be incorporated into deployment procedures just like patch management without production downtime. An encoding library updated without testing can change the file sizes, quality, or processing time of thousands of images.
The same reasoning applies to large media files: an image and a video require versions adapted to their channel. Choosing a format should extend the thinking applied to the difference between a website video and an Instagram video, rather than seeking a single file for every use case.
Does JPEG XL automatically improve perforformance and SEO?
JPEG XL does not automatically improve the referencing naturally. A smaller file can speed up display and reduce transferred data, but the result also depends on dimensions, lazy loading, caching, and decoding time. Google does not present the choice of JPEG XL as a direct ranking advantage in 2026.
The useful gain is measured on the visitor's device. A Chromium engineering discussion published on August 26, 2026, raised the case of certain lossless JPEG XL encodings whose decoding could be significantly slower than WebP's, with a possible cost in CPU usage and battery life.
On the projects we work on, we often see teams save a few kilobytes while serving an image twice as large as its on-screen placement. Responsive resizing—that is, sending a size suited to the device—generally produces a more obvious benefit than changing the format alone.
At a minimum, track the amount of data transferred, Largest Contentful Paint, or LCP (the time required to display the main content), loading errors, and server consumption related to encoding. These data also contribute to a broader visibility strategy, alongside SEO and GEO criteria to priororitize to make content accessible to search engines and AI systems.
What strategy should you choose for a site in production?
For a site in production in 2026, the least risky strategy is to add JPEG XL to the existing formats rather than remove them. Start by testing it on large photographs, JPEG archives, and lossless images. Keep AVIF or WebP, followed by JPEG or PNG, as fallback solutions.
The right trade-off depends on the cost of conversion, the volume of images, and the observed gain. On a business website comporising just a few already lightweight visuals, an additional generation pipeline can sometimes add more maintenance than it saves in bandwidth. Conversely, a large photo library or an image-rich catalog may quickly justify testing.
The decision can be made with three simple questions: Does JPEG XL actually reduce file sizes at equal quality, do your visitors' browsers use it, and does decoding remain smooth on mobile? If any answer is missing, keep the experiment behind a reversible configuration.
Establishing the image pipeline upstream avoids unnecessary bulk conversions and late compatibility issues. An outside perspective can be especially helpful in defining a test protocol related to perforformance, audience devices, and hosting constraints.
FAQ about JPEG XL in Chrome
Which version of Chrome supports JPEG XL files?
Chrome 155 reads JPEG XL files by default as of October 6, 2026. Support covers Windows, macOS, Linux, ChromeOS, Android, and Android WebView.
Which file extension and MIME type should be used for JPEG XL?
A JPEG XL file uses the extension .jxl and must be sent with the MIME type image/jxl. Incorrect server configuration may prevent the browser from using the file corcorrectly.
Can JPEG XL convert a JPEG without any loss of quality?
JPEG XL can losslessly transcode an existing JPEG file, preserving its pixels while potentially reducing its file size. The technical literature cited by Google in 2026 reports savings of approximately 20% for this operation.
Does WordPress automatically support JPEG XL?
Browser compatibility alone does not guarantee automatic handling by WordPress, its extensions, and its hosting provider. Uploading, variant creation, MIME type, caching, and fallback formats must be tested on the installation concerned.
Does JPEG XL replace traditional JPEG?
JPEG XL does not replace encore classic JPEG for universal distribution in 2026. JPEG remains useful as a fallback format, while JPEG XL can reduce the file size of photographs or archives lorque the browser supports it.