JPEG XL Returns to Chrome: What This Means for Your Images

Chrome 145 shipped native JPEG XL decoding in February 2026, reversing its controversial 2022 removal. Learn what changed, how JXL compares to AVIF and WebP, and when to start using it.

Published April 15, 2026 · Updated April 15, 2026

In October 2022, Google removed JPEG XL support from Chrome. The decision was framed as a matter of insufficient ecosystem interest and the existence of other modern formats like AVIF and WebP. It was, to put it mildly, controversial. Developers, photographers, and standards bodies pushed back hard. Petitions were signed. Bugs were filed. The discourse was loud and sustained.

Three and a half years later, JPEG XL is back in Chrome. Version 145, which shipped to stable in February 2026, includes native JXL decoding powered by a new Rust-based decoder called jxl-rs. The reversal is not just a technical milestone — it is a statement about what the web actually needs from an image format, and about how format wars eventually resolve when the engineering is good enough.

Here is what happened, why it matters, and what you should actually do about it.

The Removal and the Backlash

When Chrome dropped JPEG XL in late 2022, the reasoning was that WebP and AVIF already covered the use cases that JXL targeted. The Chrome team argued that supporting too many image formats added maintenance burden and attack surface, and that the data did not show enough demand for JXL specifically.

The photography and publishing communities disagreed. JPEG XL had properties that neither AVIF nor WebP could match. It supported lossless JPEG recompression — the ability to take an existing JPEG file and re-encode it into JXL with zero quality loss and roughly 20% smaller file size, with the original JPEG perfectly reconstructable. No other modern format offered this. For anyone managing large archives of JPEG images, this was transformative.

JXL also had progressive decoding built into its core design, something AVIF still lacks. A progressively decoded image loads in successive passes, showing a low-quality preview almost immediately and refining it as data arrives. On slow connections or for large images, this produces a dramatically better user experience than waiting for an entire file to download before anything appears.

Safari added JPEG XL support in Safari 17 (September 2023). Firefox followed in early 2025. Chrome was the holdout, and its absence meant web developers could not rely on JXL for broad deployment despite two of three major engines supporting it.

What Changed: jxl-rs and the Rust Rewrite

The technical catalyst for Chrome's reversal was jxl-rs, a ground-up Rust implementation of the JPEG XL decoder. The original C++ reference implementation (libjxl) was functional but carried the complexity and memory safety concerns that come with large C++ codebases. Google's security team had flagged image decoders as a persistent source of vulnerabilities — parsing untrusted image data from the web is inherently dangerous, and C++ makes it harder to eliminate entire classes of bugs.

jxl-rs changes the equation. Written in safe Rust, it eliminates buffer overflows, use-after-free bugs, and the other memory safety issues that have historically plagued image decoders in browsers. The decoder is also significantly smaller than libjxl, which reduced the binary size concerns that were part of Chrome's original objection.

Performance benchmarks show jxl-rs decoding speed within 5-10% of the optimized C++ implementation for most image types, with better performance on some edge cases involving complex progressive scans. For Chrome's purposes, the security benefits alone would have justified a modest performance trade-off, but in practice there was barely any trade-off to accept.

How JPEG XL Compares in 2026

With JXL now supported across Chrome, Safari, and Firefox — covering well over 95% of global browser traffic — the practical question becomes when to use it versus the alternatives.

JXL vs JPEG

This comparison is almost unfair. JPEG dates from 1992 and uses techniques that were state-of-the-art three decades ago. JPEG XL consistently produces files 60% smaller than JPEG at equivalent visual quality for photographic content. At very low bitrates, the difference is even more dramatic because JXL avoids the block artifacts that make highly compressed JPEGs look like they were assembled from bathroom tiles.

The lossless recompression path is the unique advantage here. If you have existing JPEG files, you can convert them to JXL with zero quality loss and get roughly 20% savings. When you need the JPEG back — for a legacy system, an email attachment, a platform that does not support JXL — the original JPEG can be perfectly reconstructed. No other format offers this bidirectional lossless path with JPEG.

JXL vs WebP

WebP was Google's first attempt at a JPEG replacement, based on the VP8 video codec. It is a solid format that delivers around 25-30% smaller files than JPEG, but JXL surpasses it on almost every technical metric. JXL achieves better compression ratios, supports higher bit depths (up to 32-bit float), handles wider color gamuts natively, and includes progressive decoding. WebP's lossy mode is limited to 8-bit color in the YUV 4:2:0 colorspace, which makes it unsuitable for HDR content or workflows that require precise color.

WebP still has an edge in encoding speed for quick, on-the-fly conversions, and its tooling ecosystem is more mature simply because it has been around longer. But as a compression technology, JXL is a generation ahead.

JXL vs AVIF

This is the more interesting comparison because AVIF is also a modern, highly efficient format. Both achieve substantially better compression than JPEG or WebP. In head-to-head compression benchmarks, JXL and AVIF trade wins depending on the content type, with AVIF typically performing slightly better on photographic images at very low bitrates, and JXL performing better on images with text, sharp edges, or synthetic content.

The real differences are in features and workflow:

Progressive decoding. JXL supports true progressive rendering. AVIF does not. For large images on variable connections, JXL provides a visually complete (if lower-quality) image much faster.

Encoding speed. JXL encodes significantly faster than AVIF at comparable quality levels. AVIF's encoding is derived from AV1 video encoding, which is computationally expensive. This matters for real-time conversion workflows and for services that need to encode images on the fly.

