🤖 AI disclaimer: This article uses quite a few em dashes and emojis — but it was written by a human.
The saga of JXL adoption has been a surprisingly dramatic one. While Google was one of the main proponents of the format — it was created in a collaboration between Google Research and Cloudinary, with guidance from the broader JPEG committee — this didn’t imply that Google Chrome would become an early adopter. But now it looks like in 2026 all pieces of the puzzle might finally come together.
In past blog posts, I have made the case for JPEG XL several times already. In a nutshell: superior image compression performance while ensuring a high fidelity (in particular for HDR images), legacy-friendly reversible JPEG recompression, and a very complete feature set including progressive decoding make it the most promising modern image format.
Cloudinary supports JXL since November 2020 already. But of course server-side support alone is not sufficient to be able to actually use it on the Web…
The story of JXL browser support has been one with quite some ups and downs. Let me give a brief summary of the main turning points.
In a promising start, experimental Chrome support for JXL was implemented in May 2021, followed by Firefox in July 2021. This was very early — the standard itself wasn’t officially published until March 2022, though the “final draft” (FDIS) of the file format specification was approved by the committee in April 2021, so the format was effectively frozen already.
In both browsers it was disabled by default and a configuration flag had to be manually changed to actually get JXL support. The general expectation was that this was temporary, and once the standard would be published and the implementation would be mature and well-tested, the feature would be enabled by default.
The libjxl implementation improved, bugs were squashed, the standard was finalized. Things were looking good.
But then, exactly on Halloween 2022, a controversial announcement was made by the Chrome developers, saying they were planning to remove JXL support, citing “not enough interest from the entire ecosystem.”
Shortly afterwards, Mozilla announced in January 2023 that their position on JXL was “neutral,” i.e., they wouldn’t add support for it unless the other browsers would do that.
In February 2023, all JXL code was removed from Chrome.
At this point, it looked like the story was basically over for JXL support in browsers, and thus probably for JXL in general as a widely-supported image format. After all, browsers are such a critical part of so many workflows and use cases, that no image format can be considered ubiquitous and interoperable if it doesn’t have universal browser support.
Considering the market share of Chrome and Chromium-derived browsers such as Edge, a veto from Chrome essentially is a death sentence for any web feature.
In a plot twist, in June 2023 Apple announced that they were planning to add JXL support to their entire ecosystem, including iOS, macOS, and Safari. In September 2023, JXL support was rolled out in Safari.
The following months we saw a rapid increase in the number of image requests coming from browsers with JXL support in Cloudinary’s overall traffic.
The proportion of web clients with JXL support jumped from only a fraction of a percent beginning of September 2023 to a peak of around 25% around Christmas. It slowly grew to around 28% and has been fluctuating around that ratio for about two years now, with peaks above 30%.
(As a side note: This 28% browser support number is higher than the 12% reported by “Can I Use” or as cited in Arjen Karel’s excellent recent blog post about JPEG XL and Core Web Vitals. Likely this is caused by North America and Europe/U.K. being overrepresented in Cloudinary’s traffic — together over 75% of our traffic — which bumps up the proportion of iPhones in our logs.)
(As another side note: In case you’re wondering where those peaks are coming from: on desktop, about 10% of browsers support JXL, while on mobile, it is about 40%. On working days about 60% of our traffic is from mobile devices, while on weekends and holidays it is around 75%. The plot shows the numbers for Tuesdays, so it mostly shows “working day traffic,” except around holidays. In particular around the end of the year, this causes spikes in the plot.)
In the same period, the number of JXL images Cloudinary delivered per day also increased significantly, from practically none (around 50,000/day) in the summer of 2023 to around one billion per day at the time of writing. The spikes in overall amount of traffic are always very noticeable around Black Friday.
Of course Safari’s support for JXL brought back hope for getting JXL support back into Chrome and Firefox. Alas, for both Interop 2024 and Interop 2025, making JXL an interoperable web format was proposed, but the proposals were not selected by the browser devs.
So it looked like JXL would become a Safari-only image format, similar to J2K and HEIC.
JPEG XL was conceived with a diverse range of applications in mind from the start, as outlined in its use cases and requirements document. While web delivery is a key area, it is not the sole focus. Unlike formats such as WebP or AVIF, which were created specifically to optimize web bandwidth, JXL’s intended scope is much broader.
Introduced in June 2023, version 1.7 of Adobe’s Digital Negative format, DNG, makes it possible to use JXL as a payload codec for RAW sensor data. In particular, both lossless and lossy JXL can be used. With legacy JPEG, lossy compression wouldn’t make sense for RAW files, since the precision would be too low to allow for adjustments in post-production. But JXL effectively has no precision limits and can do very high-fidelity lossy compression, which is a very attractive option for photography workflows.
Samsung introduced JXL as a payload in Expert RAW in the Galaxy S24 in January 2024, while Apple added JXL as a payload in ProRAW in the iPhone 16 Pro in September 2024.
More recently, hardware implementations of a JXL encoder have become available in November 2025, based on a design by Shikino High-Tech in collaboration with the JPEG committee. This will likely lead to consumer and professional camera vendors announcing new products that support JXL as a capture format in the near future.
At PDF Days Europe 2025, Peter Wyatt, CTO of the PDF Association, announced that JPEG XL was selected as the preferred solution for HDR images embedded in PDF. He also mentioned other features of JXL that could be useful in PDF: wide gamut, ultra-high resolution, up to 32 bits per channel and up to 4099 channels.
It’s worth pointing out that JXL was designed with printing use cases in mind, including support for CMYK and spot colors. In that respect, there’s an obvious difference between JXL and image formats derived from video codecs, such as WebP, HEIC, and AVIF.
In healthcare imaging (think MRIs, CTs, etc.), JXL can be used as a payload codec in DICOM since the 2024d release. The defined JPEG XL transfer syntaxes include lossless, lossy, and JPEG recompression variants. According to pathologists at Mayo Clinic, for whole slide imaging (WSI) the file size reduction that can be achieved using JXL is 50-60%. The WSI archives at Mayo alone are growing by about 4000 terabytes per year, so such savings represent a substantial cost reduction.
In September 2025, Philips announced the first digital pathology scanner with native DICOM JXL output. Recently AWS HealthImaging also added JXL support.
The Geospatial Data Abstraction Library (GDAL), released by the Open Source Geospatial Foundation (OSGeo), is a translator library for raster and vector geospatial data formats. It’s part of the backbone of many GIS applications, from Google Earth to OpenStreetMap. In November 2022, GDAL 3.6 was released, which added support for JXL and JXL payloads in GeoTIFF.
Also in other scientific applications JXL brings advantages, in particular for lossless or near-lossless compression of high bitdepth images, and for multispectral images for which Spectral JPEG XL was recently introduced.
All major image authoring tools support JXL as an import and export format: Adobe Photoshop and Lightroom, Affinity, Acorn, ACDSee Photo Studio, paint.net, GIMP, Krita, Darktable, and so on.
Many of them added support already back in 2022.
Linux distributions were the first to add JPEG XL support at the OS-level. The integration of libjxl in both GTK (GNOME) and Qt (KDE) allowed some distributions like KaOS and OpenMandriva to add out-of-the-box JXL support as early as 2021. Popular distributions including Ubuntu now have JXL support included in default installs.
As mentioned before, Apple rolled out full support for JXL in September 2023 — not just in Safari but also at the OS level.
In March 2025, Microsoft added OS-level support for JXL in Windows 11.
For a year or two, there was pretty much no news from Chrome and Firefox, and it looked like Safari would remain the only browser with JXL support. But in September 2024, something started changing. Bobby Holley, the CTO of Firefox, stated that “Firefox will consider a Rust implementation of JPEG XL. This announcement triggered the development of a Rust-based JXL implementation jxl-rs.
In November 2025, Rick Byers, Area Tech Lead on Chrome, announced:
“Since JPEG XL was last evaluated, Safari has shipped support and Firefox has updated their position. We also continue to see developer signals for this in bug upvotes, Interop proposals, and survey data. There was also a recent announcement 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.”
This was obviously a big turning point. Within weeks, the jxl-rs decoder was integrated in both Chrome and Firefox. Also, JPEG XL was selected as an “investigation effort” for Interop 2026.
Right now, chances are that you’re reading this on a browser that can decode JXL images. In Safari or iOS, JXL is already supported for a while now. On Chrome, it is available behind a flag since M145, which was released on February 10th, 2026. The relevant flag is:
chrome://flags/#enable-jxl-image-format
There’s a test page on the JPEG XL community website to check if your browser supports JXL.
While experimental JXL support behind a flag has been in Chrome before, it looks like this time it will actually be shipped. At the time of writing, no date is known yet for having JXL enabled by default, but it seems likely that this will happen in 2026.
It’s interesting to compare the timing for the three modern image formats recently introduced. In case of both WebP and AVIF, generally speaking the format could be used on the Web well before it could be used in most other contexts. For JPEG XL, it’s more or less the other way around:
| WebP | AVIF | JPEG XL | |
| Standardization | single company (Google) | industry consortium (AOMedia) | standards organization (ISO/IEC) |
| Specification finalized | Aug 2012 | Feb 2019 | Mar 2022 |
| Chrome | –1 ½ year Feb 2011 | 1 ½ year Aug 2020 | 4-5 years 2026 (?) |
| Edge | 6 years Nov 2018 | 5 years Jan 2024 | 4-5 years 2026 (?) |
| Firefox | 7 years Jan 2019 | 2 ½ year Oct 2021 | 4-5 years 2026 (?) |
| Safari / iOS | 10 years Sept 2022 | 3 ½ year Oct 2022 | 1 ½ year Sept 2023 |
| Adobe Photoshop | 10 years Feb 2022 | 6 years June 2025 | 3 years June 2025 |
| Adobe Lightroom | 15 years Feb 2026 | 4 ½ year Oct 2023 | ½ year Oct 2022 |
| Darktable | 11 years Dec 2022 | 1 ½ year Aug 2020 | ½ year Dec 2022 |
| GIMP | 5 years Aug 2017 | 1 ½ year Oct 2020 | ¼ year June 2022 |
| Krita | 9 years Aug 2022 | 2 ½ year Dec 2021 | ½ year Aug 2022 |
| Windows | 11 years May 2023 | 3 ½ year Sept 2022 | 3 years Mar 2025 |
| MacOS | 8 years Sept 2020 | 3 ½ year Sept 2022 | 1 ½ year Sept 2023 |
WebP, created by Google, was supported in Chrome even before the format was finalized — lossless mode, alpha transparency and animation didn’t exist yet in the early lossy-only version of WebP that Chrome initially supported. While Google was actively promoting the use of WebP on websites, for example by making sure that a Lighthouse Performance Audit would list any images that are not being served in WebP, broader ecosystem adoption outside web browsers (or even outside Chrome) was slow. This is perhaps not surprising: the format was not designed to have a broad scope in terms of use cases, and even though it is open source and royalty-free, it is a single-vendor proprietary format “owned” by Google, not by an international standards organization.
However this lack of broader support for WebP has caused much user frustration, to the extent that it became a meme. Saving an image from a website and then using it in software other than a browser is something that works effortlessly with JPEG or PNG, but with WebP, it often still doesn’t work, e.g., even at the time of writing, inserting a WebP in a Google Docs results in “unsupported image type.”
While any new format inevitably causes friction, for JXL the order of adoption is pretty much the opposite of how it went with WebP. After being introduced in Chrome and being promoted as the format of choice for web images, it took a decade for “interest from the entire ecosystem” to emerge. In contrast, JXL is already supported in all image editors and viewers well before it can be used in Chrome. From the point of view of interoperability — which is, after all, the main point of standardization — this might be a good thing, actually.
Maybe it’s not surprising that it is hard to get yet another image format supported, when JPEG and PNG are considered “good enough” for most workflows. Both born in the 1990s, they have the undeniable advantage that by now they “just work anywhere”. For any new format, it’s hard to overcome inertia and inevitable initial interoperability issues, which make it attractive to just stick to the old formats.
Yet, as discussed above, JXL adoption in the broad ecosystem — photography, digital art, medical and scientific imaging, and so on — actually was relatively swift. Adoption in browsers, on the other hand, was a roller coaster ride. But it looks like 2026 will be the year in which JXL is fully on track to become a worthy successor to good old JPEG and PNG. Knocking on wood, this dramatic saga will be concluding with a happy ending.
