Converting Images to JPEG XL: The Practical Guide for 2026

What JPEG XL Actually Is (and Why the Name Is Confusing)

JPEG XL (extension .jxl) is not a direct update to classic JPEG the way that phrasing implies. It is a completely new codec, standardised by the JPEG committee as ISO 18181, with a different architecture underneath. The "JPEG" in the name refers to the committee, not the format family.

Two properties make JXL genuinely unusual among modern formats. First, it can losslessly transcode an existing JPEG into a JXL container that is smaller but still allows exact byte-for-byte reconstruction of the original JPEG — you shrink the file without losing the source. Second, it supports up to 32-bit per channel colour depth and HDR (PQ and HLG), making it the strongest archival format in this comparison for professional photography workflows.

Compare that to AVIF, which tops out at 12-bit depth. Both WebP and AVIF are strong choices for web delivery today, but for long-term archival of high-bit-depth stills, JPEG XL's spec headroom is a real advantage.

Browser and Ecosystem Support in 2026

JPEG XL is natively supported in Safari 17 and above (announced at WWDC 2023), covering all up-to-date macOS and iOS devices. That gives you roughly 14–15% global browser coverage as a baseline — meaningful for Apple-heavy audiences, but not enough to replace JPEG or AVIF as your primary format.

Chrome's history with JXL is worth knowing because it explains where things stand now. Chromium shipped early JPEG XL support behind a flag in versions 91–109, then removed it entirely in Chrome 110 citing "lack of ecosystem momentum." In late 2025 and early 2026, Google reversed course: a Rust-based JXL decoder (jxl-rs) was merged into Chromium's rendering pipeline. Chrome 145 and later Canary builds expose it via chrome://flags/#enable-jxl-image-format, but it remains disabled by default and Google has not announced a stable-channel rollout date as of mid-2026.

Firefox is in a similar position — JPEG XL support is available in Nightly and Firefox Labs builds but is not enabled in general releases.

CDN and platform support follows the same split. Fastly Image Optimizer supports JPEG XL as both input and output. Cloudflare Images and Netlify Image CDN do not yet support JXL as an output format. Imgix accepts JXL as input but only serves AVIF or WebP as output. Major CMSes — WordPress core and Shopify — do not expose JXL in their upload or delivery pipelines, and several WordPress performance guides explicitly categorise it as not production-ready for those stacks in 2026.

Compression Benchmarks: How Much Smaller?

JPEG XL's compression efficiency is well-documented in peer-reviewed testing. The JPEG XL next-generation image compression architecture paper from Google covers the codec's design goals and efficiency in detail. Here is what the numbers say across three scenarios.

Lossy: JPEG XL vs JPEG

For typical photographic content, a lossy JPEG XL re-encode at comparable perceptual quality produces files 30–55% smaller than legacy JPEG. The upper end reflects high-effort encoder settings; a practical web preset sits closer to 35–45%. Google's Image Coding Comparisons tool shows JPEG XL consistently outperforming JPEG and WebP at equivalent subjective quality across a broad range of photographic test sets.

JPEG XL vs AVIF is tighter. Cloudinary image researcher Jon Sneyers, analysing the same benchmarks with practical encode presets (JXL s6 vs AVIF s7), found that 9 out of 13 quality metrics favoured JPEG XL on photographic datasets — a useful read on a competitive comparison.

Lossless: JPEG XL vs PNG

PNG has been the default lossless format for web graphics for decades. JPEG XL lossless is a meaningful upgrade. Community benchmarking across hundreds of images found that JPEG XL lossless at effort=1 (very fast) produced files roughly 19–25% smaller than PNG at PNG's own maximum compression, while encoding around 150 times faster. At higher effort settings, JPEG XL lossless can be 40–50% smaller than PNG — at the cost of much slower encoding. For archival use where you run the encoder once and store the result, high-effort settings are often worth it. JPEG XL also supports full transparency in both lossy and lossless modes, making it a viable PNG replacement for logos, sprites, and UI assets.

Lossless JPEG archiving

This is JPEG XL's most distinctive feature. Existing JPEG files can be transcoded into a JXL container that allows exact byte-for-byte reconstruction of the original JPEG. The EPFL/Google benchmarking paper puts the average storage reduction for this reversible transcoding at 22% across broad test sets, with Apple's WWDC documentation noting up to 60% reduction on some photographic datasets at higher settings.

For large JPEG archives — e-commerce product catalogs, photo libraries, stock collections — converting JPEG to JXL in lossless-transcode mode gives you 20–40% storage savings while preserving the ability to reconstruct the original JPEG exactly. That is a hard-to-argue-with value proposition for archival pipelines, independent of browser support.

Converting JPEG to JPEG XL

Converting JPEG to JPEG XL has two distinct modes, and which one is right depends on your goal.

Lossless transcode mode wraps the original JPEG data inside a JXL container with no re-encoding. You retain bit-for-bit reconstructability of the source file, and you typically see 20–30% file size reduction. This is the right choice for archival use and for any pipeline where you might need the original JPEG again downstream — legacy systems, social preview generation, ad networks.

