AVIF vs WebP in 2026: Which Format Should Your Next.js App Actually Serve?

Avif vs webp in is easier when you start with a clear default and a quick visual check.

The short answer

For most Next.js apps in 2026, the sensible setup is AVIF first and WebP second, with the original file left as the final fallback. There is a catch. Next.js still ships with WebP as its only default output format, and its own docs still recommend WebP for most use cases. The reason isn't browser support. It's cost: AVIF is slower to encode, and every extra format you enable adds another set of cached variants.

So the real question is "can my infrastructure absorb AVIF's encode and cache cost?" rather than "is AVIF better?" This guide covers both, plus the configuration details that changed in Next.js 16.

What actually differs between AVIF and WebP

Both are modern formats that replace JPEG and PNG on the web. They come from different codec families, and that shows up in practice.

About the numbers

The Next.js documentation gives a deliberately rough rule of thumb: AVIF takes about 50% longer to encode and comes out about 20% smaller than WebP. Third-party write-ups report anything from modest to dramatic savings. The spread is real, because results depend heavily on:

• Content type. Photos with gradients, skin tones and soft detail favor AVIF the most.
• Encoder and speed setting. libaom, SVT-AV1 and rav1e at different effort levels produce very different files and encode times.
• Quality target. A "quality 75" in one encoder doesn't mean the same thing in another.

Don't take anyone's percentage at face value, ours included. Encode a representative sample of your images and compare the file sizes at a quality you'd actually ship.

Content type matters more than format loyalty

• Photography, hero images, product shots: this is where AVIF clearly earns its cost.
• Screenshots and UI with text: savings shrink, and aggressive AVIF settings can soften sharp edges. Compare at 100% zoom. Lossless WebP or a well-optimized PNG is often competitive.
• Icons and logos: use SVG. Neither raster format is the right answer.
• Animation: animated WebP has broader tooling. For anything long, a muted <video> usually beats both image formats.

Browser support as of 2026

WebP works in every browser you're likely to care about. It's no longer a deciding factor.

AVIF is supported in Chrome 85+, Firefox 93+, Safari 16+ (iOS 16 / macOS Ventura and later) and Edge 121+. Published global estimates based on caniuse data mostly fall somewhere in the 90s. Sources disagree on the exact figure, so read any single number as approximate.

The remaining gap is mostly:

• Older iPhones and iPads that can't update past iOS 15
• Safari on macOS releases before Ventura
• Outdated Android browsers on low-end devices
• Proxy browsers in low-bandwidth markets

For a Next.js app using the built-in optimizer, this gap matters less than you'd expect. Format choice is negotiated per request through the Accept header, so a browser that doesn't advertise AVIF gets WebP or the original instead. No one sees a broken image.

Support outside the browser is a separate issue, and next/image doesn't help with it:

• Open Graph / social preview images: use JPEG or PNG for og:image unless you've tested every platform you care about.
• Downloadable assets: some OS image viewers and desktop apps still handle AVIF poorly.
• Email and PDF pipelines: keep using JPEG or PNG.

How Next.js chooses the format

The built-in Image Optimization API works like this:

1. It reads the request's Accept header.
2. It walks your images.formats array in order and serves the first format the browser accepts.
3. If nothing matches, or the source is animated, it serves the original format.
4. It caches each output format separately.

Out of the box, formats is ['image/webp']. To add AVIF, you opt in explicitly:

// next.config.ts
import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  images: {
    // Order matters: first match in the Accept header wins
    formats: ['image/avif', 'image/webp'],

    // Next.js 16: only qualities listed here are allowed
    qualities: [60, 75, 85],

    // Longer TTL = fewer re-encodes; pair with versioned URLs
    minimumCacheTTL: 60 * 60 * 24 * 30, // 30 days

    remotePatterns: [
      { protocol: 'https', hostname: 'cdn.example.com', pathname: '/uploads/**' },
    ],
  },
}

export default nextConfig

If you write ['image/webp', 'image/avif'], nearly every browser accepts WebP, so AVIF will almost never be served. Put the format you prefer first.

Next.js 16 image defaults worth knowing

Several next/image defaults changed in Next.js 16. They affect the AVIF/WebP decision because they change how many variants you encode and how long you keep them:

