JPEG XL Is Back in Chrome. Here Is What That Changes for Web Images

JPEG XL had a strange three years. Google removed it from Chrome 110 in February 2023, citing weak ecosystem adoption. Three years later, in Chrome 145 (February 2026), Google quietly re-added it behind a flag. The current expectation is that Chrome will turn JPEG XL on by default in the second half of 2026, with Edge following the same release cycle. That would push global browser support from today's 16 percent (Safari only) to roughly 85 to 90 percent in a few weeks.

For anyone running an image-heavy site, this is the most significant image-format event since AVIF reached default-on status in Firefox in 2021. It changes which formats are worth serving, how an image pipeline should be configured, and what the size budget for images looks like by 2027.

This post covers what JPEG XL actually is, the chain of decisions that led to its return, what it does that AVIF and WebP do not, and what to do about it before the Chrome default flip.

What JPEG XL actually is

JPEG XL is a still-image codec standardized as ISO/IEC 18181 in 2022. It was designed by the same standards group that produced the original JPEG, in collaboration with researchers and engineers from across the industry. The reference implementation (libjxl) is open source, and the format is royalty-free.

What sets it apart at the format level:

Lossless and lossy in one codec. JPEG XL handles both lossless encoding (think PNG replacement) and lossy encoding (think JPEG replacement) in the same file format. The container is the same; only the encoder mode differs. WebP also does this. AVIF technically does, but the lossless mode is rarely used in practice because the encoder is slow.

Lossless JPEG transcoding. A regular JPEG can be re-encoded as JPEG XL with no quality loss and roughly 20 percent smaller file size. The original JPEG can be reconstructed bit-exact from the JPEG XL file. This is unique to JXL, and it matters more than it sounds. An existing archive of millions of JPEGs can be shrunk by about 20 percent without introducing artifacts and without committing to JPEG XL permanently. Nothing else offers this.

Progressive decoding. The image renders blurry first and sharpens as bytes arrive. WebP and AVIF do not have this. On slow connections, this is the difference between "see something usable in 200 ms" and "see nothing for 800 ms."

Wide color gamut, HDR, alpha channel, animation, 16-bit precision. All built in. AVIF supports most of these too. WebP supports a smaller subset, and the support is patchier.

Encoding speed. Encoding a JPEG XL file is roughly comparable to encoding a high-quality JPEG. Encoding an AVIF file at matched perceptual quality takes 5 to 10 times longer, because AVIF's encoder is built on the AV1 video codec.

The format was designed to be the file format you migrate to from JPEG and never have to think about again. AVIF was designed as a smaller win at the cost of more complexity. WebP was designed as a 2010-era pragmatic improvement.

What happened with Chrome, and why it matters

Chrome shipped experimental JPEG XL support behind a flag in late 2021 (version 91). In February 2023, Chrome 110 removed the implementation entirely. Google's stated reasoning at the time was that the broader ecosystem had not adopted JPEG XL and that the maintenance cost of a flagged feature was not justified.

The decision was unpopular. The JPEG XL community, which includes engineers from Adobe, Facebook, Intel, and parts of Google itself, responded with technical pushback. Apple shipped native JPEG XL support in Safari 17 in September 2023. Cloudinary added it on the delivery side. Adobe added it in parts of its imaging stack. Most of the actual content infrastructure quietly normalized around the format while Chrome stayed the holdout.

In February 2026, with Chrome 145, the experimental flag returned. The technical context around the reversal points to three plausible drivers: AVIF encoding cost in production pipelines has remained higher than expected, Safari's JPEG XL support has been stable for over two years with no notable issues, and the libjxl team shipped a smaller, more focused decoder that addressed the original maintenance concerns.

The default-on flip is the part that affects site owners. Once Chrome flips the flag in the second half of 2026, JPEG XL goes from a research curiosity to a real-world deliverable overnight. The window to get an image pipeline ready for that is roughly the next few months.

What JPEG XL does that AVIF and WebP do not

The numerical comparisons depend on the content type, but the rough hierarchy in 2026 looks like this:

AVIF is the size champion for photographic content. Files are roughly 50 percent smaller than JPEG and 20 to 30 percent smaller than WebP at matched perceptual quality.

JPEG XL is competitive on photographic content (a few percent larger than AVIF, a few percent smaller than WebP), but it pulls ahead substantially on non-photographic content: line art, illustrations, screenshots, text-heavy images. For those, JPEG XL is meaningfully smaller than both alternatives.

WebP is the safe fallback. It is universally supported, it works, and the encoder is fast. The reason to keep using it in 2027 is the long tail of browsers that have not updated.

The technical differentiators that actually matter in production:

The encoding-cost difference is significant. AVIF's encoder is closer to a video frame encoder than a still-image encoder. For sites that generate images on the fly (user uploads, dynamic resizing, on-demand transcoding), AVIF encoding is a real operational expense. JPEG XL's encoder is roughly comparable to high-quality JPEG encoding, which means it slots into the kind of pipelines that already exist.

Progressive decoding is invisible to anyone on fast wifi but very visible to users on bad connections. The progressive decode in JPEG XL is true: low-frequency information arrives first, then high-frequency. WebP and AVIF either render nothing or render a corrupt partial frame until the whole file arrives.

