JPEG XL is extremely bulky and complex. The reference decoder, implemented in multithreaded C++, is over 100,000 lines of code, making it a significant security risk. This concern was a major factor in Google’s decision to drop support for JPEG XL in Chrome. Even Mozilla, a company that allowed their Android browser to basically have no sandboxing for almost a decade, has expressed some serious security concerns with JPEG XL, stating that it would add a substantial amount of attack surface to Firefox.
Considering all the above, I think it would make sense to warn people about such an addition to Cromite.
So we don’t see support for JPEG-XL as either good or bad for the Web. We might find it necessary to support the format if usage becomes more widespread, but that will be a product decision
There was also this article, which I wonder if there has been anymore info on.
Our primary concern has long been the increased attack surface of the reference decoder (currently behind a pref in Firefox Nightly), which weighs in at more than 100,000 lines of multithreaded C++. To address this concern, the team at Google has agreed to apply their subject matter expertise to build a safe, performant, compact, and compatible JPEG-XL decoder in Rust, and integrate this decoder into Firefox.
It also sounds like Google did not think the juice was worth the squeeze.
During our experiment to support JPEG-XL in Chrome, we concluded that it did not provide substantial benefits over AVIF
This concern was a major factor in Google’s decision to drop support for JPEG XL in Chrome.
This is not really known, and mostly speculation. What Google argued when they removed it was mostly about “not enough interest in the ecosystem[1]”, which is, objectively, untrue, considering that the Chromium issue alone has a ton of comments from various engineers (from NVIDIA, Cloudinary, etc.) against the decision. It was also the most requested feature for Interop 2024[2] and now Interop 2025[3]. Furthermore, Apple products, including Safari, have JPEG XL support[4] using the reference implementation. But I digress.
Even Mozilla (…) has expressed some serious security concerns with JPEG XL, stating that it would add a substantial amount of attack surface to Firefox.
This is true[5]. However, they also said they would implement it given a proper Rust decoder[6] is implemented, one of which is now in the works[7] by the JPEG XL team and also seems to be at least partially intended for use in browsers[8].
I do agree that maybe a warning could be added, considering the increased attack surface. Or maybe a note/link to similar features that are/will be implemented in Cromite that can potentially increase attack surface.
Pardon my lack of knowledge, but how could this be used for exploits from the end-user’s side? Could it be exploited by a malicious site they visit, or does it require someone tampering with the browser itself?
I just don’t understand how a large chunk of code would be open to any more vunlerabilities than the browser is without it. And that’s a genuine question lol, I’m just not knowledgeable on the way malicious actors can actually exploit one’a system like this.
Yes; in this case probably via malicious websites loading well-crafted jpegs.
You’re right that browsers are more complex than a single codec, but code for all those codecs add up. Also, browsers like Chrome & Firefox are likely to have better security posture (for the code they author and build) than most other dependencies they might link into.
OP opines that the already vast browser codebase should avoid linking into potentially unsafe code (written in C/C++ as opposed to say Zig/Rust). This is now a widely accepted norm / rapidly emerging consensus in the industry.
Probably not in Chrome itself, because Google is for some reason really protective of their (inferior) formats Webp and Avif. But I’m sure projects like Cromite and Brave would be able to port it once it’s ready.