Browsers Are Embracing JPEG XL Again: WebP Cloud Now Supports JXL by Default

Last month, we came across a particularly interesting piece of news: both Firefox and Chrome were preparing to enable JPEG XL support by default.

At first glance, this may look like browsers simply adding one more image format. JPEG XL’s history, however, has been anything but straightforward. Chrome once offered experimental support, only to remove it in 2023. Safari 17 became the first major browser to ship JPEG XL later that year. Then, in 2026, the increasingly mature Rust decoder jxl-rs brought both Chrome and Firefox back to the format.

We have now enabled JPEG XL output by default on WebP Cloud as well. Like AVIF, JXL is generated asynchronously in the background and automatically joins the set of output candidates once it is ready. Users do not need to change their image URLs or enable any additional settings.

Why browsers are returning to JPEG XL

JPEG XL is a modern, royalty-free bitmap format with both lossy and lossless compression. Beyond compression efficiency, it supports progressive rendering, alpha transparency, animation, high bit depth, wide color gamuts, and HDR. It can also losslessly transcode an existing JPEG into JXL and later reconstruct the original JPEG data.

Chrome initially integrated experimental JPEG XL support, but later concluded that ecosystem adoption and maintenance commitments were not sufficient to justify enabling it by default. The implementation was removed around Chrome 110. This decision attracted plenty of controversy: without Chromium support, websites, CDNs, and image tools had little incentive to adopt the format, while the resulting lack of adoption could then be cited as a reason not to support it.

Safari 17 added JPEG XL support in 2023 using libjxl, the C++ reference implementation. Mozilla had also evaluated libjxl, but was concerned about the attack surface associated with roughly 100,000 lines of multithreaded C++. It therefore gave the JPEG XL team a clear challenge: build a safe, performant, compact, and compatible decoder in Rust.

Google Research subsequently developed jxl-rs, and both Firefox and Chrome began integrating JPEG XL around this memory-safe Rust implementation. Mozilla published its “Intent to Ship: JPEG XL” in August 2026, while Chrome submitted its own Intent to Ship at almost the same time.

There is one important update to the timeline reported in the original news. Firefox initially intended to enable JPEG XL by default in version 157, but the remaining work took longer than expected, so the target moved to Firefox 158. Firefox 157 still includes the Firefox Labs option and the image.jxl.enabled preference for users who want to enable it manually. Chrome, meanwhile, has listed JPEG XL decoding in the Chrome 155 Release Notes, also using jxl-rs.

As of this article, Safari already enables JPEG XL by default, while default support in Firefox and Chrome is moving through their release processes. JPEG XL is finally becoming more than an experimental format available in a small collection of tools: it is gaining a realistic path to becoming a production Web output format.

Choosing between JXL, AVIF, and WebP

WebP, AVIF, and JPEG XL are all newer than traditional JPEG and PNG, but there is no universal ranking that applies to every image.

Mozilla’s JPEG XL announcement contains a useful comparison. AVIF often produces smaller files for photographs at typical Web quality, while JPEG XL tends to perform particularly well for lossless images. JPEG XL also offers a compelling form of progressive rendering: before the full file has arrived, the browser can display a low-detail version of the complete image and gradually refine it as more data is downloaded, rather than leaving the user staring at an empty area.

This is why we do not intend to claim that every site should switch entirely to JXL, or that JXL will always be smaller than AVIF. Image content, lossy versus lossless operation, quality settings, and encoder implementations all affect the outcome. A better approach is to prepare several candidate formats and select the smallest one that each visitor’s browser can decode.

How WebP Cloud supports JXL

WebP Cloud users do not need to change .jpg or .png URLs to .jxl, nor do they need to maintain multiple sources in a <picture> element. An original image URL can remain as simple as:

https://example.com/images/demo.png

After the site is connected to WebP Cloud, visitors continue to request the same path. WebP Cloud reads the browser’s explicitly declared capabilities from the Accept header, then selects a smaller supported candidate from the original image, WebP, AVIF, and JPEG XL. The selected file is returned with the correct Content-Type.

