JPEG XL: Modern Successor to JPEG for High-Quality Raster Images

JPEG XL (.jxl) is a modern raster successor to classic JPEG, standardised as ISO/IEC 18181 in 2022. It closes three gaps at once: a lossless mode (bit-exact pixels), native HDR and 8-32 bit depth, and lossless transcoding — existing .jpg files repackage into .jxl ~20% smaller and round-trip back to a byte-identical JPEG. The format is royalty-free; libjxl is the BSD-3-Clause reference implementation. For OSM map exports JXL is the "best" alternative to PNG for huge posters: smaller files at the same quality. The caveat is reader support — Safari native, Firefox behind a flag, Chrome dropped support in 2023 — so today JXL is primarily for archives and offline viewing.

History: Google PIK + Cloudinary, ISO 18181 and the Chrome drama

JXL grew out of two late-2010s projects: Google PIK (2017) and Jon Sneyers' FUIF (Cloudinary). In 2018 JTC1/SC29/WG1 (the group behind JPEG and JPEG 2000) merged them into JPEG XL: VarDCT from PIK for lossy, modular from FUIF for lossless. The spec was published as ISO/IEC 18181 in October 2022. libjxl shipped in Linux distros and editors: Photoshop in 2024, GIMP, Krita, ImageMagick, libvips and Affinity all read and write .jxl.

In parallel came the browser drama. Chrome added JXL behind a flag in 2021; in October 2022 Google announced removal citing "insufficient interest" — despite being a PIK co-author. Cloudinary, Facebook, Adobe and Krita pushed back loudly. Chrome removed the code in 2023. Firefox keeps support behind image.jxl.enabled; Safari turned it on natively in version 17 (iOS 17 / macOS Sonoma, 2023). Elsewhere you need libjxl plus a viewer (XnView, IrfanView, geeqie).

Inside JPEG XL

.jxl is an ISOBMFF-based container (same family as MP4 and HEIF) with its own codestream, running in two modes:

• VarDCT (lossy) — from PIK. Variable-block DCT (8×8 to 256×256), XYB colour space, adaptive quantisation, ANS entropy coding. Target: beat JPEG at the same quality by ~60% file size.
• Modular (lossless) — from FUIF/FLIF. No DCT, direct pixel compression via MA-tree predictors + ANS. Files 20-30% smaller than PNG.

The killer feature is lossless JPEG → JXL transcoding: an existing .jpg converts to .jxl without re-encoding the DCT coefficients. The file shrinks ~20%, and djxl --jpeg reconstructs a byte-identical JPEG. Huge win for photo archives.

Other maxima: frames up to 1 000 000 000 × 1 000 000 000 pixels, 8/10/12/16/32-bit depth, up to 4099 channels, HDR via XYB and PQ/HLG, animation, embedded ICC, progressive rendering. The encoder is 5-10× slower than JPEG; the decoder beats JPEG 2000 but is slower than plain JPEG — CPU time traded for smaller files.

Use cases

Photo archives and DAM. Cloudinary, Smugmug and corporate DAMs can repack millions of legacy JPEGs into JXL for 20% disk savings without losing the rollback path. Adobe Lightroom CC supports JXL export since 2024.

HDR and scientific imaging. Astrophotography, medical, machine vision — anywhere 16/32-bit depth is needed without proprietary DNG/OpenEXR.

Web where Safari dominates. Apple-only services can serve JXL with PNG/WebP fallback via <picture> — noticeable traffic savings at the same quality.

Workflow in OSM2CDR

JPEG XL is post-processing on top of PNG export — we don't ship a direct exporter (no mandatory libjxl dependency in the worker), but the workflow is two commands.

Step 1: export PNG via osm2cdr. On /formats/png/ or via POST /api/render with formats=["png"], bbox and size (for posters typically 8000×6000 or 12000×9000 px). Pipeline: PostGIS → WKB fast-path → qgis_renderer → PNG. See the PNG deep-dive.

Step 2: transcode to JXL locally. Install libjxl (apt install libjxl-tools / brew install jpeg-xl) and run:

# Lossless: bit-exact, 25-30% smaller than PNG
cjxl input.png output.jxl --distance=0 --effort=7

# Visually lossless: ~60% smaller
cjxl input.png output.jxl --distance=1.0 --effort=7

--distance: 0 = mathematically lossless, 1.0 = visually lossless (default). --effort=7 balances time and ratio; archives can use 9. djxl output.jxl restored.png recovers PNG; in lossless mode pixel hashes match.

A direct jpeg_xl_exporter.py is on our roadmap; until Chrome restores support, PNG + local cjxl covers 99% of scenarios.

JXL vs PNG vs WebP vs JPEG 2000

PNG is the lossless raster standard with universal browser support; JXL compresses 20-30% better and supports HDR / high bit depth. WebP (Google, 2010) has universal support but loses to JXL on lossless efficiency and lacks HDR / lossless JPEG transcoding. JPEG 2000 (2000, wavelet-based) stayed niche due to patent history and no web support; JXL is its modern replacement.

Pick JXL over PNG when the export is for archive or print (posters, hi-res for Illustrator/InDesign) and size matters more than universal compatibility — 20-30% savings at the same quality. For HTML embedding aimed at any audience — stick with PNG/WebP.

Conclusion

JPEG XL is a technically mature, licence-clean, ISO-standardised format that was meant to be "JPEG for the next 30 years". The Chrome drama slowed its web rollout, but in archives, photo banks and the Apple ecosystem it is already the norm. For osm2cdr.ru users it's a tool for better storage of raster posters: 20-30% free disk savings at the same quality, with a fallback to PNG anytime. Try it at high resolution on /formats/jpeg-xl/ and transcode locally via cjxl.

Related

• JPEG 2000 — wavelet-based successor to JPEG for medical and archive use
• WebP — Google's modern raster format
• PNG — lossless raster and the de facto standard of the web

Sources

• ISO/IEC 18181-1:2022 JPEG XL Image Coding System — iso.org/standard/77977.html
• libjxl reference implementation (BSD-3-Clause) — github.com/libjxl/libjxl
• JPEG XL official site (JPEG Committee) — jpeg.org/jpegxl/
• Cloudinary blog: JPEG XL technical overview — cloudinary.com/blog/jpeg-xl