Reference Formats
JPEG XL
A royalty-free codec (ISO/IEC 18181) offering both lossy and lossless modes, high bit depth, and lossless JPEG transcoding, built as a unified successor to JPEG, PNG and GIF.
Extension
.jxl
Full name
JPEG XL Image Coding System
Introduced
Bitstream frozen October 2021; ISO/IEC 18181 published in parts across 2021–2022
Vendor
JPEG committee (ISO/IEC JTC 1), from technology developed by Google and Cloudinary
What is inside the container
JPEG XL combines a lossy VarDCT mode for photographic content with a lossless Modular mode, supports up to 32-bit float samples for HDR and up to 4,099 channels (CMYK, alpha, spot colors), and can losslessly repackage an existing JPEG into a smaller .jxl file that reconstructs byte-for-byte. The container natively supports EXIF, XMP, JUMBF boxes and full ICC profile embedding, giving it the richest metadata model of any format in this list on paper.
How to open it
For archives
Too young for DAM master duty as of 2026: while its lossless mode and lossless-JPEG-transcode capability are technically strong, Chrome and Firefox still ship it disabled by default, and archival-scale tooling and long-term format stability aren't proven yet. Use it selectively for space-efficient lossless repackaging of JPEG-derived assets, but keep TIFF, JPEG 2000, or RAW as the durable master until browser and ecosystem support solidify.
JPEG XL grew out of two independent research efforts — Google’s Pik codec and Cloudinary‘s FUIF — which the JPEG committee merged into a single project in January 2019. The goal was to fix JPEG’s aging limitations (8-bit-only color, no alpha channel, poor efficiency at high resolution) while also unifying the fragmented landscape of lossy, lossless, and animated formats competing to replace it: WebP, AVIF, and HEIC. The bitstream froze in October 2021, with the ISO/IEC 18181 standard published across several parts through 2022.
JPEG XL’s adoption story has been unusually turbulent for a format this technically capable. Google shipped it experimentally in Chrome from version 91 through 109, then removed it in Chrome 110 (February 2023), citing insufficient ecosystem interest — a decision that stalled web-facing adoption for years even as Apple added default support in Safari 17 later that same year. As of 2026 only Safari renders JPEG XL out of the box; Chrome and Firefox both have working decoders sitting behind experimental flags, with Google signaling a possible default-on shift in the second half of the year.
For a DAM, JPEG XL is currently a format to track rather than rely on. Its ability to losslessly re-encode an existing JPEG into a meaningfully smaller file — and reconstruct the exact original bytes on demand — is genuinely useful for shrinking storage on JPEG-heavy archives without any quality loss, and its native EXIF/XMP/ICC support means metadata survives the round-trip. But because most browsers still can’t render it without a user manually flipping a flag, it is not yet safe as a delivery/preview format in a DAM’s public-facing pipeline; treat it as an efficiency layer under the hood, not a replacement for JPEG or TIFF in day-to-day workflows.
Frequently asked
Is JPEG XL ready to serve as a DAM archival master in 2026?
Not yet. While its lossless mode and lossless-JPEG-transcode capability are technically strong, Chrome and Firefox still ship JPEG XL disabled by default, and archival-scale tooling and long-term format stability aren't proven. Keep TIFF, JPEG 2000, or RAW as the durable master for now.
Which browsers support JPEG XL natively?
Only Safari, since version 17 in 2023. Chrome and Firefox both have working decoders, but as of 2026 they remain gated behind experimental flags rather than enabled by default.
Can JPEG XL losslessly repackage an existing JPEG file?
Yes — JPEG XL can losslessly re-encode an existing JPEG into a meaningfully smaller .jxl file that reconstructs the exact original bytes on demand, which is useful for shrinking storage on JPEG-heavy archives without any quality loss.
What metadata does the JPEG XL container support?
JPEG XL natively supports EXIF, XMP, JUMBF boxes, and full ICC profile embedding, giving it the richest metadata model of any format in this comparison on paper.
Why did JPEG XL adoption stall on the web?
Google shipped it experimentally in Chrome from version 91 through 109, then removed it in Chrome 110 (February 2023), citing insufficient ecosystem interest — a decision that stalled adoption even as Safari added default support later that same year.
What can JPEG XL do that JPEG cannot?
JPEG XL adds a lossless Modular mode, up to 32-bit float samples for HDR, and support for up to 4,099 channels (CMYK, alpha, spot colors) — all beyond what baseline JPEG's 8-bit design allows.
Is JPEG XL safe to use in a DAM's public-facing delivery pipeline?
Not yet. Because most browsers can't render it without a user manually enabling a flag, JPEG XL isn't currently safe as a delivery or preview format for a general audience.
What's a practical DAM use for JPEG XL today?
Treat it as an efficiency layer under the hood — for example losslessly repackaging JPEG-derived assets to save storage — rather than as a replacement for JPEG or TIFF in day-to-day ingest and delivery workflows.
Sources
- JPEG XL's bitstream was frozen in October 2021, with ISO/IEC 18181 parts published through 2022. checked 2026-08-07 — ISO/IEC 18181-2 (File format)
- JPEG XL originated from Google's Pik codec and Cloudinary's FUIF, merged by the JPEG committee in January 2019. checked 2026-08-07 — Google Open Source Blog: Journey to JPEG XL
- Chrome removed JPEG XL support in Chrome 110 (Feb 2023); Safari 17 added full support later that year. checked 2026-08-07 — Phoronix: JPEG XL Possible Chrome Return
- JPEG XL supports native EXIF and XMP boxes plus lossless transcoding of existing JPEG files. checked 2026-08-07 — libjxl format_overview.md