Back to all features
Open for signals
Image formats
JPEG XL
The JPEG XL image format is a raster graphics file format that supports animation, alpha transparency, and lossy as well as lossless compression.
Community use cases (33)
Community signal summary
Developers and framework engineers, including contributors from Vercel working on Next.js, strongly advocate for native
JPEG XLsupport to accelerate dynamic image pipelines, reduce server encoding overhead, and deliver superior compression [16][28]. Key use cases include high-dynamic-range (HDR) web delivery with wide color gamuts [18], zero-loss medical imaging under the DICOM standard without heavy WebAssembly shims [20], and high-resolution asset management in Wagtail CMS [28][33].In the meantime, developers must either serve heavier legacy formats with substantial bandwidth penalties or maintain complex WebAssembly polyfills that introduce significant client-side decode latency and memory overhead [20][25]. Standardizing JPEG XL across major browser engines would eliminate these polyfills, reduce compute costs, and elevate web visual fidelity natively [16][18][20].
Generated by AI from community comments and may contain inaccuracies. Read the comments below for full developer context.
This summary covers all 33 comments, is up to date, and was last updated on September 5, 2026.
Why is it even a question? This is the best possible data format for lossless compressed images.
@PELock can you provide a bit more detail on your use-case for lossless images on the web?
I used to use lossless formats for images with lots of solid colour, but that was really only because lossy formats like JPEG & WebP made such a horrible mess of it, whereas AVIF is pretty good at it.
With that example, the lossless WebP is 275kb, JXL is 220kb (nice!), but the AVIF version I have on the page seems pretty good for high-density viewing, and it's 12kb.
What I want to do with this feature
What I'm having to do in the meantime
<picture>element. Generating two previews makes preview generation slower than it should be. That's okay though for a transitional period. What's unfortunate is that the majority of users can't profit from the smaller, yet better JXLs due to the limited browser support. That means more traffic and less quality for everyone.(I don't see AVIF as a worthwhile alternative due to its tendency to smooth details away on the one hand and due to slower encoding speed on the other hand, which would be a problem when many previews need to be generated quickly on shared webhosting where my software is used. AVIF also doesn't support real progressive encoding, which traditional JPEGs do. Finally, I'd like to avoid transitioning between image formats repeatedly.)
There are plenty of reasons to choose lossless formats. I found the following comparisons, and they reflect what I’ve seen in my own tests.
https://arxiv.org/pdf/2108.02557
https://github.com/WangXuan95/Image-Compression-Benchmark
https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/
https://siipo.la/blog/whats-the-best-lossless-image-format-comparing-png-webp-avif-and-jpeg-xl/
(When I was developing WebP lossless in 2011, I noticed that it did worse than BMF for photographs. Back then I concluded that BMF was ~10 % more dense due to modeling somewhat hidden correlations originating from demosaicing algorithm interpolates. If I subsampled the benchmark images for example 4x4 before testing, then its performance edge disappeared. I considered that most lossless images in the internet would not be coming straight from the camera, but be some kind of renderings and then I wasn't so worried about the demosaicking decorrelations not modeled so well.)
Some use cases for lossless images on the web platform include:
Then there are of course also use cases where images are used in an authoring flow and the purpose is not just to view the image in the browser, but also to edit them. In many of these cases the best practice is to use lossy previews, but this is not necessarily always a usable approach. For example, consider browser-based image editors.
In particular, considering that the web platform is in some circumstances basically an OS platform (e.g. Chromebooks, web apps, etc), it can be argued that any use case for lossless images is also a use case for lossless images on the web platform.
I'm not sure why jakearchibald talks about lossless compression, when in fact JPEG XL will be used primarily as a lossy codec... Jake, what is your point? Why not focus on the primary function and be glad it offers lossless compression as well?
@jyrkialakuijala, where else has JPEG XL already been adopted?
What I want to do with this feature
As a web developer, I need to deliver the best looking/smallest size for items like logos (that aren't in SVG) & screen shots. The extra savings from JXL would be significant, as we often have hundreds of those per site.
What I'm having to do in the meantime
We currently use lossless webp for these items, as it’s the best option outside of JXL.
@PELock please be mindful of https://github.com/web-platform-dx/developer-signals/blob/main/CODE_OF_CONDUCT.md, in particular that this is not a forum for technical debate.
So why nitpick and make the main point of discussion on lossless compression when the primary use of it would be lossy?
Samsung and Apple have started using JPEG-XL on their phones. It's necessary for HDR and other features. It's a much more useful format than JPEG XR and AVIF. Firefox Nightly uses the jxl-rs library (the long-developed Rust library). JPEG-XL is officially designated for PDF (for HDR). Google has also decided to bring JPEG-XL to Chromium (again). Starting with Fedora 42, all wallpapers are JPEG-XL. In short, JPEG-XL wins, and AVIF and WebP lose.
@PELock you wrote
Maybe you meant lossy?
@PELock
I was asking a clarifying question based on your post
We have a template for providing feedback, which is included in the OP. You didn't use it, so I was asking you to expand on your point. It wasn't nitpicking at all, I was simply asking for more detail. The only reason I mentioned lossless compression is because you suggested it was a major use-case for you.
@jonsneyers and @jyrkialakuijala: I appreciate the use-cases you provided, but please don't speak for others. The goal of this repo is to gather use-cases from individual developers.
Hey folks, the goal of this repo is to gather use-cases from individual developers. A template is provided in the OP to make this easier:
This isn't a venue for self-promotion, technical debate, or throwing insults. Posts which do this will be hidden.
What I want to do with this feature
LSB encoding, there cannot be any data loss in RGBA
I want JPEG XL because it provides loseless compression and its helpful for my Steganography Online Codec, it's widly used by journalists and in hostile environments (war) to transfer secret messages within images, the problem is its based on LSB coding and I cannot use error correction to store the secret and encrypted content in losssy, output images like JPG because the LSB coding would be damaged & lost. Right now I can only use PNG as the output format file because I can extract the data from LSB bits without any data loss. JPEG XL would provide me with an additional format and output images would take even less space,
Image optimization plugin for Yii2 framework
I would love to add JPEG XL to my auto-image optimization plugin for Yii2 PHP framework yii2-imgopt, currently I can only output WebP and AVIF and AVIF in 90% cases is not even installed within PHP GD library, so the only working option is WebP. JPEG XL would provide a vital alternative for WebP and AVIF with even more options like lossless compression and smaller sizes. Smaller sizes = faster websites.
What I'm having to do in the meantime
I need to use other lossless formats and PNG is the only sensible option right now.
What I want to do with this feature
I work on a web framework, Next.js, that uses on-demand image optimization, so encoding speed is important on cache miss.
By default, we transform all images to WebP which is fast to encode (typically a source image is JPEG or PNG). We also allow transforming to AVIF via opt in config, however this is considerably slower to encode. So much so that we have not enabled AVIF by default.
We think that JPEG XL might be a nice middle ground to get some of the features of AVIF without the slow encoding speed (although it sounds like decoding speed might be slower too).
What I'm having to do in the meantime
Stick with WebP or AVIF depending on the use case.
What I want to do with this feature
In my free time, I work on a small website focused on sharing user-generated content. Users are able to attach screenshots, banner images and icons to their works. As the website is small and paid for out-of-pocket, I want JPEG XL in order to reduce my computation cost for image compression, networking and storage costs for serving and storing the images.
What I'm having to do in the meantime
Currently I use WebP which has a significantly lower visual quality at the file sizes I'm targetting, especially considering the content of images (pixel art). Testing with AVIF resulted in extremely long encode times on the hardware I use which made it infeasible for a good user experience.
What I want to do with this feature
I want to use JPEG XL on the web to deliver high-dynamic-range (HDR) images and to store and serve high-quality images in a truly lossless way.
JPEG XL is especially important for workflows that require wide color gamuts, higher bit depths (10-bit / 12-bit), and accurate tone reproduction, which are not well supported by traditional web image formats.
For content creators, photographers, and developers working with HDR displays and modern color pipelines, JPEG XL would significantly improve both image quality and efficiency on the web.
What I'm having to do in the meantime
In the meantime, I have to rely on formats like PNG, JPEG, or WebP, none of which fully meet these needs:
As a result, I either have to downgrade HDR images to SDR, accept unnecessary quality loss, or store separate master files in other formats for archiving. This increases complexity, storage requirements, and processing time, and prevents delivering the best possible image quality to users with capable displays.
Native JPEG XL support in all browsers would remove these compromises and enable modern, future-proof image workflows on the web.
What I want to do with this feature
I work developing a web-based markdown editor to make TTRPG books(https://homebrewery.naturalcrit.com/), meant for sharing and printing, some of which can get to well over 200 pages, therefore asset size is very important, support in this feature should reduce the overall size of our users documents noticeably.
What I'm having to do in the meantime
All users are forced to use other image formats, which are bigger in size.
What I want to do with this feature
Serve medical data compressed in JPEG XL without conversion loss or shipping a slow wasm shim.
JPEG XL is now an official part of the DICOM standard: https://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_8.2.15.html
What I'm having to do in the meantime
We have to either down-convert to JPEG, which introduces artifacts and may obscure findings, or PNG which is slow to encode and creates much larger payloads. WebP is not an option, as that is 8bit only.
The gentle push for JPEG XL on the web is no longer just a pure web developer request; it is a need arising from broader cross-industry interoperability. When global digital standards, like DICOM, PDF, PDF/A, EPUB, DNG, TWAIN, IIIF, and others converge on JPEG XL, web's lack of native support creates a bottleneck for data exchange.
The Interoperability Gap
The following sectors have already integrated JPEG XL, leaving the web stack as the missing link in their workflows:
Medical Imaging (DICOM): In digital pathology, where preserving fine detail is critical, the medical community is calling for JPEG XL to enable high-fidelity, browser-based telemedicine.
Professional Photography: The industry’s heavy hitters -- Adobe (DNG 1.7), Apple (ProRAW), and Samsung (ExpertRAW) -- have transitioned to JPEG XL. For modern flagship smartphones, JPEG XL based formats are now the standard for high-performance raw photography.
Digital Documents (PDF & EPUB): Both the PDF and EPUB standards have adopted JPEG XL to ensure the next generation of digital books and documents offers high-fidelity imagery at low bandwidth.
Geospatial & Archival (GDAL, COG, TIFF): Mapping and archival standards use JPEG XL to handle massive datasets and lossless or high-quality preservation efficiently.
The Cost of Non-Adoption
Without native web support, these industries are forced into lossy conversions when moving content for example between HTML, PDF, and EPUB. This not only degrades image quality but also creates a burden of manual verification to ensure that critical data -- whether a medical scan, cultural heritage scan, or a legal document -- remains intact during the transition.
What I want to do with this feature
I want to use it in desktop Electron apps. Electron uses Chrome as its baseline, so the addition of this functionality directly flows forward. In particular, some Electron apps like Obsidian (https://obsidian.md) involve user-created content, and those could use JXL if it was available. My personal vault contains a lot of images, so JXL would provide decent space-savings.
What I'm having to do in the meantime
Mostly I'm just using PNG. I don't want to convert my Obsidian vault's images to lossy WebP because I'd rather only do one lossy conversion on them, and I'm waiting for JXL to be the one.
JPEG XL is great! The only disadvantage IMHO is the association with the JPEG "branding", which I believe in most people's minds is still strongly associated with JPEG artifacts and supporting only lossy compression (which is not the case here).
That's why I would prefer if the creators had "branded" it more as JXL instead of JPEG-XL, to move away from the JPEG stigma a bit (I suspect that's why all their earlier attempts at evolving the JPEG format failed to catch popularity).
I'm calling it JXL whenever I can.
As for use case: having it supported in browsers would greatly promote the standard to be used in general. And it would be great to have an open non-app-specific standard interchange format for source images (supporting things like layers, animations, HDR, etc.) to be used instead of proprietary and/or app-specific formats like PSD, Krita, GIMP, etc. in things like game development projects.
If OSes and browsers support it, then other apps like game engines and image editors will be more likely to also implement support for this format, which is the most flexible image format, while being open-source and open-standard and having the best compression ratios.
It's a format that can be used anywhere, from source assets (because it's lossless and supports many features) to target optimized images/textures (because of great compression). So, please, let's promote it as a new standard.
Oh well, the official fomat name is JPEG XL, best written with the non breaking space Unicode® character.
U+00A0
NO-BREAK SPACE
commonly abbreviated as NBSP
UTF-8: 0xC2 0xA0
UTF-16: 0x00A0
Is that too much?
What I want to do with this feature:
I want to store, and serve patent-unencumbered (no AVIF), lossless and lossy images in the web forum application I've written.
An example of a web forum using said application: https://www.sr20-forum.com
What I'm having to do in the meantime:
Stuck with PNG, JPG and the likes until mainstream browsers get their act together and join Pale Moon with JPG XL support.
Can You 🃏 tell me why is respecting the official registered copy ←↑→↓ wrong. Like Depeche Mode - Wrong - Roma Stadio Olimpico 25.06.2017 4K Ultra HD
JPXL my beloved :heart:
What I want to do with this feature
I want to support it in the Wagtail CMS, so content authors can upload high-resolution images of any kind (photos, computer graphics, etc) with no concerns about compression. They can be confident the images will be served very efficiently for modern browsers, and the conversion from JPEG to JPEG XL on uploads won’t reduce quality.
What I'm having to do in the meantime
We’re using other image formats that offer similar value but all with limitations that we have to inform site implementers and CMS users about, so they decide carefully which format to use where. It would be much simpler to say "upload in JPEG, serve in JPEG XL and JPEG".
@thibaudcolas why isn't AVIF a solution to your problem? Are you concerned about how the small reduction in file size you get from converting JPEG to JXL is wiped out by much higher decoding time?
Please calm down. JXL inclusion is making progress behind the scenes:
7184969: Wire up JXL decoder was merged
https://issues.chromium.org/issues/462919304 is showing progress.
And https://bugzilla.mozilla.org/show_bug.cgi?id=1539075 in Firefox. I've also been working on updating the JPEG XL codec in squoosh.app.
@PELock please, can you calm down? Given the evidence, your rage isn't justified. My questions here are reasonable, and based on research.
This repository is meant to collect votes and use cases from web developers, for web features that aren't yet implemented in all the browsers which Baseline currently considers.
This repository is not meant to implement said features.
@jakearchibald AVIF is definitely working well for us! From my research it’s the best image format for the majority of our users right now. That said, I haven’t done a comparison of JXL vs. AVIF myself but I trust the 10 to 15% improvement reported by Cloudinary on their CID22 dataset. And from what I read the improvements should be bigger for higher-res images, that are relevant to a subset of our users in the GLAM sector. I expect JPEG XL’s recompression feature is also great in the CMS world, as it’s one less thing for our users to worry about, though here as well I haven’t actually measured the exact improvement in our use cases.
Definitely, though it’s more the decoding power consumption that I’m worried about than time. I’ve found it hard to find good information on this tbh. Not just theoretical decoder performance but something more about real-world usage in browsers. Haven’t had the chance to do measurements myself.
I think it’s also worth acknowledging that for us compatibility is a goal in its own right. We support HEIC/HEIF uploads for compatibility with the Apple ecosystem, and just on that basis at this point it’d make sense for us to support JXL uploads too since iPhones now save files in this format. But the format is promising for other reasons, so if our users upload images in that format I’d rather we also supported it when generating optimized images.