JPEG XL: Benefits, Drawbacks, and Browser Support

JPEG XL (JXL) is a modern image coding system that supports lossy and lossless encoding, progressive rendering, animation, transparency, HDR, and lossless recompression of existing JPEGs. Its strongest reasons to consider it are progressive delivery and the ability to recover an original JPEG exactly after recompression. Its main web drawback is uneven browser support: check the browsers your audience uses and serve a fallback where JXL decoding is unavailable.

There is no universally smallest format. JPEG XL, AVIF, and WebP can each win depending on the image, encoding settings, and target quality. Treat file-size comparisons as measurements for your own images, not as a property guaranteed by the format.

What JPEG XL is

JPEG XL is standardized as ISO/IEC 18181. It is designed for web delivery and professional photography, with both lossy and lossless modes. It can also losslessly recompress a JPEG and later reconstruct the exact original JPEG bitstream, which can help when migrating or archiving JPEG collections while preserving recovery of the source.

The format supports progressive coding, animation, alpha transparency, layers, thumbnails, wide color gamut, HDR, and high bit depth. Its box-based container can carry metadata such as EXIF and JUMBF. JPEG describes its reference software as free, open source, and royalty-free. See the JPEG organization’s JPEG XL overview for the format description and technical references.

Benefits of JPEG XL

• Lossy and lossless encoding: choose a smaller representation when some image information can be discarded, or preserve image data with lossless encoding.
• Exact JPEG recovery: losslessly recompress existing JPEG files and reconstruct the original JPEG bitstream. This is useful for archives and migrations where reversibility matters.
• Progressive rendering: an image can begin to render before all of its data has downloaded. This can be valuable for large images, though the benefit depends on the image, encoder, decoder, and delivery path.
• Broad image capabilities: transparency, animation, layers, thumbnails, wide gamut, HDR, and high bit depth are part of the format’s feature set.
• Flexible quality and compression tradeoffs: JPEG describes a general compression ratio of “typically 20:1 to 50:1,” but this is not a guaranteed result for a particular image or a direct comparison with another codec. Measure representative assets at the quality you need.

Drawbacks and implementation costs

• Uneven browser support: support varies by browser and version. Some versions are marked disabled by default or partial, so a JXL-only image can fail for visitors whose browser cannot decode it.
• Software support varies: desktop applications, image libraries, and metadata tools may support reading, writing, or only a subset of JXL features. Confirm the exact versions and operations in your workflow.
• No universal file-size winner: encoder settings and source content affect results. A format that is smaller for one photograph may be larger for another image or target quality.
• More delivery and testing work: if your audience includes unsupported clients, you need a fallback format and must test the real browser and device combinations that matter to your site.

JPEG XL vs AVIF and WebP

Choose by testing your own assets against the dimensions that matter: acceptable visual quality, bytes transferred, decode support, and any need for progressive display or exact JPEG recovery.

Consideration	JPEG XL	AVIF / WebP
Lossy file size	Can be competitive, but results depend on source and settings.	Can be smaller for a given example and target quality; verify with your encoder and images.
Lossless storage	Can perform well in lossless examples and can preserve recoverability of a source JPEG through lossless recompression.	AVIF and lossless WebP may be preferable for particular images; compare actual outputs.
Progressive rendering	Progressive coding lets a developing image render while downloading.	AVIF has basic progressive support according to the cited comparison; test the behavior that your client stack exposes.
Existing JPEG archives	Distinctive capability: losslessly recompress and restore the exact original JPEG bitstream.	Do not assume an encode to another format retains exact JPEG bitstream recovery.
Compatibility	Browser and application support remains version-dependent.	Check current compatibility for your supported clients as well; do not infer support from a format’s age or popularity.

In examples published by Jake Archibald on Mozilla Hacks, AVIF was 116 kB versus JPEG XL at 134 kB for one lossy image at SSIMULACRA 2 score 62.8, and 227 kB versus 264 kB at score 80. In two lossless examples, JPEG XL was smaller: 1.45 MB versus AVIF at 1.76 MB in one, and 92 kB versus 164 kB in another. These are examples from particular inputs and settings, not a general benchmark. Archibald summarizes JPEG XL as excelling at lossless imagery, progressive rendering, and further compressing JPEGs without quality loss; he describes AVIF as excelling at web-quality photographic images and images mixing sharp edges with flat surfaces. Read the full Mozilla Hacks comparison for context.

JPEG XL browser support

Browser support changes, so check a live compatibility table before setting a production policy. The snapshot below comes from Can I use, accessed October 3, 2026; its usage-share data is identified as August 2026.

Browser	Snapshot status
Chrome	Versions 155–157 supported; 145–154 disabled by default.
Firefox	Versions 158–160 supported; 90–157 listed as disabled by default.
Safari	Versions 17 through 27.1 and Technology Preview marked partial support.
Edge	Version 154 listed as not supported.
Mobile examples	Chrome for Android 154 disabled by default; Safari on iOS 17–27.1 partial; Firefox for Android 157 unsupported.

These are version-specific entries, not a promise about every browser build, configuration, or device. Can I use displays a combined global usage figure of 14.63% for this support data page, based on August 2026 statistics. Do not treat that number as JPEG XL adoption or as the share of people who can successfully decode a JXL image. Check the current Can I use JPEG XL table before relying on support data.

Mozilla Hacks published an intent-to-ship post on August 24, 2026, describing Firefox’s implementation using Google Research’s Rust decoder jxl-rs and stating that Chrome also intended to ship. An intent-to-ship announcement alone does not establish support in all stable versions; use the version table and test your actual target browsers.

