JPEG XL: What It Is and Should You Use It?

You've probably seen "JPEG XL" mentioned in an image tool somewhere and wondered what it actually is. Maybe ImgTweak listed it as an output option. Maybe someone in a web dev forum brought it up. Either way, the name sounds like a minor upgrade to the JPEG format you've been using for years, but it's actually something far more interesting than that.

Here's the situation: JPEG has been the dominant image format on the internet since the early 1990s. Thirty-plus years. And for most of that time, it was genuinely the best option available for photographs. Then WebP showed up. Then AVIF. And now JPEG XL, a format that its supporters argue should eventually replace all of them.

That's a bold claim. And the story of how JPEG XL got here including a period where Google tried to kill it, then reversed course is worth understanding before you decide whether to use it.

What JPEG XL Actually Is

JPEG XL (the file extension is .jxl) is a modern image format developed by the JPEG standards committee in partnership with Google and Cloudinary. The standardisation process started in 2017, combined two strong codecs (Google's PIK format and Cloudinary's FUIF format), and produced the final ISO specification in 2022.

The compression technology underneath it is fundamentally different from regular JPEG. Standard JPEG uses a process called discrete cosine transform, which is why compressed photos sometimes develop those blocky artifacts you see around edges and high-contrast areas. JPEG XL uses a different approach that handles both lossy and lossless compression in the same format, with a modular system that adapts to the content it's encoding.

The headline numbers are striking. JPEG XL files are typically 50 to 60% smaller than equivalent JPEG files. Compared to WebP, it tends to come in 20 to 30% smaller. It edges out AVIF by roughly 10 to 15% in most real-world benchmarks at equivalent quality. And unlike AVIF, which was derived from video codec technology designed for different constraints, JPEG XL was built from the ground up to be an image format.

One feature that doesn't get enough attention: JPEG XL can losslessly transcode existing JPEG files. That means you can convert a JPEG to JXL, reduce its file size by about 20%, and convert it back to an identical JPEG with zero quality loss. It's not lossy compression pretending to be lossless. It's a genuinely reversible transformation. For anyone sitting on a large archive of JPEG photos, this is practically useful right now.

The Features That Make It Different

Beyond the compression numbers, JPEG XL has a set of capabilities that no other single format covers:

Progressive decoding this is a big one for web performance. When you load a JPEG XL image on a slow connection, you don't see a blank space followed by a sudden full image. You see a low-resolution version that gradually sharpens as more data arrives. AVIF doesn't support true progressive decoding. WebP doesn't either. JPEG XL does it natively, and it prioritises the salient parts of the image (the subject, the faces, the key visual elements) before filling in the details.

High dynamic range and wide color gamut JPEG XL supports up to 32 bits per channel, compared to JPEG's 8. This matters for professional photography workflows, HDR displays, and any use case where color accuracy is non-negotiable. The PDF Association announced in late 2025 that JPEG XL is their preferred format for HDR images in PDFs. The DNG raw photo format (used by cameras and Apple's ProRAW) now supports JPEG XL compression.

Unlimited image dimensions AVIF has a maximum dimension limit of 65,535 pixels on any side. JPEG XL handles images up to one million by one million pixels. For most people this is irrelevant. For satellite imagery, scientific imaging, or large-format printing, it's not.

Lossless and lossy in one format you don't need different file formats for different use cases. One .jxl file can be losslessly compressed (like PNG) or lossy (like JPEG) depending on your settings. This matters for workflows where different team members need different quality levels from the same source.

Faster decoding than AVIF JPEG XL decodes faster than AVIF in benchmarks. AVIF, being derived from video codec technology, has computational costs that can affect browser performance on lower-powered devices. JPEG XL doesn't have this problem to the same degree.

The Drama: Google Killed It, Then Un-Killed It

Here's where the story gets genuinely strange.

In April 2021, Google added experimental JPEG XL support to Chrome. Developers started testing it. Industry support was growing fast. Facebook, Adobe, Intel, The Guardian, Flickr, SmugMug, Shopify they had all publicly endorsed JPEG XL as their preferred format. Things looked promising.

