📅 Published 6 April 2026

Images account for the majority of bytes transferred on most web pages, and the choice of format determines how much of that weight is genuinely necessary. JPEG has served the web since 1995. WebP arrived in 2010 with better compression. AVIF landed in browsers around 2020 with better compression still. But "newer is better" is an oversimplification — encoding speed, quality characteristics, browser support edge cases, and the specific type of image all affect which format produces the best result for a given use case.

This comparison is based on production experience encoding thousands of images across all three formats for sites where transfer size directly affects user experience and hosting costs. The page is part of the web development section and connects to the web performance topic hub.

Format characteristics​

JPEG compresses photographic images well and decompresses fast. Its artefacts are well-understood — blocky degradation at low quality, colour banding in gradients. Every browser, image tool, and CMS supports JPEG without exception. Progressive JPEG provides a decent perceptual loading experience. For photographic content at quality 80+, JPEG remains a reasonable choice — not optimal, but never wrong.

WebP provides 25–35% smaller files than JPEG at equivalent visual quality for photographic content. It also supports transparency (alpha channel) and animation, making it a replacement for both JPEG and GIF. Encoding speed is fast — comparable to JPEG. Browser support is universal in 2026. WebP's main weakness is that it can produce blurring and colour shifts in areas with fine detail at aggressive quality settings — something JPEG handles more gracefully.

AVIF achieves 40–60% smaller files than JPEG at equivalent quality. It handles gradients, fine textures, and low-contrast detail better than both JPEG and WebP. The trade-off is encoding speed — AVIF encoding is 5–20x slower than JPEG or WebP at comparable quality levels. Decoding is also slower, which can affect rendering performance on low-powered mobile devices. Browser support is now universal in modern browsers, but some older Android WebView versions and niche browsers may lack support.

Practical file size comparison​

For a typical 1600×900 photographic hero image at visually equivalent quality:

For a complex illustration with text and sharp edges:

AVIF's advantage grows with image complexity. For simple, low-detail images, the difference between WebP and AVIF narrows considerably.

When to use each format​

Use AVIF as the primary format for photographic hero images, product photography, editorial illustrations, and any image where file size savings justify the encoding time. The 50% reduction compared to JPEG compounds across every page load for every visitor.

Use WebP as the fallback for clients that do not support AVIF. At this point, WebP support is universal enough to serve as the sole fallback — you do not need a JPEG fallback chain for modern browser audiences.

Use JPEG as the baseline fallback only if you need to support extremely old browsers or non-browser clients (email clients, RSS readers, some social media crawlers) that may not handle WebP or AVIF.

The <picture> element handles format negotiation:

<picture>
  <source srcset="/img/hero.avif" type="image/avif">
  <source srcset="/img/hero.webp" type="image/webp">
  <img src="/img/hero.jpg" alt="Description" width="1600" height="900">
</picture>

Encoding workflow​

For static sites, encode images at build time in all formats:

# AVIF (quality 60, slower but smallest)
avifenc --min 30 --max 60 input.jpg output.avif

# WebP (quality 80, fast)
cwebp -q 80 input.jpg -o output.webp

# JPEG baseline (quality 80, for fallback)
jpegoptim --max=80 --strip-all input.jpg

For dynamic images (user uploads, CMS content), consider a CDN or image service that handles format negotiation and encoding on the fly — Cloudflare Images, imgproxy, or Thumbor. The encoding cost of AVIF makes on-the-fly encoding impractical for high-traffic sites without caching.

Quality calibration​

The quality numbers across formats are not comparable. AVIF quality 60 does not mean the same thing as JPEG quality 60 or WebP quality 60. Each format's quality scale maps differently to perceptual quality.

The reliable approach is to use a perceptual quality metric like SSIM or DSSIM to calibrate quality settings across formats. Encode at several quality levels, measure SSIM against the original, and choose the setting that achieves your target SSIM score (0.95+ is visually lossless for most content) at the smallest file size.

Tools like squoosh.app provide interactive quality comparison that makes visual calibration straightforward for individual images.

Build pipeline integration​

Most modern static site generators and bundlers support multi-format image generation. For Docusaurus, Astro, Next.js, and similar frameworks, image processing plugins can generate AVIF, WebP, and JPEG variants during build and output the appropriate <picture> markup.

For simpler setups, a build script that processes images with sharp (Node.js), Pillow (Python), or command-line tools like avifenc, cwebp, and jpegoptim integrates into any CI/CD pipeline. The encoding time for AVIF is the main consideration — budget 1–3 seconds per image at quality 60, which adds up for large image libraries.

The performance benefit is cumulative with compression (Brotli vs Gzip vs Zstd) and transport optimisation (HTTP/3). Smaller images compressed with Brotli over QUIC represent the optimal delivery path for image-heavy content in 2026.