AVIF vs WebP vs JPEG XL in 2026: Which Format Wins?

TL;DR >- Chrome 145 (February 2026) ships JPEG XL behind a flag via the memory-safe jxl-rs Rust decoder, with default-on expected in the second half of 2026 (Phoronix, 2025-2026).- AVIF has held roughly 93.4% browser support for years (caniuse, July 2026), yet sits at only 0.7-2% page adoption (Web Almanac 2025). Browser support was never the bottleneck.- AVIF encoding has been measured at up to 47x slower than WebP at comparable settings (libheif benchmark wiki, 2023-2025). Encode economics, not decode support, decide format migrations.- No format wins everything: AVIF leads lossy photography, JPEG XL leads lossless and high-fidelity work, WebP leads encode speed and ubiquity. The decision matrix is below.

Most of the coverage of Chrome 145 gets the story backwards. The framing goes: JPEG XL finally has a path into Chrome, so 2026 is the year the format war gets decided by browser support. But browser support has never decided a format war. AVIF has been decodable by roughly 93% of global browser traffic since Safari 16.4 shipped, and it still appears on fewer than 2 in 100 pages. The formats that win are the ones whose encode cost, tooling, and migration risk fit real pipelines.

That said, 2026 genuinely is an inflection point. For the first time, all three next-generation contenders are shippable or nearly so. This post lays out what changed, what the adoption data actually says, and how to choose by content type and pipeline budget rather than by headline.

What actually changed for JPEG XL in 2026?

