For years, JPEG XL has occupied an awkward position in web development.
The format had an impressive feature set. It could compress photographs efficiently, preserve images losslessly, handle HDR and wide color, progressively decode large images, and even losslessly transcode existing JPEG files. On paper, it looked like exactly the kind of format the modern web should want.
The problem was simpler: browsers did not agree.
That equation changed on October 6, 2026, when Chrome began shipping JPEG XL decoding in Chrome 155. Google’s Chrome team says JPEG XL can deliver 30–50% better compression than JPEG, along with lossless compression, built-in HDR, and lossless JPEG transcoding. More importantly for developers, Chrome now recommends trying both JPEG XL and AVIF rather than treating one format as the universal answer.
So the question has changed.
It is no longer “Can JPEG XL compete with modern image formats?”
It is:
“Now that Chrome supports it, should you actually use JPEG XL on your website?”
The answer is more interesting than a simple yes or no.
Key Points
- JPEG XL is now shipping in Chrome 155, giving the format a much more important position on the web.
- JPEG XL supports both lossy and lossless compression, HDR, wide color gamut, transparency, animation, and progressive decoding.
- Its lossless JPEG transcoding is one of its most unusual advantages: an existing JPEG can be converted to JPEG XL and later reconstructed as the original JPEG.
- WebP remains the safest broad-compatibility choice, while AVIF remains a strong default for highly compressed modern web imagery.
- JPEG XL becomes particularly interesting for high-quality photography, large images, HDR, archival workflows, and lossless delivery.
- Chrome support does not mean JPEG XL should immediately replace AVIF or WebP everywhere.
- For production sites, the practical approach is to test JPEG XL against the formats you already serve and provide fallbacks.
JPEG XL Finally Has a Browser Story
Image formats live or die by more than their compression algorithm.
A format can produce a smaller file and still be a poor web choice if a significant portion of visitors cannot display it.
That has been one of JPEG XL’s biggest problems.
As of October 2026, that picture is changing. Chrome 155 and later support JPEG XL decoding, while current compatibility data also lists support in Firefox 158 and later. Safari has partial support, while Edge currently does not list JPEG XL as supported.
That is progress, but it is not universal support.
And that distinction matters.
“A major browser supports JPEG XL” and “JPEG XL is safe to use as the only image format” are two very different statements.
The second one is not true yet.
For most websites, a fallback strategy remains sensible.
What Makes JPEG XL Different?
JPEG XL is not simply another attempt to squeeze a JPEG a little harder.
It was designed as a much broader image format.
The JPEG committee lists support for lossy and lossless compression, progressive coding, HDR, wide color gamut, animation, alpha channels, layers, and high bit depths among its capabilities. It was also designed with responsive web environments and professional photography in mind.
That gives JPEG XL an unusually wide range.
A typical product image might only need efficient lossy compression.
A photographer may care more about preserving subtle detail.
An HDR image needs a format that can carry a larger range of brightness.
An archival system may care about lossless storage.
And a company migrating a huge JPEG library may want to reduce storage without permanently throwing away the original JPEG data.
JPEG XL attempts to cover all of those cases.
That versatility is one of the reasons it is worth reconsidering now.
The Feature That Could Matter More Than Compression
The most interesting JPEG XL feature may not be its headline compression numbers.
It is lossless JPEG transcoding.
JPEG XL can take an existing JPEG and transcode it into a JPEG XL representation while preserving enough information to reconstruct the exact original JPEG later. The JPEG organization describes this as a way to reduce storage while maintaining compatibility with existing JPEG-based systems.
That creates a different migration path from the usual image-format conversion.
With a normal lossy conversion, you might take:
JPEG → AVIF
and accept that the new file represents a recompressed version of the image.
JPEG XL can instead offer:
JPEG → JPEG XL → original JPEG
without changing the underlying JPEG image through the transcoding process.
The JPEG XL white paper reports lossless JPEG transcoding reductions of roughly 16–22% for the tested JPEG material, although real-world savings will depend on the images and encoding workflow.
That makes JPEG XL particularly interesting for large image libraries, archives, photography platforms, and systems where retaining the original JPEG matters.
JPEG XL vs WebP vs AVIF
There is no single winner.
Each format has a different balance of compatibility, compression, features, and practical usefulness.
| Format | Compression | Lossless | HDR | Progressive decoding | Browser position |
|---|---|---|---|---|---|
| WebP | Very good | Yes | Limited compared with newer formats | No | Broad |
| AVIF | Excellent | Yes | Yes | No | Broad modern support |
| JPEG XL | Excellent | Yes | Yes | Yes | Growing, but not universal |
WebP remains the conservative choice. It has broad support across current major browsers and provides both lossy and lossless compression.
AVIF pushes compression further and supports HDR, wide color gamut, transparency, animation, and both lossy and lossless encoding. MDN notes that AVIF generally provides better compression than WebP, although its support has historically been less established.
JPEG XL brings a different combination to the table.
It offers modern compression alongside features such as progressive decoding, HDR, wide color, high bit depth, and lossless JPEG transcoding.
So the decision should not be:
JPEG XL is newer, therefore JPEG XL wins.
The useful question is:
Which format gives this particular image the best balance of size, quality, features, and browser coverage?
That is a much better optimization strategy.
Where JPEG XL Looks Especially Strong
Some types of websites have more reason to experiment with JPEG XL than others.
High-resolution photography
Photography is an obvious candidate.
Photographs contain large amounts of continuous visual information, and JPEG XL was designed with high-fidelity imagery in mind. Chrome specifically says it expects JPEG XL to be especially useful for high-fidelity or lossless compression, particularly with photographic images.
That makes galleries, portfolios, stock photography platforms, publishing sites, and image-heavy applications worth testing.
HDR imagery
HDR is another area where JPEG XL has a strong feature story.
JPEG XL supports high dynamic range, wide color gamut, and higher bit depths.
That matters because image delivery is no longer only about making an 8-bit sRGB photograph smaller.
Modern displays can show considerably more information.
If your site actually serves HDR or wide-gamut photography, JPEG XL becomes much more interesting than it is for an ordinary thumbnail.
Large images where progressive decoding matters
JPEG XL supports progressive decoding.
That allows an image to begin appearing before every bit of the full-resolution representation has arrived. The JPEG XL project describes progressive decoding as one of the format’s core capabilities, while Chrome specifically highlights cases where fine-grained progressive decoding is preferred.
That does not automatically make JPEG XL faster.
A larger file can still be a larger file.
But for certain high-resolution images, progressive presentation can be valuable to the perceived loading experience.
Image archives
This may be one of the strongest practical use cases.
Suppose a platform has millions of JPEG photographs.
Instead of treating JPEG XL only as a new delivery format, the platform can investigate it as a storage and migration format too. Lossless JPEG transcoding creates an unusual opportunity to reduce storage while retaining the ability to reconstruct the JPEG source.
That is a different proposition from simply replacing .jpg with .avif.
Where AVIF Still Makes More Sense
None of this makes AVIF obsolete.
Quite the opposite.
AVIF remains an excellent web format with strong compression and modern image features. Current browser support includes Chrome, Edge, Firefox, Opera, and Safari, and MDN recommends fallbacks because newer image formats still do not have the historical depth of JPEG.
For a typical website with:
- product photography
- blog images
- thumbnails
- marketing graphics
- hero images
- standard 8-bit photographs
AVIF may still be the more straightforward modern format.
There is little value in adopting JPEG XL simply because it has arrived in Chrome.
If AVIF gives you a smaller file at the same visual quality, works across your target browsers, and fits your existing image pipeline, there may be no reason to switch.
JPEG XL needs to earn its place through testing.
And WebP Is Not Going Away
WebP has an advantage that is easy to underestimate:
It works almost everywhere that matters for modern web delivery.
MDN lists WebP support across Chrome, Edge, Firefox, Opera, and Safari. It supports lossy and lossless compression, transparency, and animation.
That makes WebP particularly useful when compatibility matters more than extracting every possible byte of savings.
It may not be the most technically advanced format in this comparison.
It may still be the right engineering decision.
A format choice is not a technology competition.
It is a delivery decision.
The Smart Way to Introduce JPEG XL
You do not need to convert your entire image library on day one.
Start with a controlled test.
Take a representative group of images:
- photographs
- screenshots
- product images
- large hero images
- thumbnails
- transparent graphics
- HDR images, if you actually serve them
Then encode the same source images as WebP, AVIF, and JPEG XL.
Do not compare only file sizes.
Measure:
File size
How many bytes are actually saved?
Visual quality
Does the smaller file still look good at the size users see it?
Encoding time
How expensive is it to generate the files?
Decoding behavior
Does the format perform well on the devices you care about?
Browser coverage
How many users can actually receive the preferred format?
Operational complexity
Does adding another format complicate your CDN, CMS, cache, image pipeline, or build process?
That last measurement is often forgotten.
Saving 8% of image bytes may not be worth rebuilding a complicated production pipeline.
Saving 40% on a huge photography library might be.
You Can Serve JPEG XL Without Abandoning Everything Else
The web already has a mechanism for this kind of progressive format delivery: the <picture> element.
For example:
<picture>
<source srcset="hero.jxl" type="image/jxl">
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img
src="hero.jpg"
alt="A developer working at a desk">
</picture>The important idea is not the exact order.
It is that the browser can select an image format it understands while the final <img> remains available as the fallback.
MDN recommends this general fallback approach for newer formats whose browser support is not universal.
That makes experimentation considerably less risky.
You can introduce JPEG XL for capable browsers without forcing every visitor onto it.
But Do Not Add Formats Just to Say You Support Them
There is a performance trap hiding here.
Developers sometimes treat format support as a checklist:
- JPEG
- PNG
- WebP
- AVIF
- JPEG XL
Done.
But every additional variant can affect:
- build time
- storage
- CDN cache keys
- image processing
- deployment size
- monitoring
- debugging
- content negotiation
- CMS complexity
If your image pipeline already generates WebP and AVIF, adding JPEG XL should have a measurable reason behind it.
The goal is not to collect formats.
The goal is to deliver the right image with the least unnecessary cost.
So, Is JPEG XL Finally Worth Using?
For some websites, yes.
For every website, not yet.
Chrome’s decision is significant because JPEG XL now has a major browser implementation behind it. Chrome itself recommends trying JPEG XL alongside AVIF and expects the format to be particularly useful for high-fidelity and lossless imagery.
But the browser-support picture is still fragmented. Current compatibility data shows Chrome 155+ and Firefox 158+ support, while Safari remains partial and Edge does not currently provide full support.
That makes JPEG XL a strong additional format to evaluate, not an automatic replacement for everything else.
For a conventional content site, AVIF or WebP may remain the simplest production choice.
For a photography platform, image archive, high-resolution media site, HDR workflow, or system that already has a large JPEG library, JPEG XL deserves much more serious attention.
And there is a useful middle ground between “ignore JPEG XL” and “convert everything.”
Test it.
Take your real images. Compare them against AVIF and WebP at comparable visual quality. Measure the bytes, encoding cost, loading behavior, and browser coverage.
Then make the decision from your own data.
That is what image optimization has always been about.
Not choosing the format with the best specification.
Choosing the format that gives your users the best result for the least cost.