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, standardized 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 color 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 has been natively supported in Safari 17 and above (announced at WWDC 2023) for still images, covering all up-to-date macOS and iOS devices; Safari does not decode animated JXL or render progressively. Until October 2026 that Safari share, roughly 14–17% of global browsing, was the whole installed base, which is why this guide treated JXL as an Apple-audience format. That changed on October 6.

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 to 154 exposed it via chrome://flags/#enable-jxl-image-format, disabled by default. Chrome 155, released on October 6, 2026, enables it by default on Windows, macOS, Linux, ChromeOS and Android, with no flag; Google's announcement, "Shipping JPEG XL in Chrome", explains the Rust decoder and the memory-safety reasoning. Installed browsers take weeks to update, so for the rest of 2026 a share of Chrome traffic is still on 152 to 154.

Firefox enables JPEG XL by default from Firefox 158, released on October 13, 2026, with animation and progressive display; Firefox 157 does not, despite Mozilla's August intent to ship naming it. Edge, Samsung Internet and the other Chromium-based browsers had not shipped the change as of October 7, 2026, and Microsoft has made no statement. Check caniuse.com/jpegxl for the live row before you drop a fallback.

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: WordPress 7.1's client-side media pipeline outputs JPEG, PNG, WebP, AVIF and GIF, and Shopify's accepted upload formats are JPEG, PNG, GIF, HEIC and WebP. Browser support arriving does not change either of those until the platforms add an encoder.

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, analyzing 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. For a measured example on one real macOS screenshot, 46% smaller with every pixel checked, see JPEG XL vs PNG for screenshots. For how lossless JPEG XL compares with lossless WebP, PNG and AVIF across six image types, and when lossless is the wrong choice altogether, see which lossless image format to use.

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 from October 2026, JPEG-to-JXL serves Safari, Chrome 155+ and Firefox 158+ users, a share that grows weekly as installed browsers update. The baseline JPEG remains the universal fallback.

You can convert to JPEG XL directly with the JPG to JXL converter: drop the files and it re-encodes them with one high-quality setting, nothing to set. It is a re-encode, not the reversible JPEG transcode described above, so keep your JPEG masters. 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 reasons to convert PNG to JXL today are archival compression, lossless masters, and web delivery to the Chrome 155, Firefox 158 and Safari 17 audience, which is most desktop traffic once the October releases have rolled out. 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 with the PNG to JXL converter: a high-quality compressed encode by default, or switch Lossless on after uploading for a pixel-exact copy that is usually still smaller than the PNG.

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 still has the broader installed base, including Edge and Samsung Internet, which have not yet shipped JXL. 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 means you can serve JXL to Chrome 155 and Firefox 158 now - you just put the JXL <source> first.

Convert AVIF to JPEG XL with the AVIF to JXL converter: a decode and high-quality re-encode, nothing to set.

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 Chrome 155+, Firefox 158+ and Safari 17+, AVIF for Edge and older Chrome and Firefox, 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 Edge, in any Chrome or Firefox that has not yet updated to the October 2026 releases, and in email clients and chat apps. That remains the production reality for months after a release.

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

JPEG XL is production-ready with a fallback in most contexts since October 2026, and still the wrong choice in a few. Being clear about the difference saves headaches.

Production-ready with fallbacks: any site whose audience is mostly on Chrome, Firefox or Safari (Chrome 155, Firefox 158 and Safari 17 decode 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 Edge or in a not-yet-updated 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