JPEG-to-JXL transcoding is the standout feature. The lossless transcoding from JPEG to JPEG XL is a one-shot operation in libjxl. It does not re-encode, it does not introduce artifacts, and it is fully reversible. For sites with large archives of JPEGs (which is most sites that have been around for a few years), this is a 20 percent CDN bandwidth saving with no quality cost and near-zero migration risk.

What to do before the Chrome default-on flip

Three concrete steps for sites that care about image performance.

Add JPEG XL to your format negotiation. Most sites already serve modern formats through the <picture> element or a CDN that does content negotiation. Adding JPEG XL is a matter of adding one more <source> tag with type="image/jxl" ahead of the AVIF source. Browsers that do not support it fall through to the next format. The fallback chain remains intact, and the cost of adding the JXL source for a browser that does not support it is zero bytes.

Decide on the JPEG archive question. If your site has a large JPEG archive, the lossless JPEG XL transcoding is meaningful. A 20 percent reduction on a 10 TB image archive is real CDN money. The risk is near zero because the transcoding is reversible. The cost is encoder time, which is one-time and parallelizable.

Update your image pipeline's format priority. A reasonable late-2026 priority list for new image uploads:

1. JPEG XL for browsers that support it (Safari today, Chrome and Edge from H2 2026, Firefox status uncertain)
2. AVIF for browsers that support AVIF but not JXL (a shrinking set, mostly Firefox in the near term)
3. WebP as a broad fallback
4. JPEG as a final fallback for legacy clients

Sites that already serve AVIF can leave AVIF in place as the middle tier. Sites that skipped AVIF entirely can consider going JPEG XL plus WebP and dropping AVIF entirely, which simplifies the pipeline at the cost of slightly larger files for Firefox users.

When NOT to use JPEG XL

JPEG XL is not the right answer for every image.

For animated content, JPEG XL supports animation, but the implementations have not caught up to WebP and AVIF on this. For animated GIF replacement, stick with WebP or AVIF.

For browsers older than Safari 17 or Chrome 145, the fallback chain has to exist. JPEG XL is a "serve to capable browsers" format, not a "serve everywhere" format. Until the global support number is north of 95 percent, a fallback is non-negotiable.

For sites where the image pipeline is fully owned by a CDN that has not added JPEG XL yet, the rational move is to wait. Some commercial image CDNs are still catching up. Rolling your own JPEG XL encoder outside the CDN is rarely worth the operational complexity.

For very small images (favicons, small icons, anything under a kilobyte), format overhead matters more than format efficiency, and PNG or WebP often beat JPEG XL at small sizes.

Firefox is the wildcard

Firefox's position on JPEG XL has been ambiguous. Mozilla has historically been positive about the format but has not shipped a default-on implementation. As of mid-2026, Firefox still keeps it behind a config flag (image.jxl.enabled), and the official position is that Mozilla wants to see Chrome's implementation prove out in production before committing.

The realistic timeline is that Firefox follows Chrome by some number of months. That puts the "JPEG XL is universal" milestone somewhere in 2027. Until then, the format is a "serve to most users" deliverable, not a "serve to everyone" deliverable, and the fallback chain stays in place. Sites that are willing to serve a slightly larger AVIF or WebP to Firefox users are not losing much.

How ReezoAI's image tools handle format conversion

The image converter currently handles conversion between PNG, JPG, WebP, AVIF, and HEIC. JPEG XL is in the queue and will land alongside Chrome's default-on flip, when there is a meaningful download audience for the format. The reason for waiting is the same one Mozilla cites: shipping support for a format that 16 percent of browsers can read is a different operation than shipping support for a format that 85 percent of browsers can read.

The image compressor runs entirely in the browser using WebAssembly-compiled encoders. The same architecture that handles existing PNG, JPG, and WebP compression client-side extends naturally to JPEG XL, with one constraint. The current libjxl WebAssembly bundle is large by client-side standards, and shipping a multi-megabyte encoder to every visitor on every page load is not workable. The path forward is incremental: lazy-load the encoder only when the user explicitly picks JPEG XL output, and let the libjxl team continue to shrink the bundle.

This is the kind of work that is invisible from the outside but matters for the in-browser model. The tool works without uploading files, which means the encoder runs on the user's device, which means the encoder bundle has to fit a reasonable page-load budget. New format support arrives when the browser support and the encoder bundle size both line up.

Short summary

JPEG XL went from "removed from Chrome" to "coming back to Chrome by default" in three years. The default-on flip in the second half of 2026 changes JPEG XL from a research format into a real deliverable for image-heavy sites. The biggest practical win is the lossless transcoding of existing JPEG archives, which produces a 20 percent reduction in CDN bandwidth with no quality loss and no migration risk.

The right move before the flip is to add JPEG XL to your format negotiation chain, transcode your JPEG archive losslessly, and treat AVIF as a middle-tier fallback for browsers that adopt JPEG XL late. The era of "WebP plus a JPEG fallback" served the 2020s well. The 2027 default looks more like JPEG XL with an AVIF or WebP fallback for everyone else.