JPEG XL: What It Is and How It Affects Website Images

JPEG XL (JXL) is a standardized raster image format that supports lossy and lossless compression, progressive coding, animation, transparency, HDR, wide color gamut and high bit depth. It can reduce file sizes in some workflows, show an image before its full download completes, and losslessly recompress an existing JPEG so the exact original JPEG bitstream can later be reconstructed.

It is not automatically smaller than AVIF or WebP, and browser support and feature support vary. If you want to serve JXL on a website, use a <picture> element with a fallback, compare formats on representative images at your target quality, and verify support in the stable browsers your audience uses.

1. What JPEG XL is

JPEG XL is a raster image coding system and file format standardized as ISO/IEC 18181. The JPEG standards family describes lossy and lossless encoding, lossless recompression of existing JPEGs, and a container that can carry metadata. Its feature set includes alpha transparency, animation, layers, thumbnails, progressive coding, HDR, wide color gamut and high bit depth. JPEG Committee overview

A JXL file can be a bare codestream or use an ISO-BMFF-based box container. The container can hold metadata such as Exif, XMP and JUMBF. Library of Congress format description

Lossless JPEG recompression is reversible

In this mode, JPEG XL stores an existing JPEG in a way that allows the original JPEG bitstream to be reconstructed exactly. That differs from decoding the JPEG to pixels and encoding those pixels as a new lossy image: the latter does not preserve the original JPEG file data for exact reconstruction. This can be useful for archival or delivery workflows that want smaller storage while retaining the ability to recover the source JPEG. JPEG Committee overview · Library of Congress

2. What JPEG XL can change on a website

Transfer size and visual quality

JXL can make an image smaller than JPEG in some workflows, but there is no format that wins every comparison. Results depend on the source image, encoder, settings, visual quality target and whether the output is lossy or lossless. Do not infer site-wide savings from a single file or a codec feature list.

Mozilla’s August 24, 2026 comparison illustrates the tradeoff for its samples. For a photographic image at SSIMULACRA 2 score 62.8, its AVIF was 116 kB and JXL 134 kB; at score 80, AVIF was 227 kB and JXL 264 kB. In the lossless comparison, AVIF was 1.76 MB, JXL 1.45 MB and WebP 1.55 MB. A separate screenshot example showed a similar pattern. These are examples from Mozilla’s chosen images and settings, not a general benchmark or a prediction for your assets. Mozilla’s JPEG XL and AVIF comparison

WebKit’s 2023 Safari 17 announcement said recompressing existing JPEGs as JXL could reduce size by an average of 20% without data loss, and encoding from an original could produce files up to 60% smaller than JPEG. Those are vendor-published claims, not guaranteed savings for a particular site or a fresh independent benchmark. WebKit’s Safari 17 announcement

Progressive display

Progressive coding lets a browser display a recognizable approximation while the image is still downloading. This can improve perceived loading for large images or slow connections, though the result depends on the encoding and browser implementation. Mozilla’s article describes recognizing the subject of a 135 kB image after only a few kilobytes have arrived; that is a specific example, not a guarantee for every image. Mozilla’s comparison

Support for the format does not necessarily mean support for every feature. Mozilla’s 2026 article describes progressive rendering in its Firefox implementation and says Safari’s implementation lacks it, despite Safari’s earlier JXL support announcement. Check current browser behavior if progressive display is a requirement. Mozilla · WebKit

3. JPEG XL browser support and fallback strategy

Browser compatibility changes over time, and published summaries can disagree. In its August 24, 2026 article, Mozilla described its Firefox implementation, said Chrome also intended to ship, and characterized Safari support as partial. MDN’s living image-format guide summarizes JXL support as Safari, Chrome behind a flag, and Firefox Nightly. These are different snapshots and descriptions; neither should be treated as a permanent statement about all current stable releases. Recheck stable browser versions before deploying and use your own audience’s browser data to set the fallback policy. Mozilla, August 2026 · MDN image format guide

