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

to blin...@chromium.org, foo...@chromium.org, hjanu...@gmail.com, vel...@chromium.org

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

Debuggability

No information provided

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

Yes

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

Yoav Weiss (@Shopify)

unread,

to Chromestatus, blin...@chromium.org, foo...@chromium.org, hjanu...@gmail.com, vel...@chromium.org

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!!

to Yoav Weiss (@Shopify), Chromestatus, blink-dev, Philip Jägenstedt, hjanu...@gmail.com, vel...@chromium.org

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

Mike Taylor

unread,

Luca Versari

unread,

to blink-dev, Chromestatus, foo...@chromium.org, hjanu...@gmail.com, vel...@chromium.org

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

to blink-dev, Luca Versari, Chromestatus, Philip Jägenstedt, hjanu...@gmail.com, vel...@chromium.org

to 一丝, blink-dev, Chromestatus, Philip Jägenstedt, hjanu...@gmail.com, vel...@chromium.org

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

to blink-dev, Chromestatus, Philip Jägenstedt, hjanu...@gmail.com, vel...@chromium.org

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

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

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'.

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.

to Sergey Davidoff, blink-dev, Chromestatus, Philip Jägenstedt, hjanu...@gmail.com

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.

to Luca Versari, blink-dev, Chromestatus, Philip Jägenstedt, hjanu...@gmail.com

to blink-dev, Sergey Davidoff, blink-dev, Chromestatus, Philip Jägenstedt, hjanu...@gmail.com, Luca Versari

to Birk Hirdman, blink-dev, Chromestatus, Philip Jägenstedt, hjanu...@gmail.com, Luca Versari

Philip Jägenstedt

unread,

to Philip Jägenstedt, Birk Hirdman, blink-dev, Chromestatus, hjanu...@gmail.com, Luca Versari

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.

to blink-dev, Sergey Davidoff, Birk Hirdman, blink-dev, Chromestatus, hjanu...@gmail.com, Luca Versari, Philip Jägenstedt

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.

to Sergey Davidoff, blink-dev, dev null, Birk Hirdman, Chromestatus, hjanu...@gmail.com, Luca Versari, Philip Jägenstedt

to Sergey Davidoff, blink-dev, dev null, Birk Hirdman, Chromestatus, hjanu...@gmail.com, Luca Versari, Philip Jägenstedt

to blink-dev, dev null, Sergey Davidoff, Birk Hirdman, blink-dev, Chromestatus, hjanu...@gmail.com, Luca Versari, Philip Jägenstedt

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.

to Alexander Ivanov, blink-dev, dev null, Birk Hirdman, Chromestatus, hjanu...@gmail.com, Luca Versari, Philip Jägenstedt

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.

to Aleksandr Ivanov, blink-dev, dev null, Birk Hirdman, Chromestatus, hjanu...@gmail.com, Luca Versari, Philip Jägenstedt