How to use JPEG XL on a website

1. Inventory your images. Separate photographs, graphics with flat colors or sharp edges, transparency, animation, and JPEG archives. Include representative large and small assets.
2. Encode alternatives. Generate JXL and fallback files using production encoder settings. For JPEG archives, use a workflow explicitly designed for lossless JPEG recompression if exact recovery is required; retain and verify recovery according to your archive policy.
3. Compare quality and bytes. Inspect images at realistic display sizes and compare file size at the quality acceptable to your users. Do not transfer a result from one image to another.
4. Choose a fallback strategy. Keep a broadly supported image available for clients without JXL decoding. For example, use the HTML <picture> element with a JXL source followed by a fallback source:

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

5. Check server configuration. Serve the correct media type for JXL and ensure your CDN or image pipeline does not transform the file into an unexpected format. If you negotiate formats at the server, vary and cache responses correctly for the request headers you use.
6. Test actual clients. Test stable browser versions and devices from your audience, including fallback rendering, image dimensions, animation if used, transparency, and color appearance.
7. Roll out with monitoring. Watch image failures and performance after deployment. Keep the fallback files and a quick way to disable JXL delivery if a browser or serving issue appears.

The <picture> example lets the browser select a source it supports. Keep a real fallback in the <img> element. Do not infer client support only from a user-agent string if browser-native source selection can handle the choice.

Performance, reliability, and cost considerations

• Measure the full path: compare transferred bytes, visual quality, decode behavior, and when useful progressive display. Smaller files do not automatically mean a better experience if decoding, compatibility, or fallback behavior is poor for your users.
• Account for encoding work: test conversion throughput and storage needs in your own pipeline. Keep original assets if your workflow requires them, and verify exact JPEG recovery before deleting source files.
• Make delivery resilient: retain fallback images, test content types and cache behavior, and validate images in the browser versions that your site supports.
• Budget by observed outcomes: the format itself does not determine hosting or processing cost. Compare the bytes served, storage for variants, and encoding or transformation resources from your own workload.
• Check ecosystem coverage: the libjxl software-support list includes image libraries, metadata tools, operating-system integrations, and editors, with varying read/write and feature coverage. Verify your precise toolchain.

Or skip the browser setup

If you need a screenshot of a page that explains or previews an image format, ScreenshotNeo can capture it through one API request. It is a website screenshot API and MCP server for developers, made by Yorker Media. The service can return PNG, JPEG, WebP, or PDF; it does not convert images to JPEG XL.

Use ScreenshotNeo when you need a rendered page screenshot rather than a JXL file. Cookie banners are accepted and removed before the shot, along with known newsletter popups and chat widgets. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed; response headers identify the page verdict and billing status. AI agents can use its MCP server tools, including take_screenshot, get_page_info, and capture_pdf. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 shots. All features are on every plan. See the ScreenshotNeo site and API documentation.

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

Sign up for 1,000 free screenshots a month with no card.

Troubleshooting

Symptom	Likely cause	What to check or change
JXL image is missing or broken in a browser	The browser build does not decode JXL, or support is disabled or partial.	Keep a fallback source in <picture>; reproduce in the exact browser version and inspect the network response.
The browser downloads the file instead of displaying it	The response media type or server behavior may be wrong, or the client may lack a decoder.	Check the response content type and test the same file in a known JXL-capable application and browser.
Fallback is not selected	The markup, source type, or URL may be incorrect; alternatively the browser may claim support but fail on a feature subset.	Validate the markup and file URL, inspect console and network errors, and test with a simpler JXL asset plus the fallback.
JXL is larger than AVIF, WebP, or JPEG	Compression depends on image content, encoder, settings, and quality target.	Re-encode representative samples with comparable visual quality and compare the results.
Colors or transparency look different	Color profiles, wide-gamut handling, alpha, or application feature support can vary.	Check the source profile, target display, encoder options, and exact viewer/browser support; compare in the production target.
Archive conversion cannot restore the source JPEG	The conversion was not a lossless JPEG recompression workflow, or the wrong tool/mode was used.	Use a tool that explicitly supports JPEG XL lossless JPEG recompression and verify exact reconstruction before relying on it.
One editor opens a JXL but another cannot export it	Read and write support, or feature coverage, differs across applications and versions.	Consult the tool’s current support documentation and test the operation, not merely whether it can open a file.

FAQ

Is JPEG XL better than JPEG?

It offers capabilities JPEG does not provide in the same format, including HDR, high bit depth, progressive coding, and lossless recompression with exact JPEG recovery. Whether it is better for a website depends on support, quality, file size, and fallback requirements.

Can I use a JXL image without a fallback?

Only if every client you support can decode the specific JXL features you use. The cited compatibility snapshot is mixed, so most public websites should keep a fallback unless their audience and environment are tightly controlled.

Does JPEG XL always make a smaller file than AVIF?

No. Results vary by image, encoder, settings, and quality target. Compare your actual assets.

Is the 14.63% figure the share of users who support JPEG XL?

It is presented on Can I use’s page as a combined browser usage figure for its support data, not as a JPEG XL adoption measurement. Do not use it as a direct adoption statistic.

Sources

• JPEG organization: JPEG XL overview
• Can I use: JPEG XL browser support
• Jake Archibald, Mozilla Hacks: Intent to Ship: JPEG XL and format comparison examples
• libjxl software-support list