JPEG XL Progressive Images: A Guide for the Web

Progressive JPEG XL can let a browser display an image before the entire file has downloaded, then refine it as more data arrives. Whether visitors actually see that progressive rendering depends on the browser and the encoded file. JPEG XL support is not universal, so serve it with an alternative format and measure the results on your own images.

JPEG XL is a raster image format standardized as ISO/IEC 18181. It supports lossy and lossless compression, progressive coding, HDR, transparency, animation, and other capabilities. Its progressive coding is useful when an early preview matters, but it does not guarantee a visible preview in every browser. The JPEG Committee’s overview describes the format and its design tradeoffs.

1. What does progressive JPEG XL mean for a web reader?

With progressive coding, a decoder can produce successively more complete renderings as image data arrives. A reader may see a rough version first, followed by a clearer image as the download continues. This differs from a non-progressive image that generally becomes visible only once enough of the file is available for its decoding path.

The practical experience depends on three things: the browser’s decoder, whether the particular JPEG XL file is progressively decodable, and the network and rendering conditions. Mozilla describes progressive rendering as the image rendering while it downloads; its Firefox Nightly example shows a preview becoming clearer as bytes arrive. That behavior should not be assumed across all browsers.

2. Browser support and the progressive-loading caveat

Browser support is evolving, so check current support before deployment. The support summary in MDN’s image-format guide, accessed October 3, 2026, reports Safari 17 and later support, Chrome 145 and later support behind the #enable-jxl-image-format flag, and Firefox support in preview releases. MDN also says Safari does not progressively download JPEG XL: a supported Safari browser can display the image after the complete download without showing it progressively as it arrives.

These version details are time-sensitive. Recheck MDN and test the browsers and devices your audience uses before publishing or changing production delivery. Do not treat a browser’s ability to decode JPEG XL as proof that it supports progressive download.

There is also a file-level caveat. A 2024 WebKit bug report described a sample created with cjxl input.jpeg output.jxl --progressive_dc=1 that did not progressively decode in the reporter’s tested Safari context. The report is a dated implementation observation, not a universal rule about the format or a current compatibility table. It is a reminder to test your actual files and target browsers.

3. Serve JPEG XL with a fallback using HTML

Use <picture> to offer JPEG XL and a fallback. The browser can select a source whose declared type it supports; otherwise it uses the nested <img> source.

<picture>
  <source srcset="/images/hero.jxl" type="image/jxl">
  <source srcset="/images/hero.avif" type="image/avif">
  <img
    src="/images/hero.jpg"
    alt="A mountain lake at sunrise"
    width="1600"
    height="900"
  >
</picture>

Here JPEG is the final fallback, with AVIF offered before it. You can instead use WebP or another suitable format as your fallback. Keep the alternative text accurate for the actual image, and provide intrinsic dimensions to help the browser reserve layout space. WebKit’s Safari 17 article gives a JPEG XL plus JPEG example and explains this progressive-enhancement approach; MDN also recommends <picture> for alternatives.

The JPEG XL media type is image/jxl and the file extension is .jxl. Ensure your server or CDN returns the right content type for JXL assets. If you use a CDN image transformation, verify that it preserves the chosen format and serves the intended fallback URLs.

4. Encode and verify a progressive JPEG XL file

The research sources identify cjxl from libjxl as an implementation tool. The WebKit bug report shows this command form for creating a sample with progressive DC enabled:

cjxl input.jpeg output.jxl --progressive_dc=1

This is an example of an encoder option used in that report, not a promise that every output file will progressively render in every browser. Encoder controls and defaults may vary by libjxl version. Consult the documentation for the version you install, then inspect the output and test it in the browsers you intend to support.

Choose representative originals from your site, including photographs, screenshots, graphics with sharp edges, and images that need transparency or lossless fidelity.
Encode each candidate at the quality or lossless settings appropriate to that image and your audience.
Check the generated file’s format, dimensions, file size, and visual quality. Confirm the server sends Content-Type: image/jxl.
Load the file through your production delivery path in supported browsers. Check whether it appears progressively, whether it appears only after download, and whether the fallback is selected elsewhere.
Compare the encoded results with your AVIF and fallback versions at comparable visual quality. Record both file sizes and any encoding or decoding cost that matters to your pipeline.

5. Compare JPEG XL and AVIF by workload

There is no universal winner. Compare formats using your own assets and the quality settings that make sense for your users. Consider browser support, progressive rendering implementation, encoded size at comparable visual quality, lossless size and fidelity, image content, and encode/decode speed. The JPEG Committee identifies tradeoffs among fidelity, encoding and decoding speed, and compression ratio.

