JPEG XL: Features, Benefits, and Browser Support
Learn what JPEG XL supports, where it can help, and the state of browser compatibility as of October 3, 2026—with practical fallback guidance.
Short answer: JPEG XL (JXL) is an image format standardized as ISO/IEC 18181. It supports both lossy and lossless encoding, can reversibly transcode existing JPEGs, and includes features such as progressive rendering, animation, transparency, HDR, and high bit depth. As of October 3, 2026, Safari support is established, while Chromium and Firefox rollouts are in transition. For websites, serve JXL only with a tested fallback such as AVIF, WebP, or JPEG.
1. What is JPEG XL?
JPEG XL is a modern raster image coding system designed for responsive web delivery and professional photography. The JPEG Committee standardizes it as ISO/IEC 18181. It combines a coding format with a box-based file format that can hold metadata such as EXIF and JUMBF, as well as data used to reconstruct an original JPEG after reversible transcoding. JPEG Committee: JPEG XL
JXL files commonly use the .jxl extension and the image/jxl media type. The format is royalty-free according to MDN; that describes the format and does not establish the terms of every decoder, service, or implementation. MDN: Image file type and format guide
2. JPEG XL features
| Feature | What it means in practice |
|---|---|
| Lossy and lossless coding | Choose smaller approximations or preserve image data exactly, depending on the workflow and encoder settings. |
| Reversible JPEG transcoding | Transcode an existing JPEG into JXL and later reconstruct that exact original JPEG. This can help reduce storage while preserving a route back to the source file. |
| Progressive coding | Encode image data so a decoder can display an approximation that improves as more data arrives. Whether users see progressive rendering depends on the browser implementation. |
| Animation and alpha | Represent animated images and transparency in the format. |
| Color and dynamic range | Support wide-gamut color, HDR, and high bit depth, useful when the source and display pipeline can preserve those properties. |
| Layers and thumbnails | Support richer image structures and embedded thumbnails. |
| Metadata boxes | Carry metadata and JPEG reconstruction information in an extensible container. |
The standard is designed for software encoding and decoding, including mobile devices, without requiring additional hardware acceleration. Actual encode and decode costs depend on the implementation, settings, device, and image. The standards body describes codec design as a tradeoff among fidelity, speed, and compression; no one setting guarantees a particular file size or speed. JPEG Committee overview
3. When JPEG XL is useful
Lossless storage and migration
JXL is worth evaluating when exact image data matters, or when you want to transcode JPEG assets while retaining the ability to restore each original JPEG exactly. Validate the conversion and restoration process against your asset pipeline before deleting source files.
Progressive image delivery
Progressive coding can make an image available in stages as data arrives. This is most useful when the decoder and delivery path actually expose that behavior. MDN says Safari does not progressively render JXL during download; it displays the image after the complete download. A format capability is not a guarantee that every browser uses it.
High-fidelity and rich image workflows
Wide gamut, HDR, high bit depth, alpha, animation, and layers make JXL relevant to workflows that need those properties. Check the entire toolchain—editor, encoder, storage, browser, and display—because support for the file format does not mean each application supports every feature. The libjxl project maintains a changing inventory of supporting software, including editors, libraries, viewers, and plugins. libjxl software support inventory
4. JPEG XL versus AVIF and WebP
There is no universal winner on file size. Results vary with content, target visual quality, encoder, settings, and whether the task is lossy or lossless. Mozilla’s 2026 comparison found AVIF smaller in its cited lossy examples and JXL smaller in its cited lossless examples. These are examples, not format-wide benchmarks. Jake Archibald, Mozilla Hacks, “Intent to Ship: JPEG XL”
| Mozilla example (2026) | Reported result | How to interpret it |
|---|---|---|
| Fox photo, SSIMULACRA 2 score 62.8 | AVIF 116 kB; JXL 134 kB | AVIF was smaller for this lossy setting. |
| Same photo, score 80 | AVIF 227 kB; JXL 264 kB | AVIF was smaller for this lossy setting. |
| Lossless version of the photo | AVIF 1.76 MB; JXL 1.45 MB; WebP 1.55 MB | JXL was smaller in this example. |
| Screenshot, score 78 | AVIF 11.6 kB; JXL 23.8 kB | AVIF was smaller for this lossy setting. |
| Lossless screenshot | AVIF 164 kB; JXL 92 kB | JXL was smaller in this example. |
When comparing formats, use representative images from your site and measure at the visual quality you need. Include photographs, screenshots, graphics with flat areas and sharp edges, and any assets that require transparency or lossless fidelity. Consider output size, encode time, decode cost, progressive behavior, and browser coverage together. Mozilla’s comparison and testing guidance
5. JPEG XL browser support (status dated October 3, 2026)
Browser support is changing, so treat this as a dated snapshot and check current compatibility before relying on it. The reviewed announcements do not confirm that Chromium or Firefox had completed stable-channel default-on rollouts by this date.
| Browser | Status in sources reviewed by October 3, 2026 | Practical guidance |
|---|---|---|
| Safari | Support is listed from Safari 17. MDN says Safari waits for the complete download rather than progressively rendering JXL. | JXL can display in supported Safari versions; keep a fallback if serving a broad audience. |
| Chrome / Chromium | MDN lists Chrome 145+ support behind the #enable-jxl-image-format flag. Chromium’s August 24, 2026 intent-to-ship says decoding would ship enabled for all users, but the announcement lists no estimated milestones. |
Do not infer a particular stable release is default-on from the intent-to-ship announcement alone. |
| Firefox | MDN describes preview-release support. Mozilla said Nightly had JXL enabled by default and a Firefox Labs checkbox was available on all channels since Firefox 152. The planned default-on rollout moved from the 157 train to the 158 train in a September 3 update. | The sources reviewed do not establish final stable-channel availability on October 3, 2026. |
Sources: MDN compatibility guide, Chromium intent-to-ship announcement, and Mozilla rollout discussion and September update.
6. Serve JPEG XL with a fallback
Use <picture> to offer JXL first and let the browser select a supported alternative. Keep the ordinary <img> as the final fallback. Make sure each file is encoded and served with the correct content type.
<picture>
<source srcset="/images/hero.jxl" type="image/jxl">
<source srcset="/images/hero.avif" type="image/avif">
<source srcset="/images/hero.webp" type="image/webp">
<img src="/images/hero.jpg" alt="A mountain landscape at sunrise" width="1600" height="900">
</picture>For responsive variants, include width descriptors and a matching sizes attribute on each source. Keep the same crop and meaningful content across formats so browser selection does not change the image’s meaning.
<picture>
<source type="image/jxl"
srcset="/images/hero-800.jxl 800w, /images/hero-1600.jxl 1600w"
sizes="(max-width: 800px) 100vw, 800px">
<source type="image/avif"
srcset="/images/hero-800.avif 800w, /images/hero-1600.avif 1600w"
sizes="(max-width: 800px) 100vw, 800px">
<img src="/images/hero-1600.jpg"
srcset="/images/hero-800.jpg 800w, /images/hero-1600.jpg 1600w"
sizes="(max-width: 800px) 100vw, 800px"
alt="A mountain landscape at sunrise" width="1600" height="900">
</picture>Rollout checklist
- Check current browser support for the browsers and versions your audience uses.
- Generate JXL and fallback files from the same approved source and compare their visual output.
- Verify the server or CDN returns the right content type, caching behavior, and variant for each URL.
- Test unsupported browsers and formats; confirm the fallback image loads and has appropriate dimensions and alternative text.
- Monitor real delivery and errors before considering any change to your default format strategy.
7. Creating and validating JXL assets
JPEG XL is a format, not a single encoder command or quality setting. Encoding options depend on the tool and version. Choose a maintained encoder or image editor that supports the required JXL features, then consult that tool’s documentation for exact flags. The libjxl project’s support inventory is a useful starting point, but it can change. libjxl software support
For each asset class, preserve the source, encode representative samples, and compare dimensions, color, transparency, animation, and metadata after decoding. For reversible JPEG transcoding, verify that the reconstructed JPEG is byte-for-byte identical to the original before adopting the workflow. Avoid assuming lossy quality values are comparable across encoders or formats.
8. Troubleshooting
| Symptom | Likely cause | What to do |
|---|---|---|
| Image does not display | The browser or version does not support JXL, the feature is disabled, or the file response is incorrect. | Confirm support in the target browser; inspect the response and MIME type; ensure a supported fallback exists in <picture>. |
| Chrome shows an image only with a flag | The tested Chromium build has support behind the experimental flag described by MDN. | Do not require users to enable a flag. Use fallbacks and verify the stable release status for your audience. |
| Firefox stable does not render it | The rollout status may differ by channel or release; the reviewed schedule placed default-on in the 158 train. | Check the installed version and current Mozilla release information, and serve a fallback. |
| Progressive display is absent in Safari | Safari does not progressively render JXL during download according to MDN. | Plan for complete-download rendering in Safari; do not use JXL progressive coding as a guaranteed loading optimization there. |
| JXL is larger than AVIF or WebP | Compression depends on the image, target quality, mode, and encoder. | Measure representative samples at acceptable visual quality. Select per use case rather than assuming one format always wins. |
| Colors or transparency differ | Color profile, bit depth, alpha handling, or a tool’s feature support changed during conversion. | Inspect the source profile and output in the actual target applications; test alpha edges and wide-gamut/HDR assets through the full pipeline. |
| Reconstructed JPEG differs | The workflow used ordinary lossy encoding or did not preserve reversible JPEG reconstruction data. | Use a tool and mode that explicitly support lossless JPEG transcoding, then compare the restored file with the original. |
| One browser picks the wrong variant | Source ordering, MIME type, responsive descriptors, or CDN content negotiation is misconfigured. | Check the selected resource in browser developer tools; align each srcset and sizes, and verify server headers. |
9. Performance, reliability, and cost
JXL may reduce storage for some lossless workflows and can progressively encode imagery, but neither property guarantees faster page loads. Measure transfer size and decode behavior on representative devices. A format that saves bytes can still affect CPU time, and fallback files can increase storage and build complexity.
For reliability, retain a widely supported fallback while browser rollout remains unsettled, validate generated files in the browsers and tools you target, and preserve original assets until reversible conversion is verified. Include the added storage and image-pipeline work in cost estimates; the cited sources do not establish a universal cost or performance advantage.
10. Inspecting a rendered page screenshot
When debugging image delivery, inspect the rendered page at desktop and mobile sizes and check which image variant the browser selected. ScreenshotNeo is a website screenshot API and MCP server from Yorker Media; it can capture a page as PNG, JPEG, WebP, or PDF. It is useful for reviewing the page’s rendered result, while browser developer tools remain the place to inspect the exact image request and response.
For an image capture endpoint example and options, see the ScreenshotNeo documentation. The product also offers full-page captures, device presets, custom viewport sizes, and CSS/JavaScript options among its features. Learn more at ScreenshotNeo.
11. FAQ
Is JPEG XL a replacement for JPEG?
It can serve new image-delivery workflows, and reversible transcoding can preserve a path back to an exact original JPEG. Browser coverage and workflow requirements determine whether it is suitable as a direct replacement for a particular site.
Does a JXL file always have a smaller size?
No. Size depends on content, encoder, settings, and whether encoding is lossy or lossless.
Can I use JXL as the only image source on a website?
Only if you have confirmed every browser and client you need to support can display it. The safer general approach during the dated rollout described here is a fallback.
Does every browser support JXL animation and progressive rendering?
No. Format capabilities and browser implementation support differ. Check the targeted browser’s current documentation and test the specific behavior you need.
Or skip the browser setup
To capture a page without installing and maintaining browser automation, make one request to ScreenshotNeo. Replace the URL with the page you want to inspect; find API details and options in the documentation.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpimport requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);ScreenshotNeo accepts cookie banners 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 are not billed, and response headers identify the page verdict and billing status. Its MCP server lets AI agents use take_screenshot, get_page_info, and capture_pdf. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.
Sign up free for 1,000 screenshots a month, with no card required.
