What Is JPEG XL? The Format Designed to Replace JPEG

JPEG XL is the first image format specifically engineered as a successor to JPEG. Not a side project from a video codec team. Not a container borrowed from another standard. JPEG XL was built from the ground up by the JPEG committee itself to address every limitation of the 1992 format while remaining backward-compatible with the billions of JPEG files already in circulation.

The format compresses photos 60% smaller than legacy JPEG at equivalent visual quality, supports both lossy and lossless modes, handles HDR and wide color gamuts, and can losslessly transcode existing JPEG files into smaller JXL files that decode back to the exact original bytes. No other format does all of this.

Here is how JPEG XL works, how it compares to JPEG, when to pick lossy vs lossless mode, and whether you should start using it now.

JPEG XL at a Glance

JPEG XL emerged from two research projects — Google's PIK and Cloudinary's FUIF — that merged in 2018 under the JPEG committee's oversight. The result is a format designed by the same standardization body that created the original JPEG, with three decades of hindsight about what a modern image codec needs.

Key Features

Lossy and Lossless Compression

JPEG XL uses two distinct coding engines. The VarDCT (Variable-size DCT) engine handles lossy compression. It extends the block-based DCT approach from JPEG with variable block sizes (up to 256x256 instead of the fixed 8x8 in legacy JPEG), better quantization strategies, and advanced entropy coding. The Modular engine handles lossless compression using prediction, palette transforms, and entropy coding — no frequency-domain transform at all.

Both engines operate within the same bitstream. You can even mix them: lossless for critical regions of an image, lossy for the rest.

Progressive Decoding

Unlike AVIF, which requires the full file before rendering, JPEG XL supports true progressive decoding by design. As data arrives, the decoder renders a low-resolution preview that sharpens incrementally. This matters for large images over slow connections — users see something meaningful within the first few kilobytes instead of a blank space.

The progressive passes in JPEG XL are more granular than progressive JPEG. The format encodes DC coefficients first (a thumbnail of the image), then progressively adds higher-frequency detail. An encoder can insert any number of intermediate quality points.

Lossless JPEG Recompression

This is the feature no other next-gen format offers. JPEG XL can take an existing JPEG file and recompress it losslessly — producing a JXL file roughly 20% smaller that decodes back to the exact original JPEG bytes, bit for bit. Not a re-encode. Not a "visually identical" approximation. The identical file, reconstructed perfectly.

For anyone storing millions of JPEG photos (cloud storage providers, photography archives, media companies), this means 20% storage savings with zero risk — you can always get the original JPEG back.

HDR and Wide Color Gamut

JPEG XL natively supports high dynamic range content with up to 32-bit floating-point precision per channel. It handles HDR transfer functions (PQ, HLG) and wide gamuts (Rec. 2020, DCI-P3, Display P3) as first-class features, not bolt-on extensions.

As HDR displays become standard on phones and laptops, a format that can store the full dynamic range captured by modern cameras matters. Legacy JPEG is locked to 8-bit sRGB — it physically cannot represent HDR content.

Animation

JPEG XL supports animated image sequences with variable frame delays, similar to animated GIF or WebP animation. The compression efficiency advantage applies to animation too: a JPEG XL animation is significantly smaller than the equivalent GIF, and the format supports full color depth and transparency per frame.

Responsive Image Features

The bitstream supports region-of-interest decoding and resolution-level extraction. A server or CDN can extract a lower-resolution version directly from a high-resolution JPEG XL file without re-encoding. This enables responsive images from a single source file — store one 4K master and serve downscaled versions by truncating the bitstream.

JPEG XL vs JPEG

The core question: how does JPEG XL improve on the format it aims to replace?

The compression gap is substantial. At quality levels typical for web delivery (SSIM 0.95-0.98), JPEG XL produces files roughly 60% smaller than JPEG. That means a 200 KB JPEG photo becomes approximately 80 KB at the same perceived quality. For bandwidth-constrained users and page performance metrics like Core Web Vitals, that gap translates directly to faster load times.

JPEG XL also decodes fast. The reference decoder is optimized for single-threaded performance and achieves decode speeds competitive with libjpeg-turbo. Unlike AVIF, which can be slow to decode on mobile devices, JPEG XL was explicitly designed with decode speed as a first-class constraint.

JPEG XL Lossless vs Lossy: When to Use Each Mode

JPEG XL supports both lossy and lossless compression within the same format, but the two modes use entirely different coding engines and serve different purposes.

Lossy Mode (VarDCT)

Lossy mode uses variable-size DCT blocks (8x8, 16x16, 32x32, or 256x256) with adaptive quantization. The encoder analyzes image content to choose optimal block sizes per region — large blocks for smooth gradients, small blocks for textured detail. The --distance parameter controls quality:

A distance of 1.0 produces files where trained observers cannot distinguish the compressed version from the original in controlled tests. For most web images, a distance between 1.0 and 2.0 hits the sweet spot between file size and visual fidelity.

Use lossy when: delivering images on the web, sharing photos, any context where a 60% file size reduction matters more than mathematical perfection.

Lossless Mode (Modular)

Lossless mode uses the Modular coding engine: prediction filters, palette transforms, and context-adaptive entropy coding. No frequency transform, no quantization, no information loss. The decoded image is bit-identical to the original.

JPEG XL lossless compression outperforms PNG by 30-40% on photographic content and remains competitive with PNG on synthetic/graphic content. For screenshots and diagrams, the Modular engine applies palette detection and edge-aware prediction that keeps file sizes tight.

Use lossless when: archiving originals, storing screenshots and diagrams, medical or scientific imaging, any workflow where the source file must be perfectly recoverable.

Lossless JPEG Recompression (A Third Option)

There is a third mode unique to JPEG XL: lossless JPEG recompression. This takes an existing JPEG file, identifies its exact DCT coefficients and Huffman tables, and re-encodes that data more efficiently. The result is roughly 20% smaller than the original JPEG, and it decodes back to the exact original JPEG file.

This is not lossy-to-lossy transcoding. The original JPEG was already lossy — the JPEG XL container just stores that same lossy data more efficiently. Think of it as a better zip for JPEG files.

Use JPEG recompression when: you have large archives of JPEG photos and want to save storage without any quality change, or when you need to serve existing JPEG content more efficiently.

Browser and Platform Support

JPEG XL support has been rolling out across platforms, though one major gap remains.

Browser Support (as of April 2026)

Safari was the first major browser to ship full JPEG XL support, reflecting Apple's broader commitment to the format across its ecosystem. Chromium-based browsers followed with native support starting at version 113.

Firefox remains the significant holdout. Mozilla removed the experimental JPEG XL flag in Firefox 113 (June 2023), citing insufficient "ecosystem interest." That decision predated Apple's and Chrome's full support. As of April 2026, Mozilla has reopened discussion but has not committed to a shipping date.

Operating System Support

Apple's platform-wide adoption is the strongest signal for JPEG XL's long-term viability. When Apple bakes a format into the OS at the Preview/Quick Look level, it tends to stick.

What the Firefox Gap Means

For web delivery, the Firefox gap is a practical barrier. Firefox holds approximately 3-6% of global browser market share (higher in Europe and among developer audiences). Serving JPEG XL on the web requires either accepting that Firefox users see a fallback format, or implementing <picture> element fallback chains:

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

This works, but it adds complexity to every image delivery pipeline. Many teams will wait for Firefox support before switching their default format from WebP or AVIF.

How to Create JPEG XL Files

cjxl (libjxl Reference Encoder)

The reference encoder is the most capable tool for creating JPEG XL files. Install libjxl 0.10.3 (the latest stable release as of April 2026) on your platform:

Ubuntu/Debian:

# Install libjxl 0.10.3 tools
sudo apt install libjxl-tools=0.10.3

macOS (Homebrew):

brew install libjxl
# Installs cjxl, djxl, and other tools

Lossy encoding:

# Encode a PNG to lossy JPEG XL (distance 1.0 = visually lossless)
cjxl input.png output.jxl --distance 1.0 --effort 7

Lossless encoding:

# Encode a PNG to lossless JPEG XL
cjxl input.png output.jxl --distance 0.0 --effort 7

Lossless JPEG recompression:

# Recompress an existing JPEG (lossless, ~20% smaller)
cjxl photo.jpg photo.jxl
# Decode back to the exact original JPEG
djxl photo.jxl restored.jpg
# restored.jpg is byte-identical to photo.jpg

The --effort parameter (1-10) controls how hard the encoder works to find optimal compression. Effort 7 is a good balance between encode speed and file size. Effort 9-10 produces marginally smaller files at significantly longer encode times.

GIMP

GIMP 2.10.38 supports JPEG XL export via the built-in JXL plugin. Open your image, then use File > Export As and change the extension to .jxl. The export dialog lets you choose between lossy (distance-based) and lossless encoding.

Squoosh

Google's Squoosh web app (squoosh.app) supports JPEG XL encoding in its codec options. Drag an image onto the page, select "JXL" as the output format, and adjust quality settings with a live preview. Useful for quick one-off conversions.

ImageMagick 7.1+

ImageMagick 7.1.1+ supports JPEG XL when compiled with libjxl. Check your build with magick identify -list format | grep JXL. If supported:

magick input.png -quality 85 output.jxl

How to View and Convert JPEG XL

Viewing JPEG XL files is straightforward on supported platforms. On macOS Sonoma or later, double-clicking a .jxl file opens it in Preview. On Windows 11, install the JPEG XL Image Extension from the Microsoft Store. On Linux, apps built against libjxl 0.10.x (such as recent builds of Eye of GNOME, gThumb, or Gwenview) render JXL natively.

For converting JPEG XL files to other formats — or converting other formats to JPEG XL — use Pixotter's image converter. Drop your files, pick the output format, and download the result. Everything runs in your browser, so your images never leave your device.

To convert via the command line, the djxl tool from libjxl decodes JXL to PNG or JPEG:

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

# Decode JPEG XL back to JPEG (if originally created from JPEG)
djxl input.jxl output.jpg

For batch workflows, combine cjxl/djxl with shell scripting or integrate with your build pipeline. If you need to compress images for web delivery and want to experiment with JPEG XL output, Pixotter handles that too.

Should You Use JPEG XL Today?

The honest answer: it depends on your use case.

Use JPEG XL now for:

• Photo archival. Lossless JPEG recompression saves 20% storage with zero quality risk. If you manage large photo libraries, this is free savings today.
• Apple ecosystem workflows. If your audience is primarily on Safari, macOS, and iOS, JPEG XL is fully supported and delivers better compression than any alternative.
• Internal asset pipelines. Design teams and content pipelines that control their own tooling can adopt JPEG XL as a master format, exporting to JPEG/WebP/AVIF for delivery as needed.
• Print and professional photography. The combination of lossless compression, HDR, wide gamut, and high bit depth makes JPEG XL the most capable archival format available.

Wait on JPEG XL for:

• General web delivery. Until Firefox ships support, you need fallback chains (<picture> with AVIF and JPEG sources). For most teams, WebP or AVIF remain more practical as the primary web format because they work everywhere.
• Social media uploads. No major social platform accepts .jxl uploads. Images get re-encoded to JPEG or WebP on upload regardless of source format.
• Email. Email clients do not render JPEG XL. Stick with JPEG or PNG for email imagery.

The trajectory

Browser support is expanding, not contracting. Apple's OS-level commitment, Chrome's native support, and the format's technical superiority over both WebP and AVIF on most metrics suggest JPEG XL will be a dominant web format once Firefox closes the gap. Building familiarity with the format now — learning the encoder, testing compression ratios, evaluating it for your specific content — positions you well for the transition.

FAQ

Is JPEG XL the same as JPEG?

No. JPEG XL is a completely new format with a different compression algorithm, different file structure, and different capabilities. The "JPEG" in the name refers to the standards body (Joint Photographic Experts Group) that created both formats. JPEG XL files use the .jxl extension and the image/jxl MIME type. They are not backward-compatible with JPEG decoders, though JPEG XL can losslessly transcode JPEG files into its own format and back.

Can JPEG XL replace PNG?

Yes, for most use cases. JPEG XL lossless mode compresses 30-40% smaller than PNG for photographic content, supports transparency, and handles both photographic and graphic content. PNG remains useful when you need guaranteed universal support (every browser, every tool, no exceptions) or when working with legacy systems that cannot process JXL files.

Is JPEG XL better than AVIF?

JPEG XL and AVIF are competitive on lossy compression quality, with JPEG XL holding an edge at higher quality settings and AVIF performing well at lower bitrates. Where JPEG XL clearly wins: progressive decoding (AVIF has none), lossless JPEG recompression (AVIF cannot do this), encoding/decoding speed, and maximum image dimensions. Where AVIF wins: broader browser support today (Firefox supports AVIF but not JPEG XL). For a deeper comparison of next-gen formats, see WebP vs AVIF.

Is JPEG XL royalty-free?

Yes. The JPEG XL standard is published as ISO/IEC 18181, and the reference implementation (libjxl) is released under the Apache 2.0 license. The format was explicitly designed to be patent-free and royalty-free, similar to WebP and AVIF.

Does JPEG XL support transparency?

Yes. JPEG XL supports a full alpha channel with either lossy or lossless compression. You can have a lossy image with a lossless alpha channel, which is useful for product photos on transparent backgrounds where the edges need to be pixel-perfect.

How much smaller is JPEG XL than JPEG?

At equivalent visual quality (measured by SSIM, VMAF, or Butteraugli), JPEG XL produces files approximately 60% smaller than legacy JPEG for photographic content. The exact ratio depends on the image content and quality target. At very high quality settings (near-lossless), the gap widens further because JPEG's fixed 8x8 blocks become increasingly inefficient.

Why did Chrome remove JPEG XL and then add it back?

Chrome initially added JPEG XL support behind a flag in Chrome 91 (2021), then removed it in Chrome 110 (February 2023), citing low usage and the availability of AVIF and WebP. After significant community pushback and Apple's decision to fully support the format across its platforms, the Chromium team revisited the decision. JPEG XL support returned as a native feature (no flag required) in Chrome 113 (May 2023).

Can I convert JPEG to JPEG XL without losing quality?

Yes, and this is one of JPEG XL's defining features. The lossless JPEG recompression mode takes an existing JPEG file, identifies its exact internal structure (DCT coefficients, Huffman tables, quantization tables), and re-encodes that data roughly 20% more efficiently. The resulting JXL file decodes back to the byte-identical original JPEG. No additional quality loss occurs. You can do this with a single command: cjxl photo.jpg photo.jxl.