WebP vs AVIF vs JPEG XL: Which Should You Serve in 2026?

The WordPress image-format question used to be simple: ship JPEG, optionally generate WebP, call it done. In 2026 there are three modern formats competing for the same slot in your <picture> tag — WebP, AVIF, and JPEG XL — each with different compression characteristics, encoding speeds, browser support, and ecosystem maturity. Picking the right combination for your site is no longer obvious.

This guide compares all three, head to head, with the actual numbers as of 2026 and a clear recommendation for typical WordPress use cases.

The short version

• Always ship WebP. It is universally supported, encodes fast, and reliably produces 25-35% smaller files than JPEG. There is no reason a 2026 WordPress site should not have it.
• Ship AVIF when you can. It compresses 30-50% better than WebP at equivalent quality, but encoding is slower and a small slice of your traffic still cannot decode it.
• Skip JPEG XL for now. Browser support is still uneven and the format has not delivered the dominant adoption many predicted. Revisit in 2027.

The rest of this guide explains why.

A note on what we are comparing

When format comparisons go wrong it is usually because they compare incompatible quality settings — JPEG q90 versus WebP q75 versus AVIF q60 — and then declare the smallest output the winner. That is not useful. The real question is: at the same perceived visual quality, how many bytes does each format need?

The numbers below come from the open-source Squoosh benchmarks, the Cloudinary 2025 image format study, and our own testing on a corpus of typical WordPress hero images (1600px, photographic, JPEG-original).

WebP

Released: 2010 by Google. Based on the VP8 video codec.

Browser support in 2026: ~99% globally. Every modern browser, every recent mobile OS, every relevant crawler. Safari has supported it since 14 (2020). Internet Explorer never did, but you do not have IE traffic.

Compression vs JPEG (same visual quality): 25-35% smaller files. Reliable, predictable.

Encoding speed: Fast. A 1600x1200 JPEG converts to WebP in under 200ms on typical server hardware, often faster than the JPEG was originally encoded.

Lossy and lossless modes: Both. Lossless WebP is roughly 25% smaller than PNG.

Animated: Yes. Smaller than animated GIF and decodes faster.

Where it shines: Drop-in replacement for JPEG and PNG. The default modern format. If you can only pick one, pick WebP.

Where it falls short: Compression efficiency tops out below AVIF, especially on photographic content with smooth gradients and skin tones.

AVIF

Released: 2019 by the Alliance for Open Media. Based on the AV1 video codec.

Browser support in 2026: ~96% globally. Chrome (since 85, 2020), Firefox (since 93, 2021), Safari (since 16.4, March 2023), all modern Android, iOS 16+. The remaining 4% is mostly old iOS devices and a small slice of Android browsers in regions with slower update cycles.

Compression vs JPEG (same visual quality): 40-50% smaller files. Roughly 30% smaller than WebP at the same quality.

Compression vs WebP at small sizes: AVIF’s advantage shrinks for small thumbnail-sized images and grows for large hero images. Below ~300x300, the difference is often within encoding noise. Above 1600px, AVIF wins clearly.

Encoding speed: Slow. AVIF encoding is 3-10x slower than WebP at similar quality settings. A 1600x1200 image can take 1-3 seconds to encode on typical server hardware. This rules out real-time encoding on many shared hosts.

Decoding speed: Acceptable. Modern browsers decode AVIF in tens of milliseconds — slower than JPEG/WebP but not noticeable to users.

Where it shines: Hero images, large product photography, anything above 1000px wide where bandwidth savings matter and one-time encoding cost is acceptable.

Where it falls short: Encoding-heavy workflows on shared hosting (real-time thumbnail generation), and the long tail of older devices in markets with slow upgrade cycles.

JPEG XL

Released: 2021 by the Joint Photographic Experts Group. Designed as a true successor to JPEG.

Browser support in 2026: Mixed and politically complicated. Safari (since 17, 2023) and Edge support it. Chrome removed experimental support in 2023 citing low industry interest. Firefox has it behind a flag. Globally, browser support sits at roughly 35-40% depending on whose telemetry you trust.

Compression vs JPEG: 40-60% smaller files at equivalent quality, with the additional benefit of lossless JPEG re-encoding (you can convert an existing JPEG to JPEG XL losslessly while still saving 20% on file size).

Encoding speed: Comparable to WebP. Significantly faster than AVIF.

