WebP vs AVIF vs JPEG: choosing image formats for the modern web

Picking an image format for a modern website is no longer a one-line decision. JPEG, the format that defined the web's first 25 years, is still the most universally compatible — but two newer formats, WebP and AVIF, both compress significantly better at the same visual quality. Choosing between them is now a real engineering decision, with trade-offs around browser support, encode speed, file size, and the complexity of shipping fallbacks.

This article walks through what each format actually does, when each one is the right choice, and how to deploy them in production without breaking older browsers.

The three formats in one paragraph each

JPEG (1992)

JPEG is the universal photographic image format. Every browser, every operating system, every email client, every social platform reads JPEG. It uses lossy DCT-based compression that performs well on photographic content — natural colours, gradual transitions, organic detail — and badly on graphics with sharp edges, text, or large flat areas. JPEG quality is set on a 1-100 scale where 90+ is essentially indistinguishable from the source and 75-85 is the sweet spot for web delivery.

WebP (2010)

Google's image format, originally derived from the VP8 video codec. WebP supports both lossy and lossless modes plus full alpha transparency — meaning a single format covers the JPEG and PNG use cases. At lossy mode, WebP files are typically 25-35% smaller than equivalent JPEG at the same visual quality. Browser support is universal in 2026 (Chrome since 2010, Firefox since 2019, Safari since 2020, Edge since the Chromium switch).

AVIF (2019)

Derived from the AV1 video codec, AVIF is the newest of the three. It compresses even more aggressively than WebP — typically 30-50% smaller than WebP at the same visual quality, and 50%+ smaller than JPEG. It supports HDR colour, 12-bit depth, and full transparency. The trade-off is encode time (AVIF is much slower to encode than WebP, which is much slower than JPEG) and slightly less universal browser support (Chrome since 2020, Firefox since 2021, Safari since 2022/2023 depending on platform).

File size comparison: a real example

A typical 1920×1080 photographic image of a sunset, encoded at visually-equivalent quality settings:

• JPEG (quality 85): ~280 KB
• WebP (quality 80): ~190 KB (32% smaller than JPEG)
• AVIF (quality 65): ~120 KB (57% smaller than JPEG, 37% smaller than WebP)

The savings compound across a typical webpage that ships 8-15 images: AVIF page loads can be megabytes lighter than JPEG-only pages, which translates directly to faster Core Web Vitals scores and better mobile performance on slow networks.

When to use each format

Use JPEG when...

• You're shipping images to extremely old browsers or environments that don't support modern formats (rare in 2026 but still relevant for some enterprise contexts).
• You're producing email-embedded images. Email clients often don't support WebP/AVIF; JPEG is the only safe bet.
• You're feeding images into a downstream tool that requires JPEG specifically (some CMS plugins, some legacy image-processing pipelines).
• The savings from WebP/AVIF aren't worth the deployment complexity for your use case.

Use WebP when...

• You want a single format that works for both lossy photography and lossless graphics with transparency (so it can replace both JPEG and PNG).
• You want better compression than JPEG without the encode-time cost or browser-support concerns of AVIF.
• You're deploying a content site, ecommerce site, or web app where the WebP-vs-JPEG difference compounds across hundreds of images per page view.
• You don't have an image CDN that handles AVIF generation for you, and you don't want to maintain a separate AVIF encoding pipeline.

Use AVIF when...

• Image bandwidth is a meaningful cost or a meaningful performance bottleneck (high-traffic sites, mobile-heavy audiences, slow-network markets).
• You're shipping a hero image, a key marketing asset, or any image where load time directly affects conversion.
• You have a CDN or build pipeline that handles the slower AVIF encoding for you (Cloudflare Images, Cloudinary, Fastly Image Optimization, Vercel Image Optimization, etc.).
• Your audience skews modern (consumer-facing apps, design audiences, technology-forward markets) where AVIF support is now near-universal.

Shipping safely with fallbacks

The right pattern for using modern formats on the web is the HTML <picture> element with multiple <source> entries:

<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="Hero image" width="1920" height="1080" />
</picture>

The browser walks the list top-to-bottom and uses the first format it supports. Modern browsers get AVIF; slightly older browsers get WebP; very old browsers fall back to JPEG. Every visitor sees the smallest file their browser can decode — automatically, without any JavaScript.

The trade-off is build complexity: you now produce three versions of every image instead of one. For sites with hundreds of images, this requires either a build-time pipeline (sharp, ImageMagick, libvips) or a CDN that does it on the fly. For small sites with a few hero images, hand-encoding is fine.

Common gotchas

Don't double-encode lossy formats

Converting a JPEG to WebP doesn't recover the quality the JPEG threw away. Converting a WebP back to JPEG throws away even more. Always encode each format separately from the highest-quality source you have (PNG, TIFF, or RAW). Don't chain lossy conversions.

Use lossless WebP for graphics, lossy WebP for photos

WebP is two formats in one — lossy (similar to JPEG) and lossless (similar to PNG). Most encoders default to lossy, which is wrong for logos, screenshots, and icons. Specify lossless mode when encoding non-photographic content; the resulting WebP will be smaller AND sharper than a lossy WebP of the same image.

Test on real devices, not just emulators

AVIF support varies subtly across operating systems and browser versions even when caniuse.com says supported. An iPhone running iOS 16 has different AVIF support than one running iOS 17. A Mac running an older Safari renders some AVIF features differently. Test your important images on real devices before committing to AVIF-only delivery.

The pragmatic answer

If you're starting a new project in 2026: ship AVIF as the primary format with WebP and JPEG fallbacks via <picture>. Use a CDN or build pipeline to generate all three. Your users get the fastest loads their browsers can deliver, and your fallbacks cover the long tail.

If you're working on an existing project where adding a build pipeline isn't feasible: ship WebP with JPEG fallbacks. You get most of the savings of AVIF with a fraction of the deployment complexity, and WebP's browser support is essentially universal.

If you control no infrastructure and just need a simple solution: stick with JPEG. The format won't ever go away, and modern JPEG encoders (mozjpeg, libjpeg-turbo) compress better than the JPEG encoders of 10 years ago. The performance difference vs WebP is real but not catastrophic for content sites.

Convert images now: PNG to WebP, PNG to AVIF, or JPG to WebP. Free, no signup, instant download.