Lossless compression. Both formats support lossless encoding, but JXL achieves better lossless compression ratios in most tests, and its lossless JPEG recompression feature has no AVIF equivalent.

HDR and wide gamut. Both support HDR and wide color gamuts, but JXL was designed with these use cases as first-class priorities. The PDF Association specifically named JPEG XL as its preferred format for HDR content in PDF documents, citing its superior tone mapping and color space handling.

Ecosystem maturity. AVIF has been in all major browsers for longer, so more CDNs, CMSes, and image processing pipelines support it natively. JXL support is catching up rapidly now that Chrome has joined, but there is still a tooling gap that will take months to fully close.

When to Use Which

There is no single winner. The right choice depends on your specific situation:

Use JPEG XL when:

You are archiving or managing large JPEG collections (lossless recompression)
You need progressive decoding for large images or slow connections
Your content includes text overlays, screenshots, or mixed synthetic/photographic imagery
You are working with HDR or wide-gamut content for print or PDF
Encoding speed matters (batch processing, real-time conversion)

Use AVIF when:

You are optimizing web delivery of photographic content and every byte counts
Your audience uses modern browsers (same as JXL now, effectively)
You are already invested in AV1 tooling for video and want format consistency
You need animated images (AVIF sequences are well-supported)

Use WebP when:

You need maximum compatibility with older browsers and devices
Encoding speed is the top priority and compression gains are secondary
Your workflow is already built around WebP and the savings from switching are marginal

The PDF Association and HDR

One of the most consequential endorsements for JPEG XL came from the PDF Association, which designated JXL as the preferred image format for HDR content in PDF documents. This decision carries weight because PDF is the lingua franca of print publishing, archival, and professional document exchange.

The reasoning is straightforward. JPEG XL supports perceptual quantization (PQ) and hybrid log-gamma (HLG) transfer functions natively, along with ICC profiles, CICP signaling, and the full range of color spaces that professional workflows require. AVIF supports some of these features, but JXL's handling of tone mapping metadata — the instructions that tell a display how to render HDR content on screens with different capabilities — is more comprehensive and more precisely specified.

For photographers, designers, and publishers who work with HDR imagery, JXL in PDF means they can deliver documents where the images retain their full dynamic range and color information, with the display adapting the rendering to its own capabilities. This is not an abstract technical benefit — it is the difference between an image that looks flat and washed out on a standard monitor versus one that looks correct everywhere.

Practical Steps: Converting Your Images

If you have been waiting for full browser support before adopting JPEG XL, that barrier is gone. Here is how to start using it.

Converting Existing JPEGs

The lossless recompression path is the lowest-risk way to start. Take your existing JPEG files, convert them to JXL with lossless mode, and store the JXL versions. File sizes drop roughly 20% with zero quality loss, and the original JPEG is perfectly recoverable if you need it.

On Fileza.io, you can drag and drop JPEG files and convert them to other formats entirely in your browser. No files leave your device, which matters when you are working with personal photos or client images that should not be uploaded to a third-party server.

Converting from PNG or Other Lossless Sources

If you have lossless source files (PNG, TIFF, camera RAW), converting to JXL with lossy compression at quality settings around 75-85 will produce visually excellent results at dramatic file size reductions. The compression gains over JPEG are roughly 60%, which means a 5 MB JPEG becomes roughly a 2 MB JXL at equivalent or better visual quality.

Serving JXL on the Web

With Chrome, Safari, and Firefox all supporting JXL, you can use the HTML <picture> element to serve JXL with a fallback:

<picture>
  <source srcset="photo.jxl" type="image/jxl">
  <source srcset="photo.avif" type="image/avif">
  <img src="photo.jpg" alt="Description">
</picture>

This gives browsers their preferred format while maintaining backward compatibility. CDNs like Cloudflare and Fastly are adding JXL to their automatic image optimization pipelines, so if you use a CDN with image transformation, check whether JXL delivery is available as an option.

Batch Conversion

For large image libraries, batch conversion is essential. Fileza.io supports multi-file drag-and-drop, so you can convert dozens of images in a single session without uploading anything to a server. For truly massive archives (thousands of images), command-line tools like cjxl (from the libjxl project) can process files in automated pipelines.

What This Means Going Forward

Chrome's decision to restore JPEG XL support is significant beyond the technical details. It signals that the browser ecosystem has moved past the idea that one or two modern formats can serve all use cases. AVIF is excellent for certain tasks. JXL is excellent for others. WebP fills gaps where legacy support matters. Developers and content creators now have genuine choice, and the best format depends on the specific requirements of each project.

The web has also gained something rare: a modern image format with a lossless migration path from the format it aims to replace. You do not have to re-encode your JPEG archives at some lossy quality level to benefit from JXL. You can convert them losslessly, save space immediately, and convert back perfectly if you ever need to. That kind of backward compatibility is unusual in format transitions, and it removes the biggest risk that typically slows adoption.

For everyday use, the action is simple. If you are working with images — converting between formats, optimizing for the web, archiving photos — JPEG XL is now a practical option everywhere. Tools like Fileza.io let you convert between JXL, AVIF, WebP, JPEG, and PNG directly in your browser, with no uploads, no accounts, and no waiting for server-side processing. The format war may not be over, but with JXL back in Chrome, the options available to you just got meaningfully better.