The practical pattern is to offer JXL as a typed source inside <picture>, then provide a normal <img> fallback. Browsers that do not select the JXL source use the fallback. A plain <img> does not define alternate format sources. WebKit’s example · MDN: picture element

<picture>
  <source srcset="/images/hero.jxl" type="image/jxl">
  <img src="/images/hero.jpg"
       alt="A hiker looking across a mountain valley"
       width="1600" height="900">
</picture>

Keep the fallback available and valid. Set intrinsic width and height (or an aspect ratio in CSS) to reserve layout space. For responsive delivery, provide matching dimensions and crops for each format candidate:

<picture>
  <source
    type="image/jxl"
    srcset="/images/hero-800.jxl 800w, /images/hero-1600.jxl 1600w"
    sizes="(max-width: 800px) 100vw, 800px">
  <img
    src="/images/hero-800.jpg"
    srcset="/images/hero-800.jpg 800w, /images/hero-1600.jpg 1600w"
    sizes="(max-width: 800px) 100vw, 800px"
    width="1600" height="900"
    alt="A hiker looking across a mountain valley"
    loading="lazy">
</picture>

Use loading="lazy" for below-the-fold images, not for the page’s likely largest-contentful or hero image. Ensure the JXL and fallback candidates describe the same visual content and are served with the correct media type. If a content delivery layer negotiates formats automatically, verify its cache varies correctly by the format negotiation header so one browser does not receive a format it cannot decode.

4. Choosing between JPEG XL, AVIF and WebP

Consideration	JPEG XL	AVIF / WebP
Lossy photographic size	May be competitive; measure at the quality users accept.	Mozilla’s cited lossy samples had smaller AVIF files than JXL at the compared quality points. This does not establish a universal winner.
Lossless size	Was smaller than AVIF and WebP in Mozilla’s illustrated lossless examples.	Can win on other images or encoder settings; test your content.
Progressive display	Supports progressive coding; browser implementation differs.	Mozilla describes AVIF as having basic progressive rendering support.
Reversible JPEG workflow	Can preserve enough information to reconstruct the exact original JPEG bitstream.	Not the same workflow highlighted for JXL in the cited sources.
Compatibility	Version and feature support need verification; serve a fallback.	Choose based on the stable browser versions and delivery paths your audience uses.

Mozilla’s editorial summary says JXL stands out for lossless imagery, progressive rendering and further compressing JPEGs without quality loss, while AVIF excels at web-quality photography and images with sharp edges and flat surfaces. Treat that as Mozilla’s comparison, then validate with your own assets. Mozilla’s article

5. A practical evaluation workflow

Choose representative assets. Include photographs, screenshots, illustrations, transparent images and any unusually large or high-detail files. A codec can behave differently across these classes.
Set the visual target first. Compare at a quality level that looks acceptable at the real display size. Include lossless cases only where exact pixel preservation is needed.
Generate matched variants. Use your normal production pipeline to create JXL and the fallback formats at corresponding dimensions and crops. For JPEG archival workflows, separately evaluate the reversible recompression path.
Compare decoded appearance and bytes. Record file size and inspect images at actual rendered dimensions, including text edges, gradients, texture, transparency and banding. Avoid judging only by file extension or encoder quality number; quality scales differ.
Test actual browser behavior. Check stable browser versions relevant to your visitors, including fallback selection and any progressive behavior you depend on.
Roll out with a fallback and monitor. Watch transfer bytes, image failures and layout behavior. Keep the previous asset pipeline available until the new path is verified.

6. Performance, reliability and cost considerations

Performance

Smaller files reduce transferred bytes only when the selected format is supported and the image is actually requested. Compare total page bytes and loading behavior, not a single asset in isolation.
Progressive rendering may improve perceived display, but does not reduce the final bytes by itself.
Responsive dimensions often matter as much as codec selection: avoid sending a full-resolution original to a small viewport.
Retain width and height to prevent layout shifts, and lazy-load only images below the initial viewport.

