JPEG XL: The Format Chrome Killed and Brought Back

The full story of JPEG XL — why Google removed it from Chrome, how the community fought to restore it, and why JXL might finally become the image format the web deserves. Includes technical advantages, browser support status, and conversion tips.

Published March 10, 2026 · Updated March 10, 2026

No image format in history has had a more dramatic journey than JPEG XL. Designed to be the successor to the most ubiquitous image format ever created, it was championed, abandoned, mourned, and ultimately resurrected in one of the most contentious technical decisions Google has ever made. The story of JPEG XL is a story about corporate incentives, open standards, community pressure, and the surprisingly political question of how images should be compressed on the internet.

As of early 2026, JPEG XL is finally supported in every major browser. But getting here was a fight, and understanding that fight explains a lot about why the web works the way it does.

A Brief History of Trying to Replace JPEG

JPEG has been the default image format since 1992. For over three decades, it has been the universal language of digital photography. Every camera, phone, computer, printer, website, and messaging app on earth understands JPEG. It's an extraordinary run for any technology, let alone a compression standard designed when 640x480 was considered high resolution.

But JPEG is showing its age. It's limited to 8-bit color (16.7 million colors) in an era of HDR displays that can show billions. It doesn't support transparency. Its compression algorithm, while clever for 1992, leaves substantial efficiency on the table compared to modern techniques. And perhaps most frustratingly, every time you edit and re-save a JPEG, it loses quality — the dreaded generation loss.

The industry has been trying to replace JPEG for two decades. Here's the scorecard:

JPEG 2000 (2000) — technically superior, but computationally expensive and patent-encumbered. Adopted in professional imaging (medical, cinema, archival) but never made it to the web. Safari supported it; no one else did.

WebP (2010) — Google's format, based on the VP8 video codec. Good compression (25-35% smaller than JPEG), transparency support, animation. But lossy-only initially, no progressive decode, limited to 8-bit color, and for years only supported in Chrome. Now universal with 97%+ browser support, but technically modest compared to what came next.

AVIF (2019) — based on the AV1 video codec, backed by the Alliance for Open Media (Google, Apple, Netflix, Mozilla, and others). Excellent compression, HDR support, but painfully slow encoding and a 2D-tile-based architecture that creates visible grid artifacts at certain quality levels. Browser support is good but incomplete.

JPEG XL (2021) — designed from the ground up specifically as a next-generation still image format by the JPEG committee. Not derived from a video codec. This distinction matters enormously, as we'll see.

What Makes JPEG XL Technically Special

JPEG XL (file extension .jxl) was created by the Joint Photographic Experts Group — the same standards body behind original JPEG. It incorporates research from Google (their Pik format) and Cloudinary (their FUIF format), and it was designed with a clear mandate: be definitively better than JPEG at everything, while maintaining practical compatibility.

Compression efficiency

