JPEG XL vs. Other Image Formats: Compression and Quality

There is no image format that is smallest at the same visual quality for every kind of image. JPEG XL is especially useful for lossless workflows, progressive delivery, and reversibly recompressing existing JPEGs. AVIF can be smaller for some web-quality photographs and mixed images. WebP, JPEG, and PNG remain useful when their browser support, encoding speed, or image characteristics fit your needs.

Choose by testing representative assets at matched visual quality, then compare file size, encode and decode time, required features, and support in your target browsers. A format’s quality slider is not comparable to another encoder’s slider.

1. What JPEG XL is

JPEG XL (ISO/IEC 18181) is an image coding system with lossy and lossless modes. It also supports lossless recompression of existing JPEGs, progressive coding, HDR and wide-gamut imagery, high bit depth, transparency, animation, layers, thumbnails, and metadata. The JPEG Committee describes the format as balancing fidelity, speed, and compression ratio; its stated typical ratio of 20:1 to 50:1 is not a guaranteed result or a head-to-head comparison. JPEG Committee: JPEG XL

That range of capabilities means JPEG XL is more than a direct JPEG replacement. It may fit archival, editing, and progressive-delivery workflows even when a different format is a better choice for a particular web image.

2. JPEG XL vs. AVIF, WebP, JPEG, and PNG

Format	Where it can fit	Tradeoffs to check
JPEG XL	Lossless imagery, progressive rendering, HDR and wide gamut, alpha, animation, and lossless recompression of JPEG files.	Browser and application support is not universal. Compare encode and decode cost as well as bytes.
AVIF	Can produce smaller files for some web-quality photographs; can also perform well on images mixing sharp edges and flat areas.	Results depend on the image, encoder, settings, and quality target. Test encoding and decoding in your delivery environment.
WebP	A practical web format to include in comparisons, including when transparency or animation matters.	Do not assume it wins on size or quality. Compare it on the actual assets and browsers you support.
JPEG	Existing photo collections and compatibility-oriented delivery.	Lossy JPEG recompression normally entails another lossy encode; JPEG XL can instead losslessly recompress a JPEG while preserving its decoded image.
PNG	Lossless images and graphics where exact pixels or transparency matter.	For photographic content, compare a suitable lossy format if smaller downloads matter, while checking visual quality and alpha needs.

Mozilla’s examples illustrate why a single ranking is misleading. In its fox photo example, AVIF was 116 kB and JPEG XL 134 kB at SSIMULACRA 2 score 62.8; at score 80, they were 227 kB and 264 kB. In lossless mode on that photo, AVIF was 1.76 MB and JPEG XL 1.45 MB, while lossless WebP was 1.55 MB. On a Mozilla dashboard screenshot at score 78, AVIF was 11.6 kB and JPEG XL 23.8 kB; losslessly, AVIF was 164 kB, JPEG XL 92 kB, and WebP 96 kB. These are individual encodes, not universal outcomes. Mozilla Hacks: Intent to Ship: JPEG XL

3. Compare at matched visual quality

Build a representative corpus. Include photographs, screenshots, line art, graphics with flat color, transparency, and any HDR or wide-gamut content you actually serve. Include small and large images, and high-density assets when relevant.
Choose a visual-quality target. Encode each image with each candidate format. Tune each encoder separately until the outputs have comparable perceived quality. Do not match numeric quality settings across encoders.
Inspect difficult regions. Look at edges, text, gradients, fine texture, skin, noise, and transparency boundaries at normal display size and zoomed in. A metric can help organize results, but it does not replace inspection.
Record the operational costs. For every output, record bytes, encode time, decode time, memory if relevant, and whether metadata, color profile, animation, alpha, or progressive behavior survived as required.
Test delivery. Verify the target browsers and clients, fallback behavior, cache behavior, and the real image dimensions and density used on the page.

Keep source images and encoder versions/settings with the results so the comparison can be repeated. JPEG Committee’s free, open-source reference implementation is one starting point for JPEG XL work; actual results depend on the implementation and settings used. JPEG XL reference information

4. Quality, bytes, and performance

Visual quality: Lossy compression discards information, but equal slider values do not mean equal quality. Compare output appearance at the size and density users see. Metrics such as SSIMULACRA 2 can help match targets; always identify the metric and score when publishing comparisons.

File size: Content matters. Photographic texture, sharp text, flat fills, gradients, noise, and transparency respond differently to codecs. Lossless mode preserves image data but often produces larger files than lossy mode. A smaller file on one image says little about another.

Encoding and decoding: More compression can cost more CPU or latency, depending on encoder, settings, hardware, and image. Measure the exact pipeline. If images are encoded once and served many times, slower encoding may be acceptable; on-demand conversion may make encode time and queueing important. Decode cost matters on constrained devices and when many large images appear together.

Progressive delivery: JPEG XL supports progressive coding, which can be useful for large-image delivery. Check behavior in the specific browser and delivery path: MDN says Safari does not support progressive download of JPEG XL files. Do not infer perceived loading performance from the format feature alone.

