If you’ve been building websites or managing media pipelines for any length of time, you’ve likely lived through the "image format wars." We survived the crude transition from bloated GIFs to PNGs, spent years waiting for WebP to get decent browser support, and more recently, we’ve watched AVIF attempt to claim the throne of high-efficiency web image formats. But for a brief, shining moment, there was a unified beacon of hope on the horizon: JPEG XL (JXL).
Co-authored by the Joint Photographic Experts Group and Google, JPEG XL promised to be the holy grail. It boasted better compression than AVIF, lossless transcoding of legacy JPEGs (saving 20% on storage instantly without losing a single pixel), progressive decoding, and massive performance improvements. Yet today, if you look at the support tables, JPEG XL is noticeably absent from Google Chrome and Microsoft Edge, leaving web developers in a frustrating holding pattern.
So, what happened? Why is a technically superior format being sidelined, and what does this mean for the future of web development? Let’s dive into the engineering, the politics, and the practical workarounds we have to deal with today.
The Technical Promise: Why Developers Fell in Love with JPEG XL
Before we look at why JXL is stalled, we need to understand why developers were so excited about it in the first place. This wasn’t just "another incremental codec." It solved real architectural pain points in web asset delivery.
1. Lossless JPEG Transcoding (The Killer Feature)
If you run a platform with petabytes of user-uploaded JPEGs (like Instagram, Shopify, or eBay), converting them to AVIF or WebP requires a lossy re-encode. You either lose image quality, or you keep the original JPEGs and eat the massive storage costs.
JPEG XL solved this with an ingenious feature: it can take an existing JPEG and transcode it into a JXL file that is roughly 20% smaller without losing a single bit of information. Better yet, this process is completely reversible. You can reconstruct the original, byte-identical JPEG on the fly if a legacy client requests it.
2. Progressive Decoding That Actually Works
Remember 1990s-style progressive JPEGs, where the image slowly loaded from blurry to sharp? JPEG XL modernizes this concept. Unlike AVIF (which is based on the AV1 video codec and must be decoded in blocks), JXL was designed from the ground up for still images. It supports highly optimized progressive rendering. A tiny fraction of the data (say, 15%) is enough to render a visually pleasing preview, drastically improving perceived page load times on slow mobile connections.
3. Blazing Fast Encoding and Decoding
AVIF offers incredible compression, but it has a massive Achilles' heel: encoding time. Running a high-effort AVIF encode on a busy server can easily peg your CPU. JPEG XL is highly parallelizable and designed with modern multicore processors in mind. It encodes significantly faster than AVIF and decodes faster than legacy JPEG, making it highly friendly for real-time image processing pipelines.
The Case Against JPEG XL: Why the Browsers Backed Out
With all these advantages, JPEG XL seemed like a slam dunk. In 2021, Chrome, Firefox, and Safari all added experimental support behind flags. The community was ecstatic. But in late 2022, Google made the shocking decision to remove JPEG XL support from Chrome entirely.
The Chromium team provided several reasons for the deprecation, which sparked a firestorm of debate across the web development community. Let's analyze their main arguments:
Argument 1: "Not enough interest from the ecosystem"
Google claimed there was a lack of interest from ecosystem partners to warrant maintaining the code. This felt disingenuous to many developers. At the time of removal, the Chrome tracking bug for JPEG XL was one of the most starred issues in Chromium history, with companies like Facebook, Adobe, Shopify, and VESA expressing strong support.
Argument 2: "The image format space is crowded"
With JPEG, PNG, WebP, and AVIF already supported, browser vendors are hesitant to commit to maintaining another complex image parser. Every new parser added to a browser increases the attack surface for security vulnerabilities (buffer overflows, remote code execution). Unless a format offers a "generational leap," browsers prefer to consolidate.
Argument 3: "AVIF covers the high-efficiency use case"
Google has heavily backed AVIF (and the AV1 video codec it is derived from). From Google's perspective, AVIF is "good enough" for the web. It compresses extremely well at small file sizes, and because Android and Chrome are already shipped with AV1 decoders, maintaining AVIF requires less architectural overhead.
The Counterpoint: The Real Friction Points of JPEG XL
While Google's decision was highly criticized, it’s worth looking at the genuine engineering challenges that JPEG XL presents. It isn't a silver bullet, and its critics do have some valid points:
- Lack of Hardware Acceleration: Because JPEG XL is relatively new, there are no consumer chips with hardware-accelerated JXL decoding. AVIF, on the other hand, benefits from hardware AV1 decoders being built into modern GPUs (Intel Arc, Nvidia RTX 40-series, Apple M3, and modern mobile SoCs). Software-only decoding eats battery on mobile devices.
- Complexity: The JPEG XL specification is incredibly rich, supporting up to 4099 channels, print workflows, CMYK, and custom transformations. This complexity makes writing secure, bug-free parsers highly challenging.
- The AV1 Network Effect: Silicon Valley giants have invested billions of dollars into the Alliance for Open Media (AOMedia) to promote AV1. They want a single, unified codec family for both video (AV1) and images (AVIF). Introducing JPEG XL disrupts this unified ecosystem play.
How to Serve Next-Gen Images Today: A Modern Pipeline
As web developers, we can’t wait for browser politics to resolve. We need to deliver fast, lightweight websites to our users today. Fortunately, the <picture> element allows us to use progressive enhancement to serve JPEG XL to supported clients (like Safari, which actually added partial JXL support in iOS 17 and macOS Sonoma!) while falling back to AVIF, WebP, and legacy JPEG for others.
Here is how you can set up a modern, resilient image markup structure:
<picture>
<!-- Serve JPEG XL to browsers that support it (e.g., Safari 17+) -->
<source srcset="hero-image.jxl" type="image/jxl">
<!-- Fallback to AVIF for Chrome, Firefox, and Edge -->
<source srcset="hero-image.avif" type="image/avif">
<!-- Fallback to WebP for older mobile browsers -->
<source srcset="hero-image.webp" type="image/webp">
<!-- Standard legacy JPEG fallback -->
<img src="hero-image.jpg"
alt="A modern web development workspace"
loading="lazy"
width="1200"
height="630">
</picture>Automating the Pipeline with Node.js
If you want to generate these formats automatically in your build pipeline, you can leverage tools like sharp (which has experimental support for JXL via custom builds) or use the official CLI tools. Here is a simple Node.js automation script using child processes to encode your source images into both JXL and AVIF:
const { execSync } = require('child_process');
const path = require('path');
const convertImage = (source, destName) => {
const ext = path.extname(source);
const base = source.replace(ext, '');
console.log(`Processing ${source}...`);
try {
// 1. Encode to AVIF using sharp (or cjxl for JXL)
// For this example, we assume cjxl (JPEG XL encoder) and cavif are installed globally
execSync(`cjxl "${source}" "${base}.jxl" -q 85`);
console.log(`✓ Created ${base}.jxl`);
execSync(`cavif "${source}" -o "${base}.avif" --quality 65`);
console.log(`✓ Created ${base}.avif`);
} catch (error) {
console.error(`Error converting ${source}:`, error.message);
}
};
// Usage
convertImage('src/assets/hero-image.png');Where Do We Go From Here?
The JPEG XL story is a classic tech industry tale of technical excellence vs. market distribution power. On pure engineering merits, JPEG XL is arguably the best image format ever created for the web. Its ability to losslessly compress legacy JPEGs alone makes it a massive win for planetary green computing and bandwidth reduction.
However, Google’s gatekeeping of the Chromium engine means that for now, AVIF remains the pragmatist's choice for high-performance web images. But hope is not lost. Safari’s native JXL support has kept the format alive, and Firefox has left the door open for re-evaluation. If Apple and the open-source community continue to push JXL, Google may eventually be forced to capitulate and bring it back to Chrome.
What are your thoughts? Have you experimented with JPEG XL on your sites, or are you sticking with WebP and AVIF for the foreseeable future? Let me know in the comments below, or hit me up on Mastodon/Twitter!
Until next time, keep coding, keep optimizing, and never stop questioning the platforms!