Reliability

Keep an established fallback in the markup until the audience’s browser support and image pipeline are verified.
Ensure every JXL asset has a corresponding fallback and that deployment does not leave stale or missing variants.
Validate content types, cache keys and CDN transformations. A cached JXL response must not be served to a client that selected a fallback format.
For a critical hero image, check it on the exact stable browser builds and network paths used by your audience.

Cost

JXL can reduce bandwidth or storage costs when it produces smaller delivered files, but encoding, maintaining variants, cache storage and operational complexity also have costs. Estimate using your traffic-weighted image set and actual delivery charges. Avoid assuming savings based on Mozilla’s or WebKit’s samples; they are not measurements of your site.

7. Troubleshooting

Symptom	Likely cause	What to check or fix
Image is blank or broken in a browser	The browser build does not support JXL, or the delivered file is invalid.	Confirm the `<picture>` includes a valid fallback and test the JXL file with a decoder or browser known to support it.
The browser keeps showing the fallback	The browser may not support JXL, the source type may be wrong, or the source URL may fail.	Check stable browser support, use `type="image/jxl"`, inspect the network request and verify the asset path.
JXL works in one browser but a feature is missing in another	Format support does not guarantee identical feature support.	Verify the specific feature, such as progressive rendering, against the browser implementation and version.
File is larger than AVIF or WebP	Compression results depend on the source, encoder and quality target.	Compare representative images at matched visual quality; use the format that best fits each delivery path.
Images cause layout shifts	Intrinsic dimensions or aspect ratio were not reserved.	Add width and height to the fallback image or reserve the aspect ratio in CSS.
Some users receive an undecodable image after CDN caching	The cache may be reusing a response across clients with different format support.	Inspect content negotiation and cache variation, or use explicit `<picture>` source URLs.
Transparency or color looks different	Conversion settings, color profiles, alpha handling or browser rendering differ.	Inspect the source and decoded output with the intended color profile and alpha; compare at the actual display size.

8. Capture and inspect how a page uses images

When checking a page’s visual result across formats or breakpoints, a full-page screenshot can make layout changes, missing assets and fallback behavior easier to review. ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. Its API can capture a page as PNG, JPEG, WebP or PDF; the MCP tools include take_screenshot, get_page_info and capture_pdf. It is useful for visual review, but it does not replace checking format decoding in the target browser.

For information about ScreenshotNeo, see ScreenshotNeo.

Or skip the browser setup

Use ScreenshotNeo’s one-call API to capture the page you want to inspect. See the ScreenshotNeo API documentation for options.

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

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', new Uint8Array(await res.arrayBuffer()));

Cookie and consent banners, newsletter popups and chat widgets are removed before the capture; each cleanup step can be turned off.
Bot checks, blank pages, timeouts, failed loads and cache hits cost nothing; response headers report the page verdict and billing status.
An MCP server lets AI agents use screenshot, page-info and PDF capture tools.
The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

9. Frequently asked questions

Is a JXL file the same as a JPEG?

No. JXL is a separate format. It can, however, store an existing JPEG in a reversible recompression mode that allows reconstruction of the exact original JPEG bitstream.

Does JPEG XL always make images smaller?

No. It depends on the image, encoding mode, quality target and comparison format. Measure your own files.

Should I replace every JPEG with JPEG XL?

Not without measuring and checking browser support. Serve a fallback and adopt it where the byte savings, workflow or progressive behavior justify maintaining the variant.

Does JPEG XL support animation and transparency?

Yes. The format feature set includes animation and alpha transparency, alongside HDR, wide color gamut and high bit depth. Browser and tool support for individual features can vary.

Recommendation

Try JPEG XL when lossless delivery, reversible JPEG recompression or progressive display fits your workflow. Compare it with AVIF and WebP on representative images at the quality your site needs, and deploy through <picture> with a fallback while browser support remains version-dependent.