This is great news! In terms of commitments to long-term maintenance:
- Cloudinary has been involved in the JPEG XL project from the very beginning (2018), and will continue to be involved in its various aspects, from standardization to implementation. We are currently already delivering about 1 billion JPEG XL images per day and it is likely that this number will increase by an order of magnitude once Chrome ships JPEG XL support. Obviously it is a critical part of our core business to make sure that the client side can correctly and efficiently decode the images we produce on the server side. - The JPEG committee (ISO/IEC JTC 1 / SC 29 / WG 1) has a long-term commitment to maintaining its standards, not just in terms of maintaining the specifications themselves, but also in verifying conformance of implementations and participating in the maintenance of implementations. Decades-old standards like the original JPEG or the JPEG 2000 are still to this day being actively maintained by the JPEG committee, so I think it's safe to say that this organization has a proven track record of commitment to long-term maintenance. More concretely, I think the jxl-rs implementation is an excellent candidate for integration into Chromium and other web browsers. Within the JPEG committee, I am planning to take steps towards giving jxl-rs the status of alternative reference implementation (in addition to libjxl, which is currently the only reference implementation). This will help in ensuring long-term maintenance of this implementation and in making sure that there are no discrepancies between the specification, libjxl, and jxl-rs. Best, -Jon. On Friday, November 21, 2025 at 9:02:51 PM UTC+1 Rick Byers wrote: > 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/98ba9cb6-0161-41d0-bc7c-2c685ec84cd7n%40chromium.org.
