JPEG XL and Core Web Vitals: what you need to know now that Chrome ships it

JPEG XL is finally coming back to Chrome

After three years of controversy, JPEG XL has returned to Chromium. Chrome 145, released early February 2026, ships with a JPEG XL decoder. Still behind a flag, but functionally present in the codebase for the first time since its contentious removal in late 2022. This matters because JPEG XL is demonstrably superior to every incumbent web image format across most technical dimensions: 50 to 60% smaller than JPEG, 10 to 15% better compression than AVIF at equivalent encode speeds, and the only modern format with true progressive decoding. For web performance professionals, the format's trajectory from ISO standard to Chrome exile to resurrection represents both a technical opportunity and a cautionary tale about browser vendor power over the web platform.

Browser support in February 2026 is only 12%

JPEG XL's effective global browser support sits at roughly 12%, almost entirely from Safari users. That number is about to change. But the timeline remains uncertain.

Safari 17+ (shipped September 2023) provides native JPEG XL decoding across macOS Sonoma, iOS 17, iPadOS 17, watchOS, and visionOS. Apple's implementation delegates decoding to the OS level image framework, which means it works everywhere Safari runs. However, Safari's support is explicitly partial: no animation support and no progressive decoding. Two of JPEG XL's most distinctive features. This is a meaningful limitation that undercuts the format's full value proposition on Apple devices.

Chrome 145 (February 2026) reintroduces JPEG XL via a pure Rust decoder called jxl-rs, replacing the previous C++ libjxl implementation. The decoder is gated behind chrome://flags/#enable-jxl-image-format and is not enabled by default. Google has set clear conditions for default on: a commitment to long term maintenance and meeting standard launch criteria. The Rust decoder currently performs within 15 to 25% of the C++ reference implementation's speed, with 26 optimization PRs merged in December 2025 alone. Confirmed working capabilities include ICC color profiles, animations, alpha/transparency, wide gamut (Display P3), and HDR (PQ/HLG).

Firefox remains the furthest behind. The format is available only in Firefox Nightly behind the image.jxl.enabled flag. Critically, the decoder code is not compiled into stable builds at all, so the flag does nothing on release Firefox. Mozilla's position has shifted from "negative" to "neutral," with active work (Bug 1986393) to integrate the same jxl-rs Rust decoder. No timeline exists for stable support.

Edge, as a Chromium derivative, likely contains the jxl-rs code from Chrome 145 but has not officially announced or documented JPEG XL support. The Edge 145 release notes make no mention of it.

Interop 2026 has included JPEG XL as an investigation area (not a full focus area), with Apple, Google, Microsoft, and Mozilla all participating. This signals cross vendor intent to build comprehensive test suites, which typically precedes broader shipping.

How JPEG XL outperforms every alternative. And where it doesn't

The compression efficiency story is nuanced and depends heavily on content type and bitrate. At the highest level, JPEG XL wins the most important real world comparisons.

Against JPEG

