Intent to prototype: JPEG XL decoding in Rust

[Kagami Rosylight]

(The previous intent in 2021 is here.)

Summary: JPEG XL is a new emerging image format that has been adopted by multiple software as of 2026. The format is now getting an alternative, more memory-safe implementation written in Rust.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1986393
Specification: https://www.iso.org/standard/85066.html
Standards Body: ISO/IEC
Platform coverage: All
Preference: image.jxl.enabled
Link to standards-positions discussion: https://github.com/mozilla/standards-positions/issues/522
Other browsers:

• Blink: Implemented with the same underlying Rust library behind the preference #enable-jxl-image-format. Their intent to prototype is updated in 2025-11.
• WebKit: Shipped in Safari 17.0 in 2023.

web-platform-tests: A limited set of tests are in https://wpt.fyi/results/jpegxl?label=master&label=experimental&aligned. 

[Martin Thomson]

Hi Kagami,

What questions do you think you would answer with a prototype?  It seems like this is about getting an implementation in place in preparation for shipping, but not committing to shipping.  That's a good plan in this case.

I've discussed this with Jake and my understanding is that the Rust implementation is currently about 2x slower than the (unsafe) C++ reference implementation.  That doesn't seem like it would be good for Firefox, especially since the C++ implementation is still substantially slower than decoders for other formats.  At what point would we think the code is fast enough to ship?

Are there other things that a prototype might need to resolve before shipping?  Features in the format we might need extra capabilities to support, like progressive rendering or wide gamut or anything in the long list of features for the format?

--
You received this message because you are subscribed to the Google Groups "dev-pl...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-platform...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/53b4e3e0-5eee-4768-a1ba-b069e1e85244n%40mozilla.org.

[Kagami Rosylight]

Hi Martin,

Yeah, it's more like "let's start and iterate on a prototype and we'll see how it goes". Once we get the prototype we can get the performance data on Gecko to investigate further. (I wonder Jake also have CLI benchmark comparison, which would draw a line of how fast the browser integration can be. Too much difference from CLI benchmark would point out a potential integration issue.)

I think I would be positive to ship it when the performance is comparable enough to existing formats like AVIF. (The definition of "comparable" can be discussed further.) If it turns out to be impossible, we'll need some investigation.

For extra features, I'd probably say we should support everything we support for AVIF when shipping. (Probably not wide gamut because I don't think we support it right now, while we should definitely have progressive rendering.)

CC'ing tnikkel as image is more of his module and he may have different opinions.

Kagami

[Jake Archibald]

I don't have a CLI benchmark unfortunately, just https://random-stuff.jakearchibald.com/apps/img-decode-bench/. Also https://random-stuff.jakearchibald.com/apps/partial-img-decode/ for testing progressive rendering.

Comparing the performance to AVIF seems to trigger arguments around the size images should be on the web, because JXL performs closer to AVIF at larger file sizes (less compression), and JXL folks will argue that's what should be the norm on the web. It's probably less controversial to compare it to libjxl. This is still multiples slower than AVIF, but I don't see JXL reaching that level of performance.

From what I understand, the performance gap is pretty different between architectures right now, so that's worth taking into consideration.

Jake.