This negotiation model follows the same direction described in our recent article, “WebP Server Go 0.16.0: More Reliable Image Format Negotiation and CDN Caching”: the browser declares what it supports instead of the server trying to infer capabilities from the User-Agent string.

Because AVIF and JPEG XL encoding require considerably more computing resources than WebP, WebP Cloud does not make visitors wait for JXL encoding on the first request. JXL is generated through the background conversion pipeline:

1. WebP Cloud fetches the source image and completes the basic processing and fast conversions needed for the current request.
2. Additional candidates such as AVIF and JPEG XL enter the background conversion pipeline.
3. While those files are not yet ready, WebP Cloud safely returns the original image, WebP, or an already available AVIF instead of sending a file that does not exist or cannot be decoded.
4. Once JXL conversion finishes, subsequent requests automatically include it in the candidate set. If the browser supports JXL and the JXL file is smaller, WebP Cloud returns image/jxl.

JXL is enabled by default for every WebP Cloud user. Existing cached images are also being backfilled in the background, so users do not need to purge and regenerate their caches one image at a time.

Comparing a real image

We tested a build-output screenshot from this blog and used width=900 to generate equally sized cached variants:

Test URL: https://p2k7zwb.webp.ee/libvips-cgo/build.png?width=900

For each request, we advertised only PNG, WebP, AVIF, or JPEG XL in the Accept header, then recorded the Content-Type and file size actually returned by WebP Cloud:

For this screenshot, the JXL output is only 9.7% of the original size. It is about 8.6% smaller than the WebP version and 30.5% smaller than the AVIF version. A visitor whose browser advertises JPEG XL support will therefore receive JXL. If the browser supports only AVIF and WebP, WebP Cloud will serve WebP because it is the smaller candidate for this particular image.

This result illustrates why dynamic selection matters. AVIF often achieves excellent compression, but WebP happens to be smaller for this screenshot, and JXL is smaller than both. One screenshot cannot represent every photograph, illustration, or interface capture, and WebP Cloud is not designed to force one fixed format. Its job is to perform the comparison for each image and visitor.

You can verify the JXL response yourself by explicitly advertising JPEG XL with cURL:

curl -sS -D - -o /dev/null \
  -H 'Accept: image/jxl' \
  'https://p2k7zwb.webp.ee/libvips-cgo/build.png?width=900'

Once background conversion is complete, the response includes:

Content-Type: image/jxl
Content-Length: 56641
X-Compression-Rate: 0.09
Vary: Accept

The same request may temporarily receive image/png while the background conversion is still in progress. That is the compatibility fallback doing its job. A later request automatically switches to the generated image/jxl response.

What do users need to do?

Nothing.

JPEG XL output is already enabled by default for all users. Websites keep their existing image URLs, while WebP Cloud prepares JXL in the background and selects the response based on browser support and actual file size. Browsers that do not yet support JPEG XL continue to receive WebP, AVIF, or the original image, so images will not suddenly stop rendering. As Chrome and Firefox enable JXL by default, more visitors will naturally begin receiving JXL versions.

When we added AVIF in 2023, we used background conversion to balance compression efficiency against real-time request performance. JPEG XL continues the same approach. A new format does not need to replace every older format to be valuable; it gives each image one more opportunity to use a better representation.

If you already use WebP Cloud, this feature is now working for you in the background. If you do not, you can sign in to the WebP Cloud Dashboard and create a Proxy to let WebP Cloud handle image conversion, caching, and browser compatibility automatically.

References

1. Intent to Ship: JPEG XL - Mozilla Hacks
2. Intent to ship: JPEG XL - Mozilla dev-platform
3. Firefox JPEG XL target moved to version 158
4. Intent to Ship: JPEG XL - Chromium blink-dev
5. Chrome 155 Release Notes
6. Image file type and format guide - MDN
7. JPEG XL official website