Decoding speed: Fast — close to JPEG.

Standout features: Progressive decoding by default, true HDR support, lossless JPEG re-encoding, and a generation gap of features over WebP and AVIF on the technical merits.

Where it shines: Technically, almost everywhere. Practically, nowhere on the public web yet.

Where it falls short: Browser support. Without Chrome (which is roughly 65% of global browser market share), you cannot ship JPEG XL as a primary format and rely on browsers to fetch it. You can include it in a <picture> tag for Safari users, but the encoding overhead and CDN cost rarely justify a third format for a single browser.

What to actually ship from WordPress

Three reasonable strategies, depending on your situation.

Strategy 1: WebP only (the default)

Ship JPEG fallbacks and WebP variants. The <picture> tag picks WebP for ~99% of traffic; JPEG serves the rest. This is what most WordPress optimization plugins do, including the free tier of StaticQ Media, WebP Express, and Converter for Media.

Result: 25-35% bandwidth savings versus JPEG-only, near-zero compatibility risk, fast encoding.

Strategy 2: AVIF + WebP + JPEG (the optimal)

Ship a <picture> tag with AVIF as the first source, WebP as the second, JPEG as the fallback. Browsers pick the first format they can decode.

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="...">
</picture>

Result: ~96% of traffic gets AVIF (40-50% smaller than JPEG), the next 3% gets WebP (25-35% smaller), the long tail gets JPEG. This is the optimal compression strategy in 2026, but the catch is encoding cost. On shared hosting, generating AVIF for every image in a 5,000-image library can take a full day of CPU time.

The pragmatic version is to encode AVIF for hero images and large photos only — anything above 800px wide — and skip AVIF for thumbnails where the byte savings are marginal. WebP handles the small stuff.

Strategy 3: Cloudflare Image Resizing

If you do not want to manage encoding on your own server, Cloudflare’s Image Resizing API will encode AVIF, WebP, and JPEG variants on demand. The catch is that Image Resizing requires a paid Cloudflare plan (Pro $25/mo and up) on your zone, or a separate Cloudflare Images subscription. For sites that already pay for Cloudflare Pro for other reasons (caching, security, analytics), enabling Image Resizing is a small marginal step. For sites on Cloudflare Free, this strategy means upgrading first.

StaticQ Media supports this directly. You enable Cloudflare Image Resizing in settings, point at your domain (already proxied through Cloudflare), and the plugin uses Cloudflare to generate resized + format-converted variants during cron processing. You get AVIF without the local encoding cost, and the output files are stored in your own R2 bucket — meaning if you ever switch off Cloudflare’s image service, you keep all the files.

What about JPEG XL?

Today: skip it. Watch the format quarterly.

The format is technically superior. The blocker is Chrome. Without Chrome support, no major image plugin will prioritize JPEG XL output, and without that ecosystem, browser engines have less motivation to implement it. The chicken-and-egg loop is real, and there is no clear catalyst to break it in 2026.

If Chrome reverses position — possibly under pressure from photographers and image-heavy publishers, or from a wider Web standards push — JPEG XL could become a viable third format quickly. But planning for that today, with the costs of generating and storing a third variant, is premature.

A 2026 decision tree

If you have:

• Less than 500 images, basic shared hosting: Ship WebP. Use the local encoder in StaticQ Media or any WP image plugin. Done.
• Mid-size site (500-5,000 images), VPS or higher: Ship AVIF + WebP + JPEG. Use Cloudflare Image Resizing (requires Cloudflare Pro) if you do not want to burn local CPU.
• Large site (5,000+ images), serious traffic: Same strategy, but invest in a real CDN front-end and consider per-route encoding policies (AVIF on hero, WebP on thumbnails).
• Specialty (photography portfolio, design portfolio): AVIF for everything, WebP fallback. The clientele is on modern browsers.
• Anyone: Don’t ship JPEG XL yet.

How StaticQ Media handles this

StaticQ Media generates WebP variants by default for every image you upload, using your server’s GD or Imagick. Optional Cloudflare Image Resizing (requires a paid Cloudflare plan on your zone) hands resize and format conversion to Cloudflare’s edge for users who want to offload CPU work. The generated <picture> tag handles browser negotiation automatically. Local AVIF encoding is on the roadmap.

Free, no per-image limits, runs on your own infrastructure. If you have feedback on which formats to prioritize next, email hello@staticq.io.