Intent to Ship: JPEG XL decoding support (image/jxl) in blink

[Chromestatus]

Contact emails

hjanu...@gmail.com, vel...@chromium.org

Explainer

No information provided

Specification

https://www.iso.org/standard/85066.html

Summary

Adds support for decoding JPEG XL (image/jxl) images in Blink using jxl-rs, a memory-safe pure Rust decoder (https://github.com/libjxl/jxl-rs). JPEG XL is a modern image format standardized as ISO/IEC 18181 that offers progressive decoding for improved perceived loading performance, support for wide color gamut, HDR, and high bit depth, and support for animation.

Blink component

Internals>Images>Codecs>JPEG XL

Web Feature ID

jpegxl

Motivation

(see Summary)

Initial public proposal

No information provided

TAG review

https://github.com/w3ctag/design-reviews/issues/633

TAG review status

Issues addressed

Goals for experimentation

Risks

Interoperability and Compatibility

No special risks. Note that the C++ and the Rust version are both tested against the same conformance test corpus.

Gecko: Shipped/Shipping also migrating to rust version

WebKit: Shipped/Shipping WebKit currently uses the C++ decoder.

Web developers: Strongly positive

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

New feature, no special risk

Debuggability

No information provided

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes
https://wpt.fyi/results/jpegxl?label=experimental&label=master&aligned There is extensive conformance testing outside of WPT too. WPTs show failures because the flag is disabled in wpt runs. https://wpt.fyi/results/jpegxl?sha=3d06a34791fc33532baffe64e5c48c450cb1a1b9 shows a run with the flag enabled, which has two failures. The icc-uncommon-profile-reftest.html failure is a small difference visually, currently investigating. The cmyk-basic-conversion-reftest.html failure is being fixed in https://chromium-review.git.corp.google.com/c/chromium/src/+/8275513

Flag name on about://flags

enable-jxl-image-format

Finch feature name

JXLImageFormat

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Availability expectation

Feature is available on Web Platform Baseline within 12 months of launch in Chrome.

Adoption expectation

Feature is considered a best practice for some use case within 12 months of reaching Web Platform baseline.

Adoption plan

Multiple players on the web have expressed interest in deploying JPEG XL images, including at least Cloudinary and Shopify, as well as multiple web developers during the Interop process.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

No.

Estimated milestones

No milestones specified

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

N/A

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5114042131808256?gate=6594362739916800

This intent message was generated by Chrome Platform Status.

[Yoav Weiss (@Shopify)]

LGTM1

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a8c2618.f0bac957.7b6f1.087d.GAE%40google.com.

[Yoav Weiss (@Shopify)]

I guess I can expand a bit more.. :)

This is an exciting addition to the web platform, that will enable improved image compression at reduced CPU costs on the encoding side. Thanks for pushing this through!!

[Vladimir Levin]

LGTM2. Similar to Yoav, I'm very excited for this feature 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2B1zzOXQ9DPn0za1HyMGmqkrs0DO9EfiUM62oH8fG0w4w%40mail.gmail.com.

[Mike Taylor]

LGTM3

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2PaJ-oMMAqmwjWV07RywDaec5AyFa-a6Xxf9FEy8J7ktQ%40mail.gmail.com.

[Luca Versari]

Mozilla also sent an intent to ship: https://groups.google.com/a/mozilla.org/g/dev-platform/c/3YMV4MS34KA

(sorry if you receive this email twice, my previous attempt at sending it from another address was deleted from the mailing list archive)

On Mon, Aug 24, 2026 at 1:29 PM Luca Versari <vel...@google.com> wrote:

Intent to ship from Mozilla: https://groups.google.com/a/mozilla.org/g/dev-platform/c/3YMV4MS34KA

[Luca Versari]

Intent to ship from Mozilla: https://groups.google.com/a/mozilla.org/g/dev-platform/c/3YMV4MS34KA

On Monday, August 24, 2026 at 1:08:20 PM UTC+2 Chromestatus wrote:

[一丝]

Is Animated JXL currently supported?

[Luca Versari]

Animated JXL will be enabled together with "regular" JXL.

On Tue, Aug 25, 2026 at 10:21 AM 一丝 <yio...@gmail.com> wrote:

Is Animated JXL currently supported?

[Sergey Davidoff]