Lossy re-encode mode fully decodes the JPEG and re-encodes to JXL at the target quality. You get larger savings — 40–60% vs the original JPEG at similar perceptual quality — but you are making a generation copy. If the source JPEG was already lossy, you are stacking artifacts. This is the right choice when you have access to the raw source (a TIFF, a RAW export, or a lossless master) and are producing a fresh JXL for serving.

For web delivery in mid-2026, JPEG-to-JXL primarily serves Safari users and Chrome users who have enabled the flag. The baseline JPEG remains the universal fallback.

You can convert to JPEG XL directly at mochify.app/jpg-to-jpegxl — describe what you need in plain English, or drop your files and let Magic Flow choose the right settings. For batch workflows, the CLI and MCP routes are covered in the Mochify Workflow section below.

Converting PNG to JPEG XL

PNG is overused as a web format because it is the default export from many design tools, not because it is the right choice for most images. JPEG XL gives you two options to improve on it.

For photographic PNGs (PNG exports of photos, which are common from Figma and similar tools), lossy JPEG XL typically cuts file size by 60–80% at similar visual quality. The format's VarDCT mode handles photographic content the same way AVIF or WebP do — much better than PNG's lossless model.

For graphics, illustrations, UI elements, and transparent assets, JPEG XL lossless is the right mode. You keep the transparency, the sharp edges, and the exact pixel data. The compression win over PNG (19–50% depending on encoder effort) is a genuine improvement, not a trade-off.

In practice, the main reason to convert PNG to JXL today is archival compression and the Safari audience. For web delivery, you would pair the JXL source with a WebP or PNG fallback in a <picture> element. For pipelines using Fastly Image Optimizer or a JXL-aware CDN, the CDN can negotiate the format automatically based on the client Accept header.

Convert PNG to JPEG XL at mochify.app/solutions/png-to-jxl.

Converting AVIF to JPEG XL

Converting AVIF to JPEG XL for current web delivery does not make much sense on compression grounds alone — both formats are competitive, and AVIF has far broader browser support across Chrome, Firefox, Safari, and Edge. You would be trading ecosystem compatibility for marginal compression gains.

The case for AVIF-to-JXL conversion is narrower and more specific. For HDR and wide-gamut archival, AVIF supports HDR but tops out at 12-bit depth. JPEG XL goes to 32-bit. If you are building a long-term archive from AVIF masters, JPEG XL is the stronger archival target for high-bit-depth content. For consolidating a mixed archive, if you have a mix of JPEGs, PNGs, and AVIFs and want a single high-quality master format for storage, JPEG XL can ingest all of them. The masters become JXL; AVIF, WebP, and JPEG derivatives are generated from those masters for web delivery. And for pipeline readiness, building AVIF-to-JXL into your workflow now means you are ready to serve JXL when Chrome and Firefox ship it by default — you just flip the <source> priority.

Convert AVIF to JPEG XL at mochify.app/avif-to-jpegxl.

The Fallback Pattern: Serving JXL Safely on the Web

The canonical pattern for JPEG XL on the web uses the HTML <picture> element. Browsers evaluate <source> elements in order and select the first format they support, falling back to the <img> tag for everything else.

<picture>
  <source type="image/jxl" srcset="image.jxl">
  <source type="image/avif" srcset="image.avif">
  <source type="image/webp" srcset="image.webp">
  <img src="image.jpg" alt="Description of image" width="800" height="600">
</picture>

This stack gives you JXL for Safari and Chrome-with-flag-enabled, AVIF for Chrome/Firefox/Edge, WebP for older clients, and JPEG for everything else.

Always include width and height attributes on the <img> tag. Browsers need these to reserve layout space before the image loads. Omitting them causes cumulative layout shift (CLS), which affects your Core Web Vitals score. See our guide on optimizing hero images for web performance for more on this.

Do not serve JPEG XL as your only format. A standalone <img src="image.jxl"> will display a broken image in Chrome, Firefox, and Edge for the majority of users who have not enabled the flag. This is the current production reality.

CDN-level negotiation is cleaner than HTML for high-traffic sites. If you are on Fastly Image Optimizer, you can configure it to auto-negotiate JXL based on the Accept header, so the right format is served without changing your image markup. Cloudflare and Netlify do not yet offer this for JXL.

When Not to Use JPEG XL Yet

JPEG XL is production-ready in specific contexts and experimental in others. Being clear about the difference saves headaches.

Production-ready with fallbacks: photography portfolios and creative tools serving a predominantly macOS/iOS audience (Safari 17 and above handles JXL natively); internal archival and storage pipelines where browser support is irrelevant; sites running on Fastly Image Optimizer, which can serve JXL to capable clients automatically; HDR photography and retina-quality sites where the 32-bit depth is a real advantage.

Wait or test carefully: WordPress and Shopify sites — neither platform exposes JXL in its standard delivery stack. Mass-market web apps where a broken image in Chrome is a business problem. Any pipeline that feeds third-party systems such as social previews, email clients, or ad networks, which mostly do not understand JXL and will display nothing.

FAQ