5. Browser support and fallback delivery

Browser support is the key deployment constraint for JPEG XL. MDN’s compatibility guide is time-sensitive: its listed state includes Safari 17 and later, Chrome 145 and later behind the #enable-jxl-image-format flag, and Firefox preview releases. Those entries can change; verify stable browser versions at the time you ship. Mozilla’s August 2026 article describes intent to ship for Firefox and Chrome, which is not confirmation that a final stable release has shipped. MDN: Image file type and format guide · Can I Use: JPEG XL

Use <picture> to offer JPEG XL where supported while keeping an appropriate fallback. The browser selects the first supported source, with the img element as the fallback:

<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 lake at sunrise" width="1600" height="900">
</picture>

Provide equivalent content and suitable dimensions for each source. If using responsive variants, define appropriate srcset and sizes for each source, and verify that all versions preserve required color, metadata, animation, and transparency behavior. Keep the fallback available to clients that do not support the newer formats.

6. JPEG XL and reversible JPEG recompression

JPEG XL can recompress existing JPEG files losslessly. This can reduce storage or transfer size without changing the decoded JPEG pixels, and the JPEG can be recovered from the JPEG XL representation. This differs from decoding a JPEG and encoding it again as a lossy JPEG, which can add generation loss.

Test the archive or delivery workflow end to end: confirm that the chosen encoder uses JPEG recompression mode, retain any required metadata, and verify the recovery path before replacing originals. Do not assume a generic conversion command preserves the original JPEG reversibly; check the tool’s documented mode and output.

7. Troubleshooting

Symptom	Likely cause	What to do
JPEG XL image does not display	The browser, app, or image pipeline lacks support, or the file is served with an incorrect media type.	Check current client support, inspect the response content type and file, and provide a fallback such as AVIF, WebP, JPEG, or PNG as appropriate.
JPEG XL is larger than AVIF or WebP	The source content and settings favor another encoder, or the quality targets are not matched.	Retune for comparable visual quality and test a broader representative set. A single image is not a format-wide verdict.
The output looks worse despite a similar quality number	Quality scales and encoder defaults differ.	Compare by visual target and inspect difficult details; do not reuse one format’s slider value for another.
Conversion is too slow	Encoder settings or the workload require more processing than the pipeline budget allows.	Measure encode time separately, test less costly settings at acceptable quality, and decide whether offline encoding or caching suits the workflow.
Transparency or color looks wrong	The conversion path or target format did not preserve alpha, profile, bit depth, or color metadata as required.	Check source and output properties, encoder options, and rendering in target clients. Use a format and pipeline that preserve the requirements.
Progressive loading does not happen	The client or transport path does not support progressive JPEG XL delivery.	Verify client behavior; MDN specifically notes Safari does not support progressive download for JPEG XL. Keep a compatible alternative where progressive display is a requirement.
Users receive the wrong cached variant	Variant negotiation or cache keys do not distinguish format and responsive dimensions correctly.	Ensure the delivery layer keys or negotiates variants correctly, and test with caches both warm and cold.

8. Reliability and cost considerations

Image delivery cost includes more than bytes: encoding infrastructure, storage for variants, cache hit rate, bandwidth, client decode work, and the operational burden of supporting fallbacks all matter. Pre-encoding a controlled set can make delivery predictable; on-demand variants can reduce stored copies but add processing and cache complexity. Measure with your own traffic patterns rather than projecting from a codec example.

For reliability, keep a known-good source and fallback, validate generated assets before publishing, and monitor broken-image rates and delivery errors by format. Treat browser compatibility data as a snapshot and revisit it before changing the default served format.

9. Inspecting image-format results with screenshots

If your comparison is about how images render in a web page, capture the same page in each target browser and viewport, then compare the resulting screenshots. Screenshots are useful for checking layout, fallback selection, and visible artifacts; they do not replace byte-size, encoder-time, or decoder-time measurements.

For a local workflow, use your browser’s developer tools or automation to load each variant, wait until the image is decoded, and save screenshots at consistent viewport, device scale, and color settings. Check that the page actually selected the intended source before recording a comparison.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. It can capture a comparison page with one request; its API and options are documented at ScreenshotNeo docs.

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

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

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com/image-format-comparison' });
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', res);

Cookie banners, popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed. An MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Sign up for 1,000 free screenshots a month.

10. FAQ

Is JPEG XL always better quality than JPEG?

No. JPEG XL supports lossy and lossless modes, but quality depends on settings and the source. Its reversible JPEG recompression mode preserves the decoded JPEG image; a lossy encode is a separate choice.

Which format gives the smallest file at the same quality?

There is no universal winner. Compare your images at matched perceived quality and include lossless cases if those matter to your use.

Should I remove JPEG or WebP fallbacks?

Only after verifying that every client you support can render the replacement and that your deployment handles variants correctly. Browser support changes over time.

Can a screenshot tell me which codec is faster?

No. A screenshot helps compare rendered appearance. Measure encoding and decoding separately with a repeatable workload.