Then, in October 2022, the Chrome team announced they were removing JPEG XL support from Chrome entirely. The stated reason was "lack of interest from the ecosystem" and insufficient improvements over existing formats. The bug tracker where the decision was discussed gathered over 1,000 upvotes from developers who were furious. Given that Chrome holds the dominant position in the browser market, a Chrome rejection is effectively a rejection from a huge portion of web users.

Safari had shipped JPEG XL support in September 2023. Firefox was moving in a supportive direction. But without Chrome, adoption on the web was essentially stalled.

Then momentum started building again. The PDF Association added JXL to the spec in November 2025. Firefox continued moving toward implementation. The State of HTML survey, co-sponsored by Google, showed that JPEG XL support was among the top pain points cited by developers.

On November 21, 2025, Rick Byers, Chrome's Architecture Tech Lead, posted a reversal. The Chromium team would welcome contributions to a JPEG XL decoder. By January 2026, the Rust-based decoder called jxl-rs had been merged into Chromium. Chrome 145, released in February 2026, shipped JPEG XL support behind a flag (chrome://flags/#enable-jxl-image-format).

It's not enabled by default yet. Google has set conditions including long-term maintenance commitments and standard launch criteria. But the code is there. The direction is clear.

Where Browser Support Actually Stands

This is the part that matters most for whether you should use JPEG XL right now.

As of April 2026, Safari supports JPEG XL natively. Chrome has it available behind a flag but not on by default. Firefox is implementing it but hasn't shipped stable support. As of 2026, web browsers that support JPEG XL have roughly 12% market share almost entirely Safari users.

That number sounds bad. And for serving JXL as your primary format without fallbacks, it is bad. But here's the more nuanced picture:

The Chromium engine powers Chrome, Edge, Brave, Opera, and a long list of other browsers. When Google ships JPEG XL support to stable Chrome (not behind a flag), that percentage jumps dramatically. Based on Chrome's market share alone, it would go from 12% to something closer to 70 to 80% in a single release.

The question isn't whether JPEG XL will achieve broad browser support. The trajectory is clear, and the momentum is real. The question is when.

Should You Use It Today?

The honest answer depends on what you're trying to do.

For archiving and local storage: yes, absolutely. JPEG XL's lossless JPEG recompression alone makes it worth considering for photo archives. You can shrink your JPEG collection by around 20% with zero quality loss, and convert everything back whenever you need to. Tools like ImgTweak already support JPEG XL output, so you can do this in your browser without uploading anything. Software support is also solid Windows 11 added native JXL support in its 24H2 update in March 2025, and Microsoft Photos added it shortly after.

For web delivery to a general audience: not yet as a standalone format. If you serve a JPEG XL image without a fallback to someone using Chrome with the flag disabled, they'll see a broken image. You need a fallback strategy. The standard approach is a <picture> element with a JXL source and a WebP or JPEG fallback:

<picture>
  <source srcset="photo.jxl" type="image/jxl" />
  <source srcset="photo.avif" type="image/avif" />
  <img src="photo.jpg" alt="Description" />
</picture>

This works, but it means maintaining multiple versions of every image. That's more complexity than most sites want to take on while browser support is still limited.

For professional photography workflows: increasingly yes. Camera manufacturers are starting to take notice. JPEG XL is now embedded in the DNG specification, making it relevant to RAW photo workflows. If you use Lightroom, be aware that Lightroom's JXL export has a known issue where it can produce files dramatically larger than the equivalent JPEG there's a well-documented thread about this in Adobe's community forums. RawTherapee supports opening JXL files, with export support planned for version 6.0. Photopea supports it with a plugin.

For Cloudinary customers: already happening. Cloudinary one of the format's original developers automatically serves JPEG XL to browsers that support it. If you use their platform, you're already delivering JXL to Safari users.

JPEG XL vs AVIF vs WebP: The Practical Comparison

If you're deciding between formats for a project right now, here's how they shake out:

WebP is the safe, boring choice. 96% browser support. 25 to 34% smaller than JPEG. Works everywhere. If you're not doing anything special, convert to WebP and move on. ImgTweak's JPG to WebP converter handles this in your browser with no uploads.

AVIF is the performance choice for 2025 and 2026. 95% browser support. 20 to 50% smaller than WebP at equivalent quality. Excellent for photographs and product imagery. The encoding is slower than WebP, but since you encode once and decode millions of times (on user devices), that tradeoff is generally worth it. Convert JPG to AVIF here. The downside: AVIF has an 8192-pixel dimension limit in some implementations (technically 65,535, but tiling artifacts can appear beyond 8192), and decoding is computationally heavier than JPEG XL.

JPEG XL is the future-proof choice for specific use cases. Better compression than both at high quality levels. True progressive decoding. Unlimited dimensions. Lossless JPEG recompression. But browser support is still limited for general web delivery.

The format that wins in benchmarks isn't always the format you should be using. AVIF beats JPEG XL at low-to-medium quality settings (heavy compression). JPEG XL beats AVIF at high quality settings the kind you'd use for professional photography. For product shots, portraits, and high-fidelity web imagery, JXL's edge at higher quality is real.

The Lossless JPEG Recompression Thing (It's Actually Remarkable)

This feature deserves its own paragraph because it's unlike anything any other format offers.

When you save a JPEG, you lose some quality. That's permanent. But because JPEG XL understands the JPEG compression format at a deep level, it can store a JPEG's exact compressed data inside a JXL container without re-encoding the pixels. The result is a .jxl file that's about 20% smaller than the original .jpg, but contains the complete, byte-for-byte recoverable JPEG.

If you have ten years of photos stored as JPEGs and you've lost some of the originals, converting to JXL using lossless recompression gives you smaller files with no additional quality loss. And if you ever need the JPEG back for a device, software, or upload portal that doesn't support JXL you can reconstruct it perfectly.

This use case exists today, regardless of browser support. It doesn't require Chrome to ship JXL to stable. It just requires a tool that supports lossless JXL encoding. The format's value isn't locked behind the browser support question.

What to Actually Do Right Now

If you're a web developer or someone who works with images regularly, here's the practical path:

For your current web projects, use AVIF as your primary modern format with a JPEG fallback. AVIF has 95% browser support and genuinely better compression than WebP. It's the right default for 2026.

For your photo archives, consider converting JPEGs to JXL for storage not for web delivery, but for preservation and space savings. The lossless recompression is genuinely useful and works today.

Watch the Chrome stable release notes. When Google ships JXL to stable Chrome (not behind a flag), the calculus changes completely. That's when the <picture> element approach becomes worth the complexity for mainstream web delivery.

If you're just trying to reduce file sizes for everyday tasks job applications, form uploads, email attachments ImgTweak's image compressor handles all the formats you need, including JPEG XL output, all in your browser with nothing uploaded to any server. The compress to exact size tools are particularly useful when a portal has a strict file size limit.

The Bottom Line

JPEG XL is technically the best general-purpose image format available. That's not a controversial claim among people who work with image codecs. The compression is better, the features are better, the decoding speed is better, and the backward compatibility with JPEG is something no other format offers.

What's been holding it back is browser support, and specifically Google's decision to remove Chrome support in 2022. That decision now looks like a mistake, and it's being corrected. Chrome 145 has the code. The flag is there. Stable support is a matter of timing.

For right now, in April 2026, JPEG XL is the format you should know about, experiment with for archiving and specific workflows, and keep an eye on. AVIF is what you should be using for web delivery. WebP is your fallback when you need near-universal compatibility.

The interesting thing about image formats is that they move slowly until they don't. WebP took about a decade to reach broad adoption after Google introduced it in 2010. AVIF got there faster because browser makers were more coordinated. JPEG XL has better technical fundamentals than either. When Chrome ships stable support and the trajectory strongly suggests it will the ecosystem momentum should follow faster than people expect.

You don't have to bet on it today. But understanding where things are heading means you won't be caught flat-footed when "should I use JPEG XL?" stops being a question and starts being the obvious answer.