JPEG XL for Photographers: The Complete 2026 Workflow

For most of the last five years, JPEG XL felt like a format waiting for a room. The spec was finalized in 2022, Apple shipped it in Safari 17 in late 2023, and then everyone stood around waiting on Chrome. That wait ended with Chrome 145 in early 2026. For photographers, the practical consequence is simple: you can now ship .jxl files to clients and expect them to open in a browser tab.

This post covers the workflow I actually use: ingest from RAW, edit, export, and archive. The numbers below come from a mix of Sony A7 IV, Fujifilm X-T5, and Canon R5 files processed on a 2024 Mac Studio.

Why move now, and not a year ago

Three things changed between 2024 and 2026 that matter for a working photographer:

1. Chrome, Edge, and Opera all ship JXL decode without a feature flag.
2. Adobe Lightroom Classic added native JXL export in the 14.2 update (November 2025).
3. Capture One 17 added JXL export in its 17.1 point release, including ICC profile embedding.

That last point is the one that actually gated adoption for color-critical work. Without embedded ICC profiles, JXL was a dead end for anyone shipping to print.

Lossless re-encoding: the free win

This is the feature that sold me. Given an existing JPEG, the JXL encoder can repackage the DCT coefficients without re-compressing them. You get a smaller file and a pixel-identical result when decoded back to JPEG.

Typical savings on my archive of roughly 180,000 delivered JPEGs:

Source	Average size	JXL size	Savings
24MP Sony JPEGs (quality 95)	11.4 MB	8.1 MB	29%
40MP Fuji JPEGs (quality 90)	14.2 MB	9.9 MB	30%
45MP Canon JPEGs (quality 100)	22.8 MB	14.6 MB	36%

For a 2 TB archive that is roughly 600 GB back, with zero visual change and full reversibility. You can round-trip back to the exact original JPEG bytes whenever you need to.

The reference tool is cjxl from libjxl 0.11:

cjxl input.jpg output.jxl --lossless_jpeg=1 --effort=9

For batch work on a folder of finished deliveries, you can run this through Konvrt's batch converter in the browser without uploading anything.

Lightroom Classic export

In Lightroom 14.2 and later, JXL appears in the Export dialog under Image Format. The settings that matter:

• Quality: Lightroom's scale maps to JXL distance roughly as distance = (100 - quality) / 20. Quality 90 is distance 0.5, which is visually transparent on nearly all content.
• Effort: Default is 7. Bumping to 9 saves another 3-5% at the cost of roughly 2x encode time.
• Color Space: sRGB for web, Display P3 for Apple ecosystem deliveries, ProPhoto RGB only if your client's pipeline is genuinely 16-bit aware.

The preset I use for client gallery delivery: Quality 88, Effort 7, Display P3, resize long edge to 3000 px. A typical 45 MP export lands around 900 KB, versus 1.6-1.9 MB for the equivalent JPEG.

Capture One export

Capture One 17.1 exposes JXL under Process Recipe -> Format. The interesting control here is the distance slider directly, labeled "JXL Distance" with values from 0 (mathematically lossless) to 15. For reference:

• 0.0: mathematically lossless, 2-3x larger than visually lossless
• 1.0: visually lossless on a calibrated display
• 1.5: my default for web delivery
• 3.0: aggressive compression, visible on flat areas

Capture One also respects your output ICC profile, which Lightroom's JXL export occasionally strips on Windows builds before 14.3.

What to do with your RAW originals

JXL can store 16-bit-per-channel lossless, which makes it tempting as a DNG replacement. I do not recommend this yet. JXL lacks a metadata container as rich as DNG, camera-specific demosaic hints are not preserved, and most RAW processors will not round-trip correctly.

Treat JXL as a delivery and archive format for rendered images. Keep your RAWs as RAW.

Archive strategy

The approach I landed on after a year of testing:

• Client deliveries: JXL quality 88, Display P3, long edge 3000 px.
• Personal archive of edited JPEGs: lossless JXL re-encode (--lossless_jpeg=1).
• RAW files: untouched, kept as CR3/ARW/RAF.
• Portfolio web: JXL with JPEG fallback via the <picture> element, since Firefox still does not decode JXL as of 136.

For the fallback, the pattern is:

<picture>
  <source type="image/jxl" srcset="photo.jxl" />
  <img src="photo.jpg" alt="..." />
</picture>

If you are managing a large existing catalog, the fastest path is a lossless batch re-encode of your delivered JPEGs. You keep every pixel, shrink the archive by about a third, and the files will open on any 2026 browser. See also the AVIF vs WebP vs JPEG XL comparison if you are weighing formats against each other for a new pipeline.

Takeaway: if you have a backlog of JPEGs and a new Chrome-capable audience, lossless JXL re-encoding pays for itself immediately. Export-time JXL from Lightroom and Capture One is ready for client work as long as you verify ICC profiles end up embedded.