• images.qualities defaults to [75]. Any other quality prop is rounded to the closest allowed value, and a direct /_next/image request with an unlisted q returns a 400. If your hero images use quality={85}, add 85 to the list.
• images.minimumCacheTTL defaults to 4 hours (it used to be 60 seconds). That means less re-encoding, which matters a lot for AVIF. The tradeoff: an image you replace at the same URL can keep serving stale for hours. Since there's no built-in way to invalidate the cache, change the URL when content changes.
• 16 was removed from the default imageSizes. That makes the srcset slightly smaller.
• priority is deprecated in favor of preload. For an LCP image, loading="eager" or fetchPriority="high" is usually enough. Use preload for one image per page at most.

One quality value, two encoders

The quality prop goes to whichever encoder the negotiation picks. A given number doesn't produce the same perceived quality in AVIF and WebP, so a value that looks right in WebP may be more than AVIF needs, or less. Allowlist a small set of values, look at both outputs side by side on real content, and pick the lowest number that holds up. Don't copy a quality setting from a blog post.

The real production tradeoffs

Cold-cache latency

next/image encodes on demand. The first request for each width, quality and format combination pays the full encode cost. With AVIF that cost is higher, and a slow first image can end up as your LCP element. Pages that get steady traffic warm up quickly. Long-tail pages (big catalogs, user-generated content, deep archives) may serve a meaningful share of requests from a cold cache.

Cache and storage fan-out

Variants multiply. One source image rendered at 6 widths, with 3 allowed qualities and 2 formats, can produce up to 36 cached files. Turning on AVIF alongside WebP doubles that figure. For a few hundred marketing images it doesn't matter. For hundreds of thousands of product photos it does.

CPU on self-hosted and serverless setups

On a small VPS or container, a burst of cold AVIF encodes competes with SSR for the same CPU. On serverless, the encode time shows up on your bill and in your tail latency. Watch server CPU and image response times for a few days after enabling AVIF.

Proxies and CDN cache keys

If you self-host behind a reverse proxy or CDN, it has to forward the Accept header to Next.js. If it doesn't, every browser gets the same format and your formats setting quietly does nothing. The CDN also has to vary its cache by Accept (or by a normalized version of it). Otherwise the first browser to request an image decides which format everyone else gets. Check by requesting the same image URL with different Accept headers and comparing the Content-Type in the responses.

The alternative: encode ahead of time

If on-demand AVIF is too expensive for you, move the encode out of the request path:

• Static imports for images bundled with the app. They get content-hashed URLs and long-lived immutable caching.
• Pre-generated AVIF and WebP files (at build time or when an image is uploaded), served through a custom loader or with unoptimized on images you've already optimized.
• <picture> markup (for example via getImageProps) when you need explicit type="image/avif" and type="image/webp" sources or art direction.

With this approach you pay the AVIF encode once per asset, not once per variant per cold cache. It works well for user uploads and large catalogs, where the built-in optimizer's fan-out costs the most.

Decision table

Pre-ship checklist

• [ ] images.formats lists AVIF before WebP if you want AVIF served
• [ ] images.qualities includes every quality value your components use
• [ ] minimumCacheTTL is set on purpose, and changed assets get new URLs
• [ ] Your proxy/CDN forwards Accept and caches per format
• [ ] An LCP image uses loading="eager" or fetchPriority="high", not lazy loading
• [ ] sizes is set on responsive and fill images so mobile doesn't download desktop widths
• [ ] AVIF and WebP output compared side by side on real photos and screenshots
• [ ] Server CPU and image TTFB monitored for a few days after enabling AVIF
• [ ] Social preview images and downloads stay JPEG or PNG
• [ ] Large or user-uploaded libraries are pre-encoded instead of optimized on every request

Try it on Comprestack

Before changing next.config.ts, run a handful of your real images through both formats and compare the results:

• Compress and convert images: turn JPG and PNG into AVIF or WebP, then compare file size and visual quality side by side.
• Comprestack API docs: pre-encode AVIF and WebP when images are uploaded or at build time, so your Next.js server doesn't encode them on request.
• Plans and pricing: from the free tier up to Pro and Business. Agencies and platforms that need a branded conversion UI or API can look at White label.

More format guides are on the Comprestack blog.