Chrome support opens another delivery option
Chrome announced on October 6, 2026, that JPEG XL decoding ships starting with Chrome 155. Google identified high-fidelity photography, lossless compression and fine-grained progressive decoding as promising uses. The company also recommended trying both JPEG XL and AVIF. Developers now have a reason to compare them on their own assets before choosing a pipeline default. Sources: Chrome for Developers
Google claims 30–50% better compression than JPEG, without guaranteeing that saving for a particular image library. Chrome uses jxl-rs, a Rust decoder, so reference-library decoding benchmarks do not measure Chrome's implementation. A useful evaluation separates format capabilities, encoder efficiency and browser presentation. Each answers a different production question. Sources: Chrome for Developers
Published size comparisons favor different formats
NoWaterProgramming tested 24 Kodak photographs at 768×512 pixels, searching encoder settings for target SSIMULACRA2 perceptual-quality scores. It used libjxl 0.11.1 at effort 7 and libavif 1.3.0 at speed 6. The other encoders were libwebp 1.6.0 at method 6 and libjpeg-turbo 3.1.3. JPEG XL produced the smallest aggregate files at both targets in the table below. Its savings against JPEG were 22.5–23.2%, below Google's headline range. Sources: Chrome for Developers, NoWaterProgramming
Table
Aggregate encoded size for 24 Kodak photographs, in bytes
| SSIMULACRA2 target | JPEG | WebP | AVIF | JPEG XL |
|---|---|---|---|---|
| 80 | 2,107,361 | 1,846,976 | 1,684,141 | 1,633,451 |
| 60 | 982,461 | 839,896 | 757,957 | 754,392 |
Jake Archibald's comparison used an M4 Pro MacBook Pro and images generally 1,598 pixels wide. His tools included avifenc 1.4.2, libjxl 0.12.0 and jixel 0.4.2, generally at maximum effort unless that increased size. AVIF beat both JPEG XL encoders on the photograph and illustration in the table below. Sources: JakeArchibald.com
Archibald also reported that equivalent JPEG XL photographs were typically 15–25% larger than AVIF at default effort. That finding uses different effort settings from the selected examples below, which generally used maximum effort unless it increased size. Neither comparison establishes a universal winner: the images, encoder versions and effort policies differ. The Kodak totals also measure encoded files, not browser transfers or Chrome decoding performance. Sources: NoWaterProgramming, JakeArchibald.com
Table
Selected image sizes from Archibald's comparison, in kB
| Image | SSIMULACRA2 target | AVIF | JPEG XL with libjxl | JPEG XL with jixel |
|---|---|---|---|---|
| F1 photograph | Approximately 70 | 41.4 | 58.4 | 46.6 |
| Illustration | Approximately 80 | 68.5 | 139.8 | 110.4 |
Encoding cost and reversible compression change the calculation
Encoding cost belongs beside file size in a production comparison. For Archibald's illustration, AVIF speed 0 saved 14–21% against its default setting while taking 35–48 times as long to encode. JPEG XL's effort documentation says higher effort can produce larger files for individual images despite improving search and quality consistency. Compare an affordable production setting with a slower setting to see whether additional computation buys useful savings. Sources: JakeArchibald.com, libjxl
Existing JPEG files offer a separate opportunity because the reference tools support reversible recompression. NoWaterProgramming reduced 30 files from 178.0 MB to 141.0 MB, saving 20.8%, and reconstructed all originals byte-for-byte. Encoding took 11.3 seconds and reconstruction took 5.6 seconds on the study's laptop. Evaluate this workflow separately because exact file reconstruction serves a different requirement from visually acceptable lossy delivery. Sources: NoWaterProgramming, libjxl
The reference encoder defaults to lossless JPEG recompression, and the decoder can reconstruct the original when given a JPEG output filename. The commands below perform a pilot round trip and compare the resulting files. Retain originals during validation and compare every pilot file before relying on the archive. Sources: libjxl
cjxl original.jpg archived.jxl
djxl archived.jxl reconstructed.jpg
cmp original.jpg reconstructed.jpgHigh dynamic range needs a separate comparison
High dynamic range, or HDR, makes metric choice especially consequential. Archibald's experimental HDR SSIMULACRA2 comparison placed default libjxl output 5–33% larger than AVIF using the perceptual quantizer transfer function. ColorVideoVDP instead placed it 28–53% smaller. Report the metric and its display assumptions alongside each result. Sources: JakeArchibald.com
AVIF supports 8-, 10- and 12-bit content, transparency, color profiles and HDR transfer-function signaling. Lossy WebP uses 8-bit color with 4:2:0 chroma subsampling, while lossless WebP uses red, green, blue and alpha channels. Use an approved standard dynamic range, or SDR, rendition for WebP in this comparison. Inspect small colored text and edges separately from photographic detail. Sources: Google for Developers, MDN
The libjxl changelog records gain-map bundle APIs in version 0.11.0. Archibald nevertheless reported that browsers did not yet handle JPEG XL gain maps. Check that time-sensitive observation against the browser and operating-system combinations being deployed. Record display model, brightness, highlight detail, banding and SDR appearance alongside file size. Sources: JakeArchibald.com, libjxl
Build a test around the production library
Build a test corpus that covers the site's actual image categories. Include skin, foliage, fabric, noise, smooth skies, screenshots, illustrations, transparent cutouts and HDR highlights. Cover thumbnails, normal responsive sizes and full-resolution photographs, with existing JPEG files in a separate reconstruction group. Publish dimensions, hashes, licenses, encoder versions, exact commands and machine configuration so later upgrades can be compared fairly.
- Separate lossy delivery, exact decoded-pixel preservation and byte-for-byte file reconstruction.
- Match perceptual quality before comparing bytes, and inspect images before revealing their sizes.
- Sweep practical and expensive effort settings, recording color and subsampling choices.
- Keep resizing, metadata policy and color preservation consistent across variants.
- Repeat browser tests on desktop and a constrained mobile device under controlled network conditions.
Record encoded bytes and actual cold-cache transfer, plus encoding wall time, CPU time, peak memory and thread count. Google's benchmark documentation distinguishes concurrent codec instances from internal codec threads and recommends ten encoding and decoding repetitions. In the browser, capture decode time, first useful paint, final paint and Largest Contentful Paint, or LCP. Use a filmstrip to inspect progressive loading, and measure LCP directly before claiming an improvement. Sources: Google
Report medians, spread and per-image outcomes alongside aggregate totals. Add an analysis weighted by actual request frequency, then subtract encoding and additional storage and cache costs from delivery savings. For mobile tests, consider libjxl's decoding-speed tiers from 0 through 4, which trade compression density or quality for faster decoding. Choose the configuration that meets the site's visual and operational requirements. Sources: libjxl
Start with a limited rollout
Begin with a limited asset class and measure how many actual requests receive JPEG XL. Expand when rendering results and delivery savings justify the additional encoding, storage and cache costs.