While it's great to see that the PDF Association & Chrome are getting on board, I just hope it'll be enabled by default when testing it in dev builds this time 😅
On Wednesday, December 3, 2025 at 2:30:56 PM UTC Matthieu LAURENT wrote: > Amazing news! Great to see Chromium reconsidering JPEG XL given all it's > benefits. > Le vendredi 21 novembre 2025 à 20:02:51 UTC, Rick Byers a écrit : > >> 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/fc183bc9-7a8d-45ef-992d-4fe08d8845dcn%40chromium.org.