I am concerned about lossless JPEG XL decoding performance. In my measurements it is 30x slower to decode than lossless WebP, in exchange for a 10% reduction in file size. This is a questionable trade-off, especially on laptops and phones where it could drain battery and degrade user experience.

I am especially concerned about CDNs adopting lossless JPEG XL to save <10% on bandwidth costs, and externalizing those costs by degrading my phone's battery life.

I suggest shipping only lossy JPEG XL initially, where the benefit is clearly demonstrated, and considering lossless JPEG XL format separately.

Measurement methodology

I've used https://github.com/sharkdp/hyperfine which measures execution time over multiple runs and collects statistics

jxl-rs from git https://github.com/libjxl/jxl-rs on commit 775837f57dfe4294d89c1c6317dd91a1ed8d3cfa compiled with 'cargo build --release'

Input image: https://commons.wikimedia.org/wiki/File:55_Cancri_e_Final_1_30.png

converted to WebP with 'cwebp -lossless', to JPEG XL with 'cjxl -d 0'

Both decoders running in single-threaded mode to measure total CPU time taken with 'taskset -c 0'.

$ hyperfine --warmup 5 'taskset -c 0 target/release/jxl_cli --speedtest 55_Cancri_e_Final_1_30.jxl' 'taskset -c 0 dwebp 55_Cancri_e_Final_1_30.png.webp'
    Benchmark 1: taskset -c 0 target/release/jxl_cli --speedtest 55_Cancri_e_Final_1_30.jxl
      Time (mean ± σ):     20.632 s ±  0.061 s    [User: 20.605 s, System: 0.027 s]
      Range (min … max):   20.549 s … 20.743 s    10 runs
     
    Benchmark 2: taskset -c 0 dwebp 55_Cancri_e_Final_1_30.png.webp
      Time (mean ± σ):     667.0 ms ±   2.2 ms    [User: 449.5 ms, System: 217.5 ms]
      Range (min … max):   664.3 ms … 670.1 ms    10 runs
     
    Summary
      taskset -c 0 dwebp 55_Cancri_e_Final_1_30.png.webp ran
       30.93 ± 0.14 times faster than taskset -c 0 target/release/jxl_cli --speedtest 55_Cancri_e_Final_1_30.jxl

For reference, libjxl's djxl tool is 20x slower than WebP in the same measurement. So it doesn't look like further optimizations to the Rust code could help, but would not change the overall calculus.

понедельник, 24 августа 2026 г. в 12:08:20 UTC+1, Chromestatus:

[Luca Versari]

There are at least three reasons to ship lossless and lossy JXL at the same time:
1) Lossless JXL is already shipped in Safari. Even if it were possible to draw a line between lossy and lossless, doing so would cause ecosystem fragmentation, which is undesirable. Moreover, the current speed does not seem to have caused significant problems in Safari.
2) The speed obtainable by lossless JXL is significantly better than what the email above suggests - first of all, jxl_cli's --speedtest option will run two decodes by default. Moreover, the encoder can be configured to prioritize decoding speed over maximum compression -- for example, setting --faster_decoding 1 does not change the compressed size significantly, but doubles decoding speed. Also, note that the linked image is almost 100 megapixels and strongly benefits from multi-threaded decoding.
3) Not all possible use-cases of JPEG XL lossless are covered by webp, i.e. >8bpc content.

[Sergey Davidoff]

The speed obtainable by lossless JXL is significantly better than what the email above suggests - first of all, jxl_cli's --speedtest option will run two decodes by default. 

I have verified it and this does seem to be the case. So make it a 15x slowdown vs lossless WebP. That is still astronomical, and my point still stands.

I've re-measured on my laptop with 'taskset -c 0 target/release/jxl_cli --num-threads 1 --num-reps 1 --warmup-reps 0 --speedtest' and I'm seeing a 20x slowdown in practice. Not sure why it's higher than the theory - the lack of AVX-512 on this machine is to blame.

Moreover, the encoder can be configured to prioritize decoding speed over maximum compression -- for example, setting --faster_decoding 1 does not change the compressed size significantly, but doubles decoding speed. 

Then perhaps only fast-decoding lossless mode should be supported in web browsers. A 7.5x slowdown instead of 15x might be excusable, depending on the use case.

Also, note that the linked image is almost 100 megapixels and strongly benefits from multi-threaded decoding.

