Hi everyone, Since JPEG XL was last evaluated, Safari has shipped support <https://developer.apple.com/documentation/safari-release-notes/safari-17-release-notes> and Firefox has updated their position <https://github.com/mozilla/standards-positions/pull/1064>. We also continue to see developer signals for this in bug upvotes <https://issues.chromium.org/issues/40270698>, Interop proposals <https://github.com/web-platform-tests/interop/issues?q=%22jpeg%20xl%22%20sort%3Areactions-%2B1-desc>, and survey data <https://github.com/web-platform-tests/interop/issues/994#issuecomment-3416932563>. There was also a recent announcement <https://www.youtube.com/watch?v=DjUPSfirHek&t=2284s> that JPEG XL will be added to PDF.
Given these positive signals, we would welcome contributions to integrate a performant and memory-safe JPEG XL decoder in Chromium. In order to enable it by default in Chromium we would need a commitment to long-term maintenance. With those and our usual launch criteria met, we would ship it in Chrome. Rick (on behalf of Chrome ATLs) On Thu, Sep 11, 2025 at 4:04 PM Ad <[email protected]> wrote: > Any updates on this? Or changes in stances? > > On Thursday, September 19, 2024 at 3:44:05 PM UTC+1 ― wrote: > >> Many apologies for messaging on a seemingly dormant thread but I feel >> it's worth me pointing out that alongside the new push for JPEG-XL support >> in the latest iOS/iPhone releases, there are also signs that Microsoft >> might be looking at adding support into their products, and another >> interesting sign would be this - >> https://github.com/mozilla/standards-positions/pull/1064 perhaps it's >> worth revisiting now that the 'no signal' classification no longer applies >> in multiple cases here? Things have definitely changed since jxl first came >> up for Chromium/Chrome >> >> On Monday 26 June 2023 at 02:37:01 UTC+1 Andy Foxman wrote: >> >>> >>> Hello, >>> so when will be the JPEG XL issue reopened? >>> Request for reopen here: >>> https://bugs.chromium.org/p/chromium/issues/detail?id=1451807 >>> >>> Since Safari added support, I think it deserves new discussion. >>> Original issue: >>> https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 >>> >>> Thanks. >>> --- >>> >>> Dne úterý 20. června 2023 v 17:51:12 UTC+2 uživatel Simon Pieters napsal: >>> >>> On Tue, Jun 20, 2023 at 5:35 PM ― <[email protected]> wrote: >>> >>> Worth Noting: On top of Apple support, Mozilla is now looking into Jxl >>> integration again. From neutral to positive. >>> >>> >>> This is incorrect. https://mozilla.github.io/standards-positions/#jpegxl >>> is still neutral. >>> >>> cheers, >>> >>> >>> Chrome will need feature parity even if chromium doesn’t have it. >>> >>> >>> On Wed, 7 Jun 2023 at 15:32, ― <[email protected]> wrote: >>> >>> >>> *Update:* >>> >>> >>> >>> >>> Firefox: >>> In testing builds. (Neutral - depending on support from community.) >>> >>> Safari (& iOS): >>> Currently undergoing testing & implementation as of latest iOS/macOS dev >>> previews. (Positive.) >>> >>> Web Developers & Community: >>> (Very Positive Support) >>> >>> >>> >>> >>> - - - - - - - - - >>> >>> >>> >>> Support added by a lot of apps with more showing support should Google >>> Chrome (and ChromeOS) support the format by default & Android Community has >>> requested support for it too alongside some in the Windows Insider >>> Community. >>> >>> This would also be welcomed by the Digital art community, the medical >>> community for scans, and have benefits for streamlining online image >>> storage with a healthy balance of quality vs size taken up. >>> >>> Fwiw, I also support JPG-XL adoption to have healthy competition with >>> AVIF/WebP and I'm neither a developer nor a representative of any company. >>> Just a tech user enthusiast, I've also met countless of people supporting >>> the view. >>> >>> 1,000 in Chromium bug tracker over 500 in Mozilla's Trending Feature >>> Requests, then you have those on reddit and Phoronix wishing to raise their >>> support for the matter. >>> >>> But let's not beat around the bush here, support from Chromium/Chrome >>> can make or break something like this, regardless of whether or not it is >>> logically right to do so, Google knows that fact all too well by now. >>> >>> >>> >>> On Tue, 6 Jun 2023, 11:50 Albert Andaluz González, <[email protected]> >>> wrote: >>> >>> The Chrome status page (https://chromestatus.com/ >>> feature/5188299478007808) should now mention that Webkit supports >>> jpeg-xl, at least for Safari 17 beta onwards. >>> https://developer.apple.com/documentation/safari-release- >>> notes/safari-17-release-notes >>> See also relevant WWDC2023 session (Explore media formats for the web) : >>> https://developer.apple.com/videos/play/wwdc2023/10122/ (available 8th >>> June) >>> >>> >>> El sábado, 17 de diciembre de 2022 a las 22:55:47 UTC+1, ⸻ “How Things >>> Work” escribió: >>> >>> >>> 800 Users with hundreds of comments seem to be distrustful after the >>> previous ones, can't that be considered or taken into account for the >>> request? There are many developers from quite a few big name companies such >>> as Facebook/Meta & Intel too. Also use cases highlighted, such as Medical >>> Imaging. Regardless of how this is spun, it would seem that this format >>> would see widespread adoption & implementation across multiple industries >>> if it were permitted to be enabled by default. >>> >>> https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 - One >>> again leaving this link for reference, please reconsider, a lot of work >>> would go to waste when we could all just compromise and improve on the >>> format in the future >>> On Saturday 17 December 2022 at 03:53:10 UTC Yaowu Xu wrote: >>> >>> Thanks for the feedback regarding speed tests, please see updated >>> decoding timing info on latest builds on more platforms: >>> https://storage.googleapis.com/avif-comparison/decode-timing.html >>> >>> >>> On Tuesday, December 13, 2022 at 8:19:40 AM UTC-8 Markus K. wrote: >>> >>> I find it very concerning that this decision is has evidently been based >>> on this bogous data: https://storage.googleapis. >>> com/avif-comparison/index.html >>> >>> 1. The speed comparison is based on a buggy and outdated JPEG >>> XL implementation. >>> 2. The filesize comparison is based on a metric that JPEG XL was not >>> tuned for. >>> >>> On top of that we seem to have completely misjudged ecosystem and >>> industry demand for JPEG XL . >>> And there seems to have been no consideration for certain features, >>> which I don't want to reiterate here, that AVIF just doesn't support. I >>> think there is a place for JPEG XL alongside AVIF. >>> >>> I would suggest to halt the removal of the JPEG XL experiment in >>> Chromium until this is addressed to prevent further harm based on bad >>> science. >>> >>> On Sunday, December 4, 2022 at 7:00:22 PM UTC+1 ⸻ “How Things Work” >>> wrote: >>> >>> https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 - Also >>> requesting a reconsideration of.JXL as a format due to cross-industry >>> interest from companies & consumers alike. Also on the grounds of it being >>> hindered by being buried behind an obscure flag within beta builds :/ >>> >>> Could just revert the removal till the M111 or 112 builds and see how >>> things stand then, would give time for debate *& a more fairer test of >>> market sentiment for this open JPEG standard*. >>> >>> On Friday 2 December 2022 at 23:05:15 UTC Tomáš Poledný wrote: >>> >>> Now you should run your tests again with this: >>> https://chromium-review.googlesource.com/c/chromium/src/+/4031214 >>> >>> Dne pátek 2. prosince 2022 v 22:20:19 UTC+1 uživatel Jarek Duda napsal: >>> >>> If there are objectivity concerns, maybe there available tests of >>> independent sources? >>> For example Phoronix often uses libjxl in benchmarks - at least for >>> speed getting very different numbers: https://www.phoronix.com/ >>> review/aocc4-gcc-clang/3 - maybe there are available other independent >>> tests? >>> >>> [image: obraz.png] >>> >>> On Friday, December 2, 2022 at 6:57:35 PM UTC+1 Yaowu Xu wrote: >>> >>> Following Jim’s previous note, here is a link to tests >>> <https://storage.googleapis.com/avif-comparison/index.html> AVIF >>> engineers ran comparing AVIF to JPEG, WebP and JPEG-XL. The tests provide >>> all the necessary code, test sets and parameters to reproduce the test >>> results. Developers are welcome to ask questions and submit feedback to >>> [email protected]. >>> >>> >>> Apologies for the delay in providing this information. We wanted to be >>> sure that everyone would be able to duplicate and verify these results for >>> themselves before posting. >>> >>> >>> On Friday, November 11, 2022 at 7:58:28 AM UTC-8 Jim Bankoski wrote: >>> >>> Helping the web to evolve is challenging, and it requires us to make >>> difficult choices. We've also heard from our browser and device partners >>> that every additional format adds costs (monetary or hardware), and we’re >>> very much aware that these costs are borne by those outside of Google. When >>> we evaluate new media formats, the first question we have to ask is whether >>> the format works best for the web. With respect to new image formats such >>> as JPEG XL, that means we have to look comprehensively at many factors: >>> compression performance across a broad range of images; is the decoder >>> fast, allowing for speedy rendering of smaller images; are there fast >>> encoders, ideally with hardware support, that keep encoding costs >>> reasonable for large users; can we optimize existing formats to meet any >>> new use-cases, rather than adding support for an additional format; do >>> other browsers and OSes support it? >>> >>> After weighing the data, we’ve decided to stop Chrome’s JPEG XL >>> experiment and remove the code associated with the experiment. We'll work >>> to publish data in the next couple of weeks. >>> >>> For those who want to use JPEG XL in Chrome, we believe a WebAssembly >>> (Wasm) implementation is both performant and a great path forward. >>> >>> >>> Jim >>> >>> >>> On Monday, October 31, 2022 at 11:01:44 AM UTC-7 [email protected] >>> wrote: >>> >>> Apologies for bringing back an old thread, but I thought it was >>> important to bring this up here. >>> >>> I was surprised to read that Google are abandoning their efforts to >>> implement JPEG-XL: https://bugs.chromium.org/p/chromium/ >>> issues/detail?id=1178058#c84 >>> >>> As I understood it, JPEG-XL brought significant improvements over >>> existing image formats, and had a lot of interest in the technology world. >>> However the reasons cited were apparently lack of benefits and lack of >>> interest. >>> >>> I for one was interested in this format and the improvements it would >>> bring, and it seems many others are disappointed too. Can Google explain >>> how they came to this conclusion? How are they evaluating the benefits and >>> interest? Even this intent to prototype lists many of the purported >>> benefits and the extent of the interest, which makes this reversal >>> particularly hard to understand. >>> >>> >>> >>> >>> On Tue, 30 Mar 2021 at 20:20, 'Moritz Firsching' via blink-dev < >>> [email protected]> wrote: >>> >>> Contact emails >>> >>> >>> *[email protected], [email protected], [email protected], >>> [email protected]*Explainer >>> >>> >>> *https://jpeg.org/jpegxl/ >>> <https://jpeg.org/jpegxl/>http://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf >>> <http://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf>*Specification >>> >>> >>> *https://arxiv.org/abs/1908.03565 <https://arxiv.org/abs/1908.03565>* >>> Summary >>> >>> >>> >>> >>> *JPEG XL is a new royalty-free image codec targeting the image quality >>> as found on the web, providing about ~60% size savings when compared to >>> original JPEG at the same perceptual quality, while supporting modern >>> features like HDR, animation, alpha channel, lossless JPEG recompression, >>> lossless and progressive modes. It is based on Google's PIK and >>> Cloudinary's FUIF, and is in the final steps of standardization with >>> ISO.This feature enables image/jxl decoding support in the blink >>> renderer.*Blink >>> component >>> >>> >>> *Blink>Image >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EImage>* >>> Motivation >>> >>> >>> >>> >>> *The main motivations for supporting JPEG XL in Chrome are: - The >>> improvement in image quality vs image size, about 60% file size savings for >>> the same visual quality (lossy compression of larger originals) when >>> compared to JPEG at the qualities found on the web.- Improved visual >>> latency by both smaller download sizes and supporting progressive decoding >>> modes. - Support for HDR, animation and progressive all together in the >>> same image codec. - Support for lossless-recompressed JPEGs - Ecosystem >>> interest in JPEG XL: Several Google teams evaluated using JPEG XL for >>> storing and delivering images, as well as outside of Google: including CDNs >>> interest in storing lossless-recompressed JPEGs as JPEG XL and converting >>> to JPEG on request is the browser doesn't support JXL. Facebook is >>> exploring to use JPEG XL.*Initial public proposal >>> >>> >>> *Support decoding image/jxl behind a feature flag which is turned off by >>> default on all platforms. *Search tags >>> >>> >>> *jxl <https://www.chromestatus.com/features#tags:jxl>*TAG review >>> >>> >>> *Not applicable for image decoders*TAG review status >>> >>> >>> *Not applicable*Risks >>> >>> Interoperability and Compatibility >>> >>> >>> >>> >>> >>> >>> *JPEG XL is in the final stage ISO standardization. Firefox has an open >>> bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1539075 >>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1539075>Edge/Safari - no >>> signals yetGecko: No signalWebKit: No signalWeb developers: high >>> interest/many stars in the tracking bug, and there was a separate external >>> crbug requesting the feature. A lot of interest on encode.su >>> <http://encode.su>, r/jpegxl, <https://reddit.com/r/jpegxl/> discord >>> <https://discord.com/channels/794206087879852103>, ...*Is this feature >>> fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> >>> ? >>> >>> >>> *No, but planning to have complete tests before shipping. *Tracking bug >>> >>> >>> *https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 >>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1178058>*Launch >>> bug >>> >>> >>> *https://bugs.chromium.org/p/chromium/issues/detail?id=1178040 >>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1178040>*Link to >>> entry on the Chrome Platform Status >>> >>> https://www.chromestatus.com/feature/5188299478007808 >>> >>> This intent message was generated by Chrome Platform Status >>> <https://www.chromestatus.com/>. >>> >>> -- >>> >>> 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 [email protected]. >>> >>> To view this discussion on the web visit https://groups.google.com/a/ >>> chromium.org/d/msgid/blink-dev/CAMM7wxZEBJ8uf5OB% >>> 3DR1j2J6w5OF8OT1o%2B%2BN4t8G_brOo-Zgh_w%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMM7wxZEBJ8uf5OB%3DR1j2J6w5OF8OT1o%2B%2BN4t8G_brOo-Zgh_w%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >>> Sent from Gmail Mobile >>> >>> -- >>> 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 [email protected]. >>> >>> >>> To view this discussion on the web visit https://groups.google.com/a/ >>> chromium.org/d/msgid/blink-dev/CACf2j71RrPYrWOHEXFvkcL6% >>> 3Dx9tFfDK_id2C40Mo3HHQcxRj9w%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACf2j71RrPYrWOHEXFvkcL6%3Dx9tFfDK_id2C40Mo3HHQcxRj9w%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> >>> >>> -- >>> Simon Pieters >>> https://www.mozilla.com/ >>> >>> -- > 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 [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d8b6b280-5630-4cd7-93ba-0f70487f2ccen%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d8b6b280-5630-4cd7-93ba-0f70487f2ccen%40chromium.org?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-e3B25xkAZvAtBwXke-h2uPMqgpHQXVKxdh9pau_xjuQ%40mail.gmail.com.