Chrome 145, released in February 2026, ships JPEG XL decoding behind a flag (chrome://flags/#enable-jxl-image-format) using jxl-rs, a pure-Rust decoder, with default-on expected in the second half of 2026 pending launch criteria (Phoronix, 2025-2026). That follows Chromium's November 2025 reversal of its 2022 "obsolete" designation (devclass, 2025).

The reversal is worth reading precisely. When Rick Byers announced the decision for the Chromium Architecture Tech Leads on November 21, 2025, the condition was explicit: Chromium would accept a memory-safe decoder. Security and maintenance burden killed JPEG XL in Chrome in 2022. Rust unkilled it. The jxl-rs decoder is already within 15-25% of the C++ libjxl reference speed, with 26 optimization PRs merged in December 2025 alone (Helmut Januschka, 2026).

Meanwhile, the current support picture stays modest. JPEG XL sits at about 13.6% global browser support, all of it Safari 17+ "partial" support with no animation and no progressive decoding, while Chrome's implementation remains disabled by default through v153 (caniuse, July 2026). If Chrome flips the default later this year, that number jumps to roughly 85-90% essentially overnight. That is the real news hook, and also the reason to have a plan before it happens.

Was browser support ever the real bottleneck?

No. AVIF has full support in roughly 93.4% of global browser traffic across Chrome 85+, Firefox 93+, Safari 16.4+, and Edge 121+ (caniuse, July 2026), yet the Web Almanac measured AVIF on only about 0.7-2% of pages, against 57% for JPEG and 26% for PNG (Web Almanac 2025).

Here is the full support-versus-adoption picture:

Support: caniuse, July 2026. Adoption: Web Almanac 2025, Performance.

Browser support far outstrips page adoption for every modern format. Sources: Web Almanac 2025; caniuse, July 2026.

Read that middle row again. WebP shipped in 2010, reached near-universal support years ago, and still only carries 11% of page image usage. If support drove adoption, WebP would have displaced JPEG a decade ago. It didn't, because format migration is a pipeline project: re-encoding archives, updating CDNs and CMS integrations, revalidating quality gates, retraining editorial workflows. We've written before about why the pipeline from upload to delivery is where optimization actually succeeds or fails, and format choice is the clearest example.

The sites that did migrate are being rewarded, though. Median home page image bytes tell the story: JPEG carries 43-49 KB at the median, WebP 17-20 KB, and AVIF just 7 KB (Web Almanac 2025, Page Weight). Part of that gap is compression efficiency, and part is selection bias: the teams sophisticated enough to ship AVIF also compress more carefully everywhere else.

Compression and speed: the three-way numbers

AVIF typically produces files about 50% smaller than JPEG and 20-30% smaller than WebP at comparable visual quality, while WebP lands roughly 25-35% below JPEG (Cloudinary codec research). But bytes are only half the ledger. Encode and decode costs differ between these formats by an order of magnitude, and they point in opposite directions.

On the encode side, libaom-based AVIF encoding has been measured at up to 47x slower than WebP at comparable settings, while libjxl at default settings encodes roughly 5-10x faster than libaom-AVIF at equivalent quality (libheif benchmark wiki and community benchmarks, 2023-2025). On the decode side, JPEG XL decodes roughly 10x faster than AVIF and about 2x faster than WebP on typical hardware (XL Converter format comparison, 2024-2025). These are approximate, encoder-version-dependent numbers, but the ordering is consistent across benchmarks.

A caution on all such claims: "comparable visual quality" is doing heavy lifting in every codec comparison, ours included. Compression ratios shift with content, quality target, and the metric used to judge equivalence. We've documented how we benchmark codecs precisely because unverifiable ratio claims are endemic in this space. Treat every ratio above as a typical range, not a guarantee for your library.

Which format wins for each content type?

No single format wins every job. AVIF leads photographic content at low-to-mid quality targets, where it runs about 50% smaller than JPEG (Cloudinary codec research). JPEG XL leads lossless, high-fidelity, and synthetic imagery, plus bit-exact reversible JPEG transcoding, which no other format offers. WebP remains the fast, universal default.

Two rows deserve emphasis. First, the JPEG transcode row: JPEG XL is the only format that can convert an existing JPEG archive losslessly and reversibly, which changes the migration risk calculation for large libraries. You are not re-encoding and praying; you can round-trip back to the original bytes. For teams that have been burned by irreversible bulk re-encodes, this matters more than any compression ratio, and it is the same property we care about in invertibility for image optimization generally.

Second, the animation row: Safari's "partial" JXL support means no animation and no progressive decoding. Counting Safari 17+ as JXL-supporting overstates parity, so any near-term JXL rollout should scope to still images.

Encode cost is the pipeline story

For any service that transforms images on demand, encode CPU is the budget line that decides format choice. A 47x encode-cost gap between WebP and libaom-AVIF at comparable settings (libheif benchmark wiki, 2023-2025) is why many CDNs default to WebP and gate AVIF behind higher pricing tiers or async pre-generation.

Run the logic from the CDN operator's chair. Every cache miss triggers an encode. WebP encodes are cheap enough to do synchronously at the edge. AVIF encodes at quality-competitive settings are not, so operators either pre-generate variants (storage cost, pipeline complexity), serve AVIF only for popular assets (inconsistent wins), or eat the CPU bill. JPEG XL's 5-10x encode advantage over libaom-AVIF at equivalent quality is therefore not a nerd statistic. It is the argument that JXL fits on-the-fly transformation economics in a way AVIF never quite has.

This is also why we're skeptical of format advice that stops at "AVIF is smaller, use AVIF." Smaller per file, yes. But if the encode cost pushes your pipeline toward aggressive speed presets, quality suffers in exactly the way that file-size-first thinking always does: the metric you optimized looks great, and the images quietly don't.

So what should you ship in 2026?

Ship WebP as the negotiated default, add AVIF for photographic content where encode budget allows, and build a JPEG XL contingency now. If Chrome flips the default in H2 2026 as expected (Phoronix, 2025-2026), JXL support jumps from roughly 13.6% to 85-90% of traffic, and prepared teams win the window.

Concretely, in priority order:

1. Serve by content negotiation, not by rewriting URLs. Accept-header negotiation means adding a format later is a config change, not a content migration.
2. WebP everywhere as the modern baseline. At ~97% support and 25-35% savings over JPEG (Cloudinary codec research), it is the highest-certainty win per unit of effort.
3. AVIF for photography where you can pre-generate. Async encoding sidesteps the CPU problem for stable assets like product and editorial imagery.
4. Prototype a JXL path behind the Chrome flag today. Especially the lossless JPEG transcode route for legacy archives, since it is reversible if you need to back out.
5. Keep the JPEG fallback. The last few percent of traffic still needs it, and negotiation makes it free.

At Inverity, the way we frame this internally is that a format is an implementation detail of a quality target, not the other way around. Pick the perceptual quality you owe your users, then let the pipeline choose the cheapest format that hits it per asset. Formats will keep changing. That decision procedure won't.

FAQ

Is JPEG XL supported in Chrome in 2026?

Partially. Chrome 145 (February 2026) includes JPEG XL decoding via the Rust-based jxl-rs decoder, but it stays behind chrome://flags/#enable-jxl-image-format and remains disabled by default through v153 (caniuse, July 2026). Default-on is expected in the second half of 2026, pending launch criteria (Phoronix, 2025-2026).

Should I use AVIF or WebP for my website?

Use WebP as your default and AVIF where encode cost permits. AVIF is typically 20-30% smaller than WebP at comparable quality (Cloudinary codec research), but its encoding has been measured at up to 47x slower than WebP (libheif benchmark wiki, 2023-2025). Pre-generate AVIF for stable photographic assets; serve WebP on-the-fly.

Is AVIF better than JPEG XL?

For lossy web photography at low-to-mid quality, AVIF usually compresses smaller. JPEG XL wins lossless compression, high-fidelity targets, synthetic content, and decode speed, decoding roughly 10x faster than AVIF (XL Converter format comparison, 2024-2025). It also uniquely offers reversible JPEG transcoding. Different tools, different jobs.

Why did Chrome remove JPEG XL, and why is it back?

Chrome removed JPEG XL in 2022, citing maintenance burden and insufficient ecosystem interest. In November 2025, Chromium's Architecture Tech Leads reversed the "obsolete" designation, explicitly conditioned on a memory-safe decoder (devclass, 2025). The pure-Rust jxl-rs decoder satisfied that condition and shipped behind a flag in Chrome 145.

Do I still need JPEG fallbacks in 2026?

Yes. Even AVIF, the best-supported modern format, covers about 93.4% of global browser traffic (caniuse, July 2026), leaving a real remainder on older browsers, embedded webviews, and non-browser consumers like email clients and scrapers. Content negotiation makes the fallback nearly free, so there is no reason to drop it.