Workload or requirement	What to evaluate
Photographs at web quality	Compare perceived quality and size at matched quality targets. Mozilla’s examples show AVIF smaller in its two cited lossy comparisons; this is not a guarantee for other images.
Lossless images	Compare exact fidelity and lossless output size. Mozilla’s cited fox and screenshot examples show JPEG XL smaller than AVIF in those lossless cases, not universally.
Progressive preview matters	Test actual browser behavior and actual encoded files. Support for decoding does not establish support for progressive display.
Screenshots, diagrams, or sharp edges	Include these content types in your sample set. Results can differ from photographs, so do not infer from a single image category.
Production encoding pipeline	Measure encode and decode time, operational constraints, format support, fallback delivery, and resulting payload size.

For context, Mozilla’s August 2026 article reports these selected measurements, not universal benchmarks:

Fox image at SSIMULACRA 2 score 62.8: AVIF 116 kB; JPEG XL 134 kB.
Fox image at SSIMULACRA 2 score 80: AVIF 227 kB; JPEG XL 264 kB.
Fox image, lossless: AVIF 1.76 MB; JPEG XL 1.45 MB.
Screenshot at SSIMULACRA 2 score 78: AVIF 11.6 kB; JPEG XL 23.8 kB.
Screenshot, lossless: AVIF 164 kB; JPEG XL 92 kB.

These examples support testing by workload, not claiming that one format always compresses better. Mozilla’s recommendation is to test representative imagery from the site.

6. Measure performance and reliability in production

Progressive rendering can improve perceived loading when a browser displays a useful preview before the full transfer completes. It does not automatically reduce total bytes or make a page faster. Measure the user-visible result alongside payload size and decode behavior.

Performance: compare transfer size, time until the image first appears, time until it reaches full quality, and decode/encode costs. Use the same images and quality targets when comparing formats.
Reliability: keep a tested fallback in the markup, verify MIME types and CDN behavior, and exercise the actual files in the browsers you support.
Cost: account for storage of multiple format variants, encoding compute, image delivery bandwidth, and operational complexity. The cited research does not provide a universal cost or speed benchmark.
Rollout: begin with a representative subset, retain the fallback, and expand only after confirming visual quality and browser behavior.

7. Troubleshooting common JPEG XL web issues

Symptom	Likely cause	Fix
Image does not display	The browser lacks JPEG XL support, the source URL is wrong, or the server/CDN returns an incorrect response.	Confirm the file URL and response, serve a fallback with `<picture>`, and verify the JXL MIME type is `image/jxl`.
Image displays only after the download completes	The browser can decode JPEG XL but does not implement progressive download, or the file is not progressively decodable.	Do not promise progressive rendering to all readers. Test the file in target browsers and retain the fallback.
Progressive option appears to have no effect	Encoder behavior is version-dependent, the output may not be suitable for progressive decoding, or the browser path does not support it.	Check the installed encoder’s documentation and generated file, then test in a browser known to implement the behavior. Treat the WebKit report as a dated example, not a definitive format rule.
Fallback never appears	The `<source>` type may be missing or wrong, or browser support detection may choose a source whose fetch then fails.	Declare `type="image/jxl"` accurately, validate all URLs and responses, and test failure behavior with the production markup and delivery path.
JXL works locally but not through the CDN	The CDN may not serve the file as JXL, may rewrite URLs, or may return a cached response with unexpected headers.	Inspect the production response headers and body, configure the asset type correctly, and invalidate or update the affected cache entry.
JXL is larger than AVIF or JPEG	Compression results depend on content, settings, and quality target.	Compare representative images at matched visual quality and choose per workload; do not assume a universal size advantage.

8. Or skip the browser setup

If your task is to capture a web page as an image rather than build a browser-based image pipeline, ScreenshotNeo is a website screenshot API and MCP server. One GET request returns a PNG, JPEG, WebP, or PDF. Its clean-shot workflow accepts cookie or consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits cost nothing, and response headers identify the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. Plans include 1,000 shots per month free with no card, and paid plans start at $5 for 3,000 shots.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

See the ScreenshotNeo API documentation for request details. Sign up for 1,000 free screenshots a month with no card.

9. FAQ

Does “progressive” mean the file is split into separate image files?

No. Progressive coding means a decoder can refine a rendering as more coded image data arrives; it does not require separate image files for each quality level.

Can I remove the fallback once Safari supports JPEG XL?

Keep a fallback unless your audience and deployment requirements justify dropping it. Support remains non-universal in the cited MDN summary, and support details can change.

Should I convert every image to JPEG XL?

No. Benchmark a representative set from your site against the formats you already serve, using quality settings suited to the content and audience.