The gains are dramatic. JPEG XL achieves visually lossless quality at approximately 1.2 bits per pixel where JPEG requires 2.4 bpp. A 2:1 improvement. The [url=https://www.debugbear.com/blog/jpeg-xl-image-format]DebugBear benchmark[/url] of a 990 KB photograph showed JPEG XL at 472 KB (52% savings), compared to WebP at 700 KB and AVIF at 507 KB. [url=https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs]Cloudinary's testing[/url] of 40,000+ images found JPEG XL at effort 6 produced files 20% smaller than AVIF while encoding 2.5x faster.

Against AVIF

The comparison is bitrate dependent. At low bitrates below 0.4 bpp (heavy compression), AVIF outperforms JPEG XL. It produces smoother images with fewer artifacts. At mid to high bitrates (0.4 bpp and above), where most web photography lives, JPEG XL consistently wins on detail preservation and fidelity. Google's own AVIF comparison study showed 9 of 13 quality metrics favoring JPEG XL at practical encoder speed settings. The encoding speed gap is enormous: AVIF (via libaom) is an order of magnitude slower than JPEG XL in single threaded encoding. At AVIF's slowest settings (~0.5 Mpx/s), it matches the compression density of JPEG XL's second fastest setting at 52 Mpx/s. A 100x speed difference.

Against WebP

JPEG XL wins decisively. WebP is limited to 8 bit color depth, 4:2:0 chroma subsampling in lossy mode, and a maximum resolution of 16,383 x 16,383 pixels. JPEG XL supports up to 32 bit per channel (integer or floating point), resolutions exceeding 1 billion pixels per side, and has no chroma subsampling constraint.

Content type matters

For specific content types, the DebugBear benchmarks revealed a more mixed picture. AVIF won on logos (2 KB vs JXL's 6 KB) and transparency images (18 KB vs 63 KB), while JPEG XL won on photographs (472 KB vs 507 KB) and animated content where it achieved 99% compression (14 KB from a 1.3 MB GIF, versus AVIF's 56 KB). These results used Cloudinary's default settings, so they represent typical rather than optimized outputs.

Feature comparison

Feature	JPEG	WebP	AVIF	JPEG XL
Max bit depth	8 bit	8 bit	10/12 bit	32 bit
Progressive decoding	Limited	No	No	Advanced
Lossless JPEG transcode	N/A	No	No	Yes (~20% savings)
HDR support	No	No	Yes	Yes (superior)
Max dimensions	65K x 65K	16K x 16K	65K x 65K	~1B x 1B
Animation	No	Yes	Yes	Yes
Encoding speed	Fastest	Fast	Very slow	Fast
Decoding speed	Fast	Moderate	Slow	Fast

Two features no other format can match

JPEG XL's most strategically important features are progressive decoding and lossless JPEG transcoding. No competitor offers either.

Progressive decoding

Progressive decoding fundamentally changes how images load. JPEG XL files are always at least 8x8 progressive; the DC (low frequency) frame is always encoded first. With only ~1% of file data downloaded, a usable full image preview appears. Compare that to progressive JPEG, which requires 10 to 15% for its first scan. More importantly, JPEG XL supports saliency ordered progression: machine learning models can identify the most visually important regions (faces in portraits, product details in e commerce) and encode those regions to arrive first. The decoder smooths boundaries between completed and still loading regions.

This creates a different rendering timeline. AVIF requires the full compressed image before decoding can begin: total time equals download time plus decode time, sequentially. JPEG XL overlaps transfer and decode, so the user sees meaningful content much sooner. [url=https://cloudinary.com/blog/jpeg-xl-progressive-format-images-web]Cloudinary has noted[/url] that JPEG XL's progressive rendering eliminates the need for separate Low Quality Image Placeholder (LQIP) files, removing redundant bytes entirely. However, it's worth noting that Safari's current implementation does not support progressive decoding, which limits this advantage to future Chrome and Firefox implementations.

Lossless JPEG transcoding

Lossless JPEG transcoding is JPEG XL's sleeper feature. The format can directly copy JPEG's DCT block coefficients into its own VarDCT blocks, improving only the entropy coding. The result: ~20% average file size reduction (range: 13 to 22%) with the original JPEG file bit for bit reconstructable from the JXL file. No other format can do this. Transcoding to WebP or AVIF requires decoding to pixels and re encoding, causing generation loss. Google Cloud Platform's DICOM API already uses this capability to reduce medical imaging file sizes by 20%.

At web scale, if all current JPEGs were losslessly transcoded to JXL, the bandwidth savings would be enormous. The JPEG XL community estimates the energy savings equivalent to powering ~487,000 US homes for an hour per day.

What this means for Core Web Vitals

JPEG XL affects each Core Web Vital metric through different mechanisms, and the relationship is more nuanced than "smaller files = better scores."

LCP (Largest Contentful Paint)

LCP benefits from two compounding effects. First, smaller file sizes reduce Resource Load Duration. The download phase. A 52% reduction from JPEG means the hero image arrives roughly twice as fast on bandwidth constrained connections. Second, JPEG XL decodes faster than AVIF, reducing Element Render Delay. AVIF's complex video codec derived decoding can create meaningful CPU overhead on mobile devices, where a smaller AVIF that downloads faster may be partially negated by longer decode time. JPEG XL's decoding speed of up to 132 Mpx/s and SIMD optimization minimize this bottleneck. However, LCP is measured when the image is fully rendered, so progressive decoding does not directly improve the LCP timestamp. It improves perceived performance, which matters for user experience even if it doesn't move the metric.

CLS (Cumulative Layout Shift)

CLS does not care about format. All formats benefit equally from explicit width and height attributes. JPEG XL does encode dimension information in early headers, which could theoretically help browsers allocate space faster, but the practical impact is negligible compared to simply setting dimensions in HTML.

INP (Interaction to Next Paint)

INP can be affected by heavy image decoding on the main thread. JPEG XL's faster decoding and SIMD optimization mean less main thread blocking than AVIF, though both formats are typically decoded off the main thread in modern browsers.

Real world impact

The median web page in 2025 loads 19 images on mobile weighing 911 KB total (HTTP Archive Web Almanac 2025). Converting these from JPEG to JPEG XL would save roughly 450 to 550 KB per page. A substantial improvement for users on constrained networks. At median desktop image weight of 1,058 KB, the savings approach 500 to 630 KB.

Serving JPEG XL today with proper fallbacks

Implementation requires a layered strategy: the <picture> element for HTML images, server side content negotiation for CSS and dynamically referenced images, and CDN automation where available.

The picture element

The <picture> element provides the cleanest client side approach. Browsers evaluate <source> elements top to bottom and use the first supported format:

<picture>
  <source srcset="hero.jxl" type="image/jxl">
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Description" width="1200" height="800"
       loading="lazy" decoding="async">
</picture>

For responsive images, each source needs its own srcset with width descriptors. Creating a combinatorial explosion of 12+ variants per image (3 or 4 formats x 3 or 4 sizes). This is where CDN automation becomes essential.

Server side content negotiation

Server side content negotiation inspects the Accept header. Safari 17+ sends image/jxl in its Accept header. Nginx configuration maps this to file extensions:

map $http_accept $img_ext {
    ~image/jxl   '.jxl';
    ~image/avif  '.avif';
    ~image/webp  '.webp';
    default      '';
}

The critical detail: always include Vary: Accept in the response header so CDNs and proxy caches store separate variants per format. Without this, a cached JXL response will be served to browsers that cannot decode it.

CDN support

CDN support is uneven. [url=https://cloudinary.com/blog/jpeg-xl-progressive-format-images-web]Cloudinary[/url] offers full JPEG XL support through its f_auto parameter. Unsurprising given that Cloudinary co created the format and already delivers approximately 1 billion JPEG XL images per day. [url=https://www.fastly.com/blog/level-up-your-images-jpeg-xl-now-supported-by-image-optimizer]Fastly's Image Optimizer[/url] added full JPEG XL support in July 2024, using encoding effort 3 with 4 threads and claiming ~60% savings over JPEG. [url=https://developers.cloudflare.com/images/transform-images/]Cloudflare[/url], despite strong community demand, does not support JPEG XL conversion in its Image Resizing product. It can cache JXL variants from your origin via Vary: Accept, but cannot generate them. AWS CloudFront, Akamai, and Azure have no native JPEG XL support.

Tooling

Tooling for generating JPEG XL files centers on cjxl from the [url=https://github.com/libjxl/libjxl]libjxl reference implementation[/url]. Key parameters: -d for distance (0 = lossless, 1.0 to 2.0 for web quality lossy), -e for effort (1 to 9, default 7), and -p for progressive encoding. For JPEG inputs, cjxl input.jpg output.jxl performs lossless transcoding by default. The simplest possible migration path. ImageMagick, libvips (since 8.11), and Photoshop v25 also support JXL. However, sharp (the Node.js image library powering Next.js) does not yet expose JXL output, meaning Next.js has no native JPEG XL support. [url=https://core.trac.wordpress.org/ticket/52788]WordPress core support[/url] is tracked as ticket #52788, marked "maybelater."

The Halloween decision and its three year reversal

The political history of JPEG XL in Chrome is a case study in browser vendor power over web standards. Understanding it matters because it reveals the forces that shape which technologies reach users.

On October 31, 2022. Nicknamed the "Halloween decision." Jim Bankoski of Google's Chrome team announced the removal of JPEG XL experimental support. The stated reasons were fourfold: experimental flags shouldn't remain indefinitely; insufficient ecosystem interest; insufficient incremental benefits over existing formats; and maintenance burden. Bankoski suggested WebAssembly as "a great path forward" for those wanting JPEG XL in Chrome.

The backlash was immediate and sustained. The Chromium issue became the second most starred in the project's entire history, with over 1,000 upvotes and comments from representatives of Intel, Adobe, Meta, Shopify, The Guardian, Flickr, and the Krita Foundation. Jon Sneyers, the JPEG XL co creator at Cloudinary, published a detailed technical rebuttal ("The Case for JPEG XL") showing that Google's published comparison tests used buggy JPEG XL implementations and metrics biased toward AVIF. The [url=https://www.fsf.org/blogs/community/googles-decision-to-deprecate-jpeg-xl-emphasizes-the-need-for-browser-choice-and-free-formats]Free Software Foundation[/url] called Google's decision evidence that Google Chrome had become the arbiter of web standards and accused the company of acting for its own interests. Since AVIF derives from AV1, developed by the Alliance for Open Media that Google co founded.

The irony was not lost on observers: Google itself co created JPEG XL through its PIK project, making the decision to kill it from Chrome all the more confusing. When JPEG XL was proposed for Interop 2024, it received 646 community reactions. 4.5x the second place proposal. And was rejected with only "lack of consensus" as explanation.

What ultimately reversed the decision was ecosystem momentum that made Chrome's absence untenable. Apple shipping Safari 17 with JPEG XL support in September 2023 was the first major break. Mozilla shifting from "negative" to "neutral" and then to actively willing to implement (with a Rust decoder) added pressure. The [url=https://www.theregister.com/2025/11/10/another_chance_for_jpeg_xl/]PDF Association announcing JPEG XL as the preferred HDR format for PDF[/url] in October 2025 may have been the tipping point. Chrome's built in PDF viewer would need JXL support to remain compliant. On November 21, 2025, Rick Byers (Chrome Architecture Tech Lead) posted the reversal, welcoming contributions to integrate a performant and memory safe JPEG XL decoder in Chromium. By January 2026, the Rust based jxl-rs decoder was merged, and Chrome 145 shipped it behind a flag in February 2026.

Conclusion: prepare now, deploy incrementally

JPEG XL is technically the best general purpose image format available. Better compression than AVIF at practical encode speeds, progressive decoding that no competitor offers, and lossless JPEG transcoding that provides an instant 20% savings with zero quality loss. The political obstacles that blocked its adoption for three years are dissolving: Chrome has code in the tree, Firefox is actively integrating the same Rust decoder, and Safari has shipped support since 2023.

The practical path forward for web performance teams is clear. Start generating JXL variants now. Lossless JPEG transcoding via cjxl is trivially automatable and provides immediate 20% savings for the ~12% of users on Safari. Use <picture> elements or content negotiation with Vary: Accept headers to serve JXL alongside AVIF, WebP, and JPEG fallbacks. If your CDN is Cloudinary or Fastly, enable automatic JXL delivery today. The open question is not whether JPEG XL will achieve broad browser support, but when Chrome will flip the flag from off to on by default. And the only honest answer is that no timeline has been announced. The format's three year exile from Chrome should temper enthusiasm with pragmatism: serve it where supported, fall back gracefully elsewhere, and keep the pipeline ready for the moment universal support arrives.