How many times have you run a PageSpeed Insights report only to be greeted by the dreaded warning: "Serve images in next-gen formats"? For years, our industry-standard response has been WebP. It was a massive leap forward from standard JPEG, saving us precious kilobytes on every page load. But WebP is over a decade old, and it has some glaring technical limitations, particularly when it comes to high-fidelity photography, wide color gamuts, and lossless compression efficiency.
Enter JPEG XL (codenamed .jxl). Driven by collaborative open-source experiments and standardized as ISO/IEC 18181, JPEG XL is not just another incremental improvement. It is the holy grail of image formats for the modern web. It offers better compression than AVIF, lossless re-compression of legacy JPEGs (yes, you can shrink your existing JPEG library by 20% without losing a single pixel of data), progressive decoding, and native support for HDR and wide color gamuts.
As developers, DevOps engineers, and system architects, it’s time to look seriously at the journey to JPEG XL. In this post, we’re going to dive deep into the technical architecture of JPEG XL, see how it compares to WebP and AVIF, and write some practical code to start serving it today using progressive enhancement.
The Tech Behind the Magic: What Makes JPEG XL Different?
To understand why JPEG XL is a game-changer, we have to look under the hood. Unlike WebP and AVIF, which are derived from video codecs (VP8 and AV1 respectively), JPEG XL was built from the ground up specifically for still images. This architectural choice yields several massive technical advantages.
1. XYB Color Space
Traditional image formats operate in the RGB or YCbCr color spaces. JPEG XL introduces a novel color space called XYB (derived from LMS color space). XYB is a biologically-inspired color model based on the human visual system. By aligning the data representation with how our eyes actually perceive color and brightness, the encoder can discard data that the human eye literally cannot register. This results in incredibly efficient lossy compression that looks perceptually identical to the uncompressed source.
2. VarDCT and Modular Modes
JPEG XL is a hybrid format. It supports two completely different coding modes within the same file:
- VarDCT (Variable-block-size Discrete Cosine Transform): This is used for photographic content. While legacy JPEG is locked to rigid 8x8 pixel blocks (which causes that ugly blocky pixelation on highly compressed images), JPEG XL can dynamically vary its block sizes from 2x2 up to 32x32. This allows it to preserve sharp edges while smoothly compressing flat areas like skies.
- Modular Mode: This is used for lossless compression, synthetic imagery (like charts, screenshots, and UI elements), and near-lossless encoding. It uses a modified version of Haar wavelets and predictor-based coding to outperform PNG and WebP lossless compressions by huge margins.
3. Lossless Legacy JPEG Transcoding
This is arguably JPEG XL's killer feature for backend and DevOps engineers. If you have petabytes of legacy .jpg files sitting in an AWS S3 bucket, converting them to WebP or AVIF requires decompression and re-compression. This is a lossy process that degrades image quality and alters the original pixels.
JPEG XL, however, has a built-in "lossless transcoding" feature. It can parse a standard JPEG, convert its DCT coefficients directly into JPEG XL format, and reduce the file size by 20% to 30%. The magic part? This process is completely reversible. You can reconstruct the original, byte-for-byte identical JPEG at any time. This offers immediate storage savings with absolutely zero risk of quality degradation.
JPEG XL vs. WebP vs. AVIF: The Technical Showdown
Let's look at how the primary modern image formats stack up against each other:
| Feature | WebP | AVIF | JPEG XL (.jxl) |
|---|---|---|---|
| Max Resolution | 16,383 x 16,383 px | 65,536 x 65,536 px | Over 1 billion x 1 billion px |
| Bit Depth | 8-bit only | 8, 10, 12-bit | Up to 32-bit (supports float/HDR) |
| Progressive Decoding | No | No | Yes (Fully responsive previewing) |
| Lossless JPEG Transcoding | No | No | Yes (retains bit-exact original) |
| Encode Speed | Fast | Extremely Slow | Very Fast (Multi-threaded) |
While AVIF offers incredible compression ratios, its encoding speed is notoriously slow and CPU-intensive, making on-the-fly dynamic image generation highly expensive. JPEG XL is designed to scale across modern multi-core CPUs, encoding significantly faster than AVIF while matching or beating its compression efficiency at high-quality targets.
Hands-On: Working with JPEG XL in Code
Now that we understand the theory, let's look at how we can start integrating JPEG XL into our development pipelines and web projects.
Step 1: Encoding Images on the Command Line
The reference implementation for JPEG XL is libjxl. You can install it on macOS via Homebrew:
brew install jpeg-xlTo encode an existing PNG or JPEG image to JPEG XL using lossy compression (with a target quality of 90, where 100 is visually lossless):
cjxl input.png output.jxl -q 90To losslessly transcode an existing legacy JPEG to save ~20% space without losing any data:
cjxl input.jpg output.jxlStep 2: Serving JPEG XL on the Web (With Graceful Fallbacks)
Browser support for JPEG XL is currently growing. Safari 17+ supports it natively, and it can be enabled behind flags in Firefox and Chromium-based browsers. As web developers, we should never write off a format because of partial support; instead, we use progressive enhancement via the HTML <picture> element.
The browser will evaluate the sources in order. If it supports image/jxl, it will download and render that tiny, high-fidelity file. If not, it falls back to WebP, and finally to legacy JPEG for older browsers:
<picture>
<!-- Serve JPEG XL to supported browsers (Safari, etc.) -->
<source srcset="hero-image.jxl" type="image/jxl">
<!-- Serve WebP to modern browsers without JXL support -->
<source srcset="hero-image.webp" type="image/webp">
<!-- Legacy fallback -->
<img src="hero-image.jpg" alt="Stunning landscape scenery" width="1200" height="800" loading="lazy">
</picture>Step 3: Programmatic Server-Side Negotiation
If you are building an asset pipeline, an image CDN, or an API that serves media dynamically, you can use HTTP Content Negotiation. When a browser requests an image, it sends an Accept header indicating what formats it supports.
Here is a quick Node.js/Express middleware example demonstrating how you can dynamically route requests to the best available image format:
const express = require('express');
const path = require('path');
const app = express();
app.get('/images/:filename', (req, res) => {
const filename = req.params.filename; // e.g., 'avatar'
const acceptHeader = req.headers.accept || '';
let ext = '.jpg'; // Fallback
let contentType = 'image/jpeg';
if (acceptHeader.includes('image/jxl')) {
ext = '.jxl';
contentType = 'image/jxl';
} else if (acceptHeader.includes('image/webp')) {
ext = '.webp';
contentType = 'image/webp';
}
const imagePath = path.join(__dirname, 'public', 'images', `${filename}${ext}`);
res.setHeader('Content-Type', contentType);
res.setHeader('Vary', 'Accept'); // Tell CDNs to cache based on Accept header
res.sendFile(imagePath);
});
app.listen(3000, () => console.log('Image server running on port 3000'));Why Open-Source Experiments Matter for the Future of the Web
The journey to JPEG XL is a fascinating case study in how open-source collaboration shapes our industry. The format is a combination of Google's "Pik" project and Cloudinary's "FUIF" (Free Universal Image Format). By merging these experimental codebases, the open-source community created something far greater than the sum of its parts.
While some browser vendors have been slow to ship enabled-by-default support due to competing political and video-codec interests, the technical superiority of JPEG XL is undeniable. It is already being embraced by major software suites like Adobe Photoshop, rendering engines, and camera manufacturers. As developers, advocating for open, royalty-free, and technically superior standards like JPEG XL is how we move the web forward.
Conclusion: Time to Prep Your Pipeline
JPEG XL represents a massive leap forward in image compression, performance, and fidelity. With features like lossless legacy JPEG transcoding, lightning-fast encoding speeds, and HDR support, it is poised to become the dominant image format of the next decade.
The best part? You don't have to wait to start using it. By implementing the <picture> element or server-side content negotiation, you can serve ultra-lightweight JPEG XL files to supported browsers right now, while seamlessly keeping fallbacks in place for the rest.
Over to you: Have you experimented with JPEG XL yet? Are you planning to add JXL encoding to your asset pipelines or CI/CD workflows? Let me know in the comments below, and don't forget to subscribe to "Coding with Alex" for more deep-dives into modern web infrastructure!