Multi-threading helps with latency on some systems but does not meaningfully affect power usage. And given that a webpage contains not only images and the CPU is already busy processing the rest of it, multi-threading is less of a boon to latency in a web browser than in an image viewer.

I do not mean to derail this thread into a discussion of the details of the lossless mode and what can be done about it. Rather, I believe the lossless compression mode of JPEG XL has not received enough attention on its cost-benefit analysis (unlike the lossy mode), and should not be included in a stable release in web browsers until compelling evidence for its use cases and trade-offs is provided.

[Birk Hirdman]

Moreover, the encoder can be configured to prioritize decoding speed over maximum compression -- for example, setting --faster_decoding 1 does not change the compressed size significantly, but doubles decoding speed. 

Then perhaps only fast-decoding lossless mode should be supported in web browsers. A 7.5x slowdown instead of 15x might be excusable, depending on the use case.

 

Surely websites can select compression options that fit their use cases? Perhaps all that is needed is to change the default in libjxl's CLI tool to use faster_decoding=1.

[Sergey Davidoff]

What I am concerned about is CDNs using lossless JPEG XL to cut their network costs, and externalize those costs by degrading battery life for all users with recent enough browsers. They are financially incentivized to do so, and that is why I am so concerned about giving them the opportunity.

вт, 25 авг. 2026 г. в 20:16, Birk Hirdman <lon...@gmail.com>:

[Philip Jägenstedt]

I think this is a real risk, but we should expect adoption to ramp up quite slowly, and that there will be time to optimize. The usage can be seen at https://webstatus.dev/features/jpegxl or https://chromestatus.com/metrics/webfeature/timeline/popularity/418 (same underlying data) and should start rizing from ~0 only after this reaches stable.

[Sergey Davidoff]

It is not clear if significant further optimization is even possible. libjxl, the original highly optimized C++ implementation, was also 20x slower to decode than WebP in my measurements. This indicates that we're more likely than not in the realm of diminishing returns already. Rushing the stabilization in hopes that further dramatic optimizations might be possible seems reckless.

ср, 26 авг. 2026 г. в 10:32, Philip Jägenstedt <foo...@chromium.org>:

[dev null]

I don't see a reason to break an important feature of an image format just because some small amount of users might have slightly less battery life if they browse special sites serving a lot of lossless images.

The vast majority of sites and CDN's deliver lossy images to users, they have a far greater incentive to deliver lossy images, as that's far more efficient for both them and the users, there is no good reason to assume this will meaningfully impact the average user at all.

There is no reason to assume JXL lossless optimization won't dramatically improve, while you can consider the lossy encoding well optimized, lossless has not yet received as thorough of an optimization, and optimization for both is still not as mature as codecs like WebP which have been around for 15+ years, and have far more users.

I personally have a great use of JXL lossless images as I have huge archives of lossless images on my personal home server, but considering I like to view most of those images in browsers on my devices, I have been blocked from converting my archive, and have been waiting for several years for Chrome to add JXL support, especially lossless.

I would be heartbroken to still not be able to use JXL's excellent lossless compression, after all these years of waiting.

[Aleksandr Ivanov]

A huge 100mpx lossless image rendering on a web page is not a valid use
case for a typical browser user.

[Aleksandr Ivanov]

Again, that's not a real scenario. No one in their sane mind would view
100mpx lossless file for fun in the first place.

[Alexander Ivanov]

I'm not sure why lossless decoding performance is an issue. If I'm on a mobile device I will be more concerned downloading a huge lossless image in the first place, the speed of decoding is irrelevant at this point. I don't believe that it is a realistic scenario that "CDNs will externalise costs". JXL benefits outweigh this imaginary scenario.

[Sergey Davidoff]

Consider that if the image is cached, the decoding cost is paid over and over and over every time the page is opened, negatively affecting power use and responsiveness, while 10% in download size is saved only once.

вт, 1 сент. 2026 г. в 09:27, Alexander Ivanov <a...@hexmode.org>:

[Sergey Davidoff]

A single large image is the best-case scenario for jxl-rs decoder, and is easy to measure. According to Mozilla's intent to ship announcement, jxl-rs performs even worse when decoding many small images, so this benchmark is the best-case scenario for decoding performance.

вт, 1 сент. 2026 г. в 10:12, Aleksandr Ivanov <a...@hexmode.org>: