Chrome 145 quietly shipped something big: a native JPEG XL decoder. After dropping JXL support in 2022 and years of community pushback, Google reversed course. JXL is now viable in production.
What changed
Before Chrome 145, JPEG XL had only Safari support (~14%). Now with Chrome on board, you're looking at 70%+ coverage overnight. Firefox has JXL in nightly builds. Edge follows Chrome. The holdout is older Chrome versions.
Why JXL is different from AVIF and WebP
| AVIF | WebP | JPEG XL | |
|---|---|---|---|
| Compression vs JPEG | ~50% | 25-34% | 35-55% |
| Encode speed | Slow | Fast | Fast |
| Lossless | Yes | Yes | Yes |
| Progressive decode | No | No | Yes |
| Lossless JPEG recompression | No | No | Yes |
The lossless JPEG recompression is unique — you can transcode existing JPEGs to JXL with zero quality loss and ~20% size reduction. No other format can do this.
Should you use JXL today?
For new projects: yes, with a JPEG fallback. The <picture> element handles this cleanly:
<picture>
<source srcset="image.jxl" type="image/jxl">
<source srcset="image.avif" type="image/avif">
<img src="image.jpg" alt="...">
</picture>
For existing projects: wait 6-12 months until Chrome 145+ penetration is high enough.
Tooling support in 2026
The weak point is still encoder tooling. Lightroom and Photoshop don't export JXL natively yet. For now the options are:
-
cjxlCLI (libjxl reference encoder) - ImageMagick 7.1+
- libvips 8.13+
- Online converters like Convertify for quick testing
Bottom line
JXL won't replace AVIF for pure compression use cases. But for archival, lossless JPEG migration, and high-quality photography workflows — it's now the best option available in a browser.
The next 12 months will tell if the ecosystem catches up.
Top comments (0)