JPEG XL achieves roughly 60% smaller file sizes than JPEG at equivalent visual quality. That's not a typo — we're talking about files that are less than half the size of JPEG, with no visible difference. The compression gains come from a fundamentally more sophisticated encoding pipeline that uses variable-block-size transforms (up to 256x256 pixels, vs. JPEG's fixed 8x8), better entropy coding, and advanced prediction models.

Compared to WebP and AVIF:

The compression advantage over WebP is substantial, and while AVIF gets close in some benchmarks, JPEG XL's encoding is dramatically faster — often 5-10x faster than AVIF at similar quality levels. In production workflows where you're encoding thousands of images, this difference is measured in hours.

Lossless JPEG recompression

This is JPEG XL's most underrated feature and, arguably, its most practically important one. JPEG XL can take an existing JPEG file and recompress it losslessly — producing a .jxl file that's approximately 20% smaller than the original JPEG, while preserving every single bit of the original data. You can later decompress the JXL file back to the exact original JPEG, byte for byte identical.

No other format can do this. When you convert a JPEG to WebP or AVIF, you're re-encoding it with a new lossy algorithm, which means additional quality loss (however small). JPEG XL's lossless recompression means you can shrink your existing JPEG archives by 20% without touching the image data at all. For organizations sitting on terabytes of JPEG photos — news agencies, stock photo services, social media platforms, cloud storage providers — this is potentially worth millions in storage costs.

Progressive decoding

JPEG XL supports true progressive decoding, similar to progressive JPEG but far more capable. When loading a large JXL image, you first see a very low-resolution preview (almost instantly), then the image refines in stages until full quality is reached. Each progressive pass is a complete, usable image — not a partial load that displays top-to-bottom.

This matters for perceived performance. On slow connections, a progressive JXL image appears to load instantly (with a blurry preview) and sharpen over time, rather than loading painfully line by line. WebP has no progressive mode at all. AVIF has limited progressive support that most implementations don't use.

HDR and wide color gamut

JPEG XL supports up to 32-bit floating point color depth and the full range of HDR color spaces (PQ, HLG, and linear transfer functions). With HDR displays becoming standard on phones (every iPhone since the 12), laptops (MacBook Pro, many Windows laptops), and monitors, a format that can actually represent HDR content natively is increasingly important.

JPEG is stuck at 8-bit SDR. WebP is also 8-bit. AVIF supports HDR but its tile-based architecture can create visible block boundaries in smooth HDR gradients. JPEG XL handles HDR gracefully because its variable-block-size architecture was designed for it from the start.

Additional technical strengths

• Lossless mode that's competitive with PNG in file size, but significantly faster to decode
• Animation support that's more efficient than WebP animation and GIF
• Alpha channel with separate quality control (lossy image + lossless alpha)
• Up to 4 billion x 4 billion pixels — no practical resolution limit
• EXIF, XMP, and IPTC metadata support
• Royalty-free — no patent licensing required, ever
• Designed for parallelism — encoding and decoding scale efficiently across CPU cores

The Chrome Controversy: What Happened and Why

Given all these technical advantages, you'd expect JPEG XL adoption to have been straightforward. Instead, what happened was one of the most controversial decisions in recent browser history.

The flag era (2022-2023)

Chrome added experimental JPEG XL support behind a feature flag (chrome://flags/#enable-jxl) in Chrome 91 (May 2021). Developers and photographers could enable it manually to test JXL images in the browser. Everything was on track.

Then, in October 2023, Google removed JPEG XL support from Chrome entirely — not just the flag, but all the underlying code. The commit message was terse, citing "insufficient ecosystem interest" and "not enough interoperability benefits." The Chromium bug tracker ticket discussing the removal received over 1,000 comments, overwhelmingly negative, making it one of the most commented issues in Chromium's history.

Why Google removed it

Google never gave a fully satisfying public explanation, but the community assembled a credible picture from various public statements and technical discussions:

1. Google had competing formats. WebP was Google's format, and AVIF was developed by a consortium that Google co-led. Supporting JPEG XL — a format developed by an independent standards body — would compete with Google's own investments.

2. Maintenance burden argument. Supporting an additional image codec in Chrome means more code to maintain, more security surface area, and more edge cases to handle. Google argued that WebP and AVIF already covered the use cases that JPEG XL addressed.

3. Ecosystem chicken-and-egg. With Chrome holding roughly 65% of browser market share, removing JXL support effectively killed adoption. No one would serve JXL images if the majority browser couldn't display them. Google then pointed to this lack of adoption as evidence of "insufficient ecosystem interest" — a circular argument that did not go unnoticed.

The backlash

The response from the technical community was intense. Professional photographers, imaging researchers, CDN providers (Cloudinary, Fastly), standards body members, and web developers all pushed back. Several key criticisms emerged:

• JPEG XL was the only format not controlled by Google or a Google-led consortium
• The lossless JPEG recompression feature alone justified the format's existence
• Safari and Firefox were actively implementing JXL support, undermining the "insufficient interest" claim
• Chrome's market dominance gave Google effective veto power over web standards

Apple added JPEG XL support to Safari 17 (September 2023), and Mozilla began implementing it in Firefox — both moves that implicitly criticized Google's decision.

The reversal

Under sustained pressure from the web community, imaging industry, and competing browser vendors, Google reversed course. In late 2025, Chromium re-added JPEG XL support, and it shipped enabled by default in Chrome 145 (February 2026). The accompanying announcement was notably more measured than the original removal, acknowledging the format's technical merits and the "strong community feedback."

As of March 2026, JPEG XL is supported in:

• Chrome 145+ (February 2026) — enabled by default
• Safari 17+ (September 2023) — enabled by default
• Firefox 135+ (2025) — enabled by default
• Edge 145+ (February 2026, follows Chrome) — enabled by default
• Opera, Brave, Vivaldi — follows Chromium, so also supported

For the first time, JPEG XL has genuine cross-browser support. The question is no longer "will it be supported?" but "how quickly will it be adopted?"

JPEG XL vs. AVIF: Which Should You Use?

Both formats are technically impressive, and they coexist rather than directly compete. But understanding their respective strengths helps you choose the right one.

Where JPEG XL wins

• Encoding speed: JXL encodes 5-10x faster than AVIF at similar quality. For batch processing or real-time encoding, this is a decisive advantage.
• Decoding speed: JXL decodes faster than AVIF, which matters for page rendering performance.
• Progressive decoding: JXL has native, well-designed progressive rendering. AVIF's progressive support is limited and rarely implemented.
• Lossless JPEG recompression: Unique to JXL. If you have existing JPEG archives, this feature alone is worth adopting JXL.
• HDR handling: JXL's continuous-tone compression handles HDR gradients more cleanly than AVIF's tile-based approach.
• No tile artifacts: AVIF can produce visible grid-like artifacts at the boundaries of its 2D tiles, especially at lower quality settings. JXL's variable-block architecture doesn't have this problem.

Where AVIF wins

• Smaller files at low quality: At very aggressive compression levels (low quality settings), AVIF can produce slightly smaller files than JXL. This matters for thumbnails and highly compressed previews.
• Longer track record in browsers: AVIF has been in Chrome since 2020 and has more established tooling.
• Industry backing: The Alliance for Open Media includes most major tech companies, ensuring ongoing investment.
• Video codec synergy: AVIF shares a decoder with AV1 video. Sites already using AV1 video get AVIF decoding "for free" in terms of code size.

Practical recommendation

Use both. The HTML <picture> element was designed precisely for this kind of scenario:

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

The browser will use the first format it supports. With this approach, you get the best compression for each browser without breaking compatibility for any user.

For build pipelines and CDNs, many services now support automatic format negotiation — they detect the browser's Accept header and serve the optimal format. Cloudflare, Cloudinary, Imgix, and AWS CloudFront all support this.

Converting JPEG XL Files Today

While browser support for displaying JXL images is now solid, many applications and platforms still don't accept JXL uploads. If you have JXL files that need to be in JPEG, PNG, or WebP format, conversion is straightforward.

Browser-based conversion

Fileza supports converting JXL files to JPG, PNG, and WebP directly in your browser. Since Chrome, Safari, and Firefox can now decode JXL natively, the conversion uses the same Canvas API pipeline as any other image format — decode to pixels, re-encode in the target format.

Command-line tools

For batch processing and automation, the reference JPEG XL implementation (libjxl) provides two essential command-line tools:

# Convert JPEG XL to PNG
djxl input.jxl output.png

# Convert JPEG XL to JPEG
djxl input.jxl output.jpg

# Convert JPEG to JPEG XL (lossy)
cjxl input.jpg output.jxl -q 80

# Convert JPEG to JPEG XL (lossless JPEG recompression)
cjxl input.jpg output.jxl -q 100

# Reconstruct the original JPEG from lossless JXL
djxl output.jxl reconstructed.jpg

Installation on various platforms:

# macOS (Homebrew)
brew install libjxl

# Ubuntu/Debian
sudo apt install libjxl-tools

# Windows (via Chocolatey)
choco install libjxl

Image editors

Software that natively supports JPEG XL as of 2026:

• GIMP 2.10.32+ — open/save JXL via plugin
• darktable 4.0+ — raw workflow with JXL export
• XnView MP — viewing and batch conversion
• ImageMagick 7.1+ — full JXL support (magick input.jxl output.jpg)
• Krita 5.1+ — open/save support
• Adobe products — Photoshop and Lightroom added JXL support in late 2025

Notably, many web-based design tools (Canva, Figma) do not yet export to JXL, though they may accept JXL uploads as input.

Creating JPEG XL Images for Your Website

If you want to start serving JXL images on your website, here's a practical approach.

Step 1: Generate JXL versions of your images

Use cjxl for batch conversion:

# Convert all JPEGs in a directory to JXL at quality 80
for f in *.jpg; do
  cjxl "$f" "${f%.jpg}.jxl" -q 80 -e 7
done

The -e flag controls encoding effort (1-9). Higher effort means slower encoding but smaller files. For a one-time conversion of static website images, use -e 7 or -e 9. For real-time or high-volume encoding, -e 3 or -e 4 provides a good speed/size trade-off.

Step 2: Serve with content negotiation

The simplest approach is the <picture> element shown earlier. For server-level negotiation, configure your web server to check the Accept header:

# Apache .htaccess
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTP_ACCEPT} image/jxl
  RewriteCond %{REQUEST_URI} \.(jpg|jpeg|png)$
  RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI}.jxl -f
  RewriteRule (.+)\.(jpg|jpeg|png)$ $1.$2.jxl [T=image/jxl,L]
</IfModule>

# Ensure correct MIME type
AddType image/jxl .jxl

Step 3: Measure the results

After deploying JXL, measure the actual file size savings across your image catalog. Real-world results will vary by image content, but expect:

• Photographs: 40-60% smaller than JPEG equivalents
• Screenshots/graphics: 20-40% smaller than PNG equivalents (lossless JXL vs. PNG)
• Existing JPEGs (lossless recompression): exactly 20% smaller with zero quality change

Monitor your Core Web Vitals (LCP, CLS) through Google Search Console — the reduced file sizes should translate directly into faster Largest Contentful Paint times.

The Future of JPEG XL

With universal browser support now achieved, JPEG XL's path forward depends on tooling and platform adoption. The signs are promising:

CDN support is growing. Major CDNs are adding JXL to their automatic format negotiation, meaning website operators can benefit without manually generating JXL versions.

Camera manufacturers are watching. JXL's ability to store HDR data efficiently and its lossless recompression of existing JPEG makes it attractive for camera firmware updates. Several manufacturers have hinted at JXL as a capture format.

Social media and messaging platforms will likely begin accepting JXL uploads as browser support matures. Instagram and WhatsApp could save enormous bandwidth by serving JXL to supported clients.

Operating system integration is the remaining frontier. Windows and Android need native JXL support in their image viewers and file managers. macOS and iOS already support JXL through Safari's engine.

The format's journey has been unconventional, to put it mildly. But with the technical controversy resolved and browser support in place, JPEG XL is finally positioned to fulfill its potential as the rightful successor to the most important image format ever created. Whether adoption actually follows will be one of the more interesting web platform stories to watch over the coming years.