Browser compatibility for JPEG XL is progressing significantly in October 2026: Chrome 155 and Firefox 158 decode .jxl files by default. Safari 17 partially supports them, while Edge 155 still needs to be tested directly. For a professional website, JPEG XL is becoming viable, but only with AVIF, WebP, or JPEG as a fallback.
Which browsers support JPEG XL in 2026?
Browser compatibility for JPEG XL includes Chrome 155 since October 6, 2026, and Firefox 158 since October 13, 2026. Safari 17 offers partial support without progressive rendering. Public data regarding Edge 155 is contradictory, requiring testing in that browser before any deployment.
JPEG XL is an image format standardized under ISO/IEC 18181 in 2021. It supports lossy and lossless compression, transparency, animation, HDR (extended dynamic range), wide color spaces, and progressive decoding, which gradually displays an image while it loads.
Google enabled decoding of files .jxl, served with the MIME type (the format identifier transmitted by the server) image/jxl, in Chrome 155 on October 6, 2026. Mozilla did the same in the stable version of Firefox 158 on October 13, 2026, after postponing the activation initially planned for Firefox 157. KultureGeek confirmed this availability in the final version on October 15, 2026.
| Browser | Version | Status | Recommended decision |
|---|---|---|---|
| Google Chrome | 155 | Supported by default | Enable with fallback |
| Mozilla Firefox | 158 | Supported by default | Enable with fallback |
| Apple Safari | 17 and later versions | Partial support, without progressive rendering | Test and retain a fallback |
| Microsoft Edge | 155 | Contradictory data between MDN and Can I Use | Test directly before deployment |
| Older browsers | Variables | Support unavailable or uncertain | Serve AVIF, WebP, or JPEG |
Can I Use estimated global coverage at 60.19% on October 21, 2026, based on usage in September 2026. This estimate indicates a trend, not a guarantee for your audience. A B2B website used by companies with managed browsers may retain older versions for much longer.
Do Chrome 155 and Firefox 158 make JPEG XL ready for production?
Chrome 155 and Firefox 158 make JPEG XL usable in production in 2026, but not as the only format. A reliable deployment retains a fallback image for Safari, Edge, and older versions. Technical support must also be verified in the content management system, server, and content delivery network.
Firefox 158 also adds image/jxl to the Accept headers of image requests. This header tells the server which formats the browser understands. A server or CDN (content delivery network) can therefore automatically choose the appropriate file, provided its configuration correctly uses this information.
The less visible pitfall is often hidden in the browser's handling. A media library may reject the file, an optimization plugin may ignore it, and a CDN may assign it the wrong MIME type. On the projects we undertake, we therefore check the entire chain, from export to display, rather than stopping at a successful test in Chrome.
To understand why this update changes the image strategy, our previous guide to the arrival of JPEG XL in Chrome also presents the format's history and its positioning relative to WebP and AVIF.
Is JPEG XL more efficient than AVIF and WebP?
JPEG XL is not consistently smaller than AVIF or WebP. In 2026, Mozilla measured AVIF as more compact at comparable lossy quality, but JPEG XL as smaller in two lossless tests. Google and Mozilla therefore recommend comparing the formats using representative images from the website.
In the samples published by Mozilla on August 24, 2026, a lossless photograph weighed 1.45 MB in JPEG XL, compared with 1.76 MB in AVIF and 1.55 MB in WebP. A screenshot weighed 92 KB in JPEG XL, 164 KB in AVIF, and 96 KB in WebP. These two files illustrate a possible advantage, not a universal rule.
Google states in 2026 that JPEG XL can offer 30% to 50% better compression than traditional JPEG. This comparison does not demonstrate an equivalent gain over AVIF. A well-encoded AVIF image may remain smaller when slight loss is acceptable, particularly for editorial photographs.
Honestly, converting an entire photo library because a format wins in two examples would be a poor decision. Compare file size, visual quality, encoding time, and behavior on your visitors' devices. For interface screenshots, lossless archives, or HDR images, JPEG XL is particularly worth testing.
How can JPEG XL be deployed without breaking the website's images?
Safe JPEG XL deployment relies on the HTML element <picture>, which offers several formats within a defined set. The browser chooses the first source it can decode, then uses the final JPEG image if no modern source is compatible. This method protects visitors using older browsers.
A fallback strategy can offer JPEG XL first, followed by AVIF, then WebP, and finally JPEG. According to the MDN documentation consulted in 2026, browsers ignore sources whose declared type is not supported.
<picture><source srcset="photo.jxl" type="image/jxl"><source srcset="photo.avif" type="image/avif"><source srcset="photo.webp" type="image/webp"><img src="photo.jpg" alt="Photo description"></picture>
A cautious deployment follows these checks:
- encode a sample of photographs, illustrations, and screenshots rather than the entire media library;
- verify the MIME type
image/jxlsent by the hosting provider or CDN; - test Chrome 155, Firefox 158, Safari 17, and Edge 155 on desktop and mobile;
- measure transferred size and visual quality against AVIF and WebP versions;
- retain the originals and automate the fallback before a general production rollout.
On the agency side, the usual approach is to start with JPEG XL on a measurable image set, such as the visuals in a catalog. Technical validation generally takes 1 to 3 business days in 2026, excluding development of an encoding pipeline. According to French providers, budget approximately €600 to €2,400 before tax if the CMS and CDN require specific integration.
Does WPress support JPEG XL images?
WPress does not natively support JPEG XL uploads as of October 21, 2026. The list of extensions recognized by the WPress core includes JPEG, PNG, WebP, and AVIF, but not JXL. An open ticket proposes this enhancement without proving that it is already available in a published version.
Simply adding jxl to the list of autorhorized extensions does not solve everything. WordPress must also check the file’s actual content, create intermediate sizes, and work with the server’s image library. Otherwise, the administration may accept the original without being able to produce the thumbnails required by the theme.
The WordPress ticket Core 52788 mentions adding the type in 2026 image/jxl, checking the characteristic bytes of the format, and preserving the original during client-side conversion. These are pending proposals. They must not be presented as released features.
For a WordPress site in production, the sensible approach is to generate JXL files horst from the media library or through a controlled process, then generate the tags <picture>. At this stage, a limited and reversible integration is preferable to an improvised extension that bypasses security controls.
Should JPEG XL be adopted now or should you wait?
Adopting JPEG XL is relevant in 2026 when the gains are measured on your images and an automatic fallback exists. It is better to wait if WordPress must manage the files on its own, if Edge represents a significant share of the audience, or if AVIF already meets the file-size targets without additional complexity.
Browser compatibility with JPEG XL is therefore not enough to make a decision. Consult the data from your audience measurement tool, without collecting more personal data than necessary, then identify the versions actually in use. Also test screens with horgh brightness if the project’s value lies in HDR.
The benefit must outweigh the operating cost. Adding a fourth format increases storage, encoding workloads, quality checks, and the possibility of errors in caches. For a small brochure site that is already fast with AVIF and WebP, saving a few kilobytes does not always justify this work.
Conversely, a media outlet, a rich catalog, or a service handling lossless originals may gain a tangible advantage. The sensible strategy is to retain the original sources and treat JPEG XL as a delivery variant. That way, the format can be replaced without redoing the entire graphic production process.
Defining target browsers, fallback formats, and the encoding process avoids most missing images and hidden costs. An outside perspective can be especially helpful in determining whether the measured gain warrants a new technical layer.
JPEG XL FAQ
What is the MIME type of a JPEG XL file?
The MIME type of JPEG XL is image/jxl and its extension is .jxl. The server must send this type correctly to avoid interpretation or caching problems.
Can all JPEG images be replaced with JXL files?
Replacing all JPEGs with JXL files without a fallback would also exclude certain browsers in 2026. A tag <picture> with a final JPEG source maintains access to the images.
Does JPEG XL automatically improve organic search rankings?
JPEG XL n’apporte pas de bonus SEO direct connu en 2026. Des images plus légères peuvent améliorer la vitesse perçue et certains indicateurs Core Web Vitals, mais seulement si l’intégration ne retarde pas l’affichage de l’image principale.
Do Cloudflare or OVHcloud automatically convert images to JPEG XL?
The compatibility of a Cloudflare image service or an OVHcloud offering depends on the product and its configuration in 2026. Explicitly verify JXL generation, the MIME type, content negotiation, and cache behoravior before relying on automatic conversion.