WebP vs AVIF vs JPEG: Choosing an Image Format

WebP and AVIF are modern image formats that generally produce smaller files than JPEG at equivalent visual quality, but they differ from each other and from JPEG in compression efficiency, encode speed, and browser support — and the right choice depends on which of those trade-offs matters most for a given image. Since images are typically the largest chunk of a page’s total weight, this choice has a direct, measurable effect on load time.

How each format compresses

JPEG uses a decades-old lossy compression scheme based on discrete cosine transforms applied to 8×8 pixel blocks. It’s universally supported and fast to encode and decode, but its compression efficiency is noticeably behind newer formats, and it doesn’t support transparency (an alpha channel) or animation.

WebP, developed by Google, supports both lossy and lossless compression, transparency, and animation, and typically produces 25-35% smaller files than JPEG at comparable visual quality for photographic images. It’s built on the same intra-frame prediction ideas as the VP8 video codec.

AVIF, based on the AV1 video codec’s intra-frame compression, generally compresses even further than WebP — particularly at lower quality settings and on images with large flat color areas or fine detail — at the cost of meaningfully slower encoding. AVIF also supports transparency, animation, and a wider color gamut (HDR) than either WebP or JPEG.

Comparison table

	JPEG	WebP	AVIF
Typical size vs JPEG	Baseline	~25-35% smaller	~30-50% smaller
Transparency	No	Yes	Yes
Animation	No	Yes	Yes
Encode speed	Fast	Moderate	Slow
Browser support	Universal	Broad, modern browsers	Broad, modern browsers
Best for	Maximum compatibility	General-purpose replacement for JPEG/PNG	Maximum compression where encode time doesn’t matter

Why AVIF’s slower encoding matters

AVIF’s compression advantage comes from a much more computationally expensive encoding process — it searches a larger space of prediction modes and block partitions than JPEG or WebP. For a one-time build step generating a handful of hero images, that cost is irrelevant. For a service generating thousands of user-uploaded images on demand, or for developers iterating quickly during a build, the slower encode time is a real operational cost worth weighing against the smaller file size it buys.

Serving the right format with fallbacks

Because browser support, while broad, isn’t universal, the safe pattern is the <picture> element with multiple <source> entries, letting the browser pick the first format it supports:

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

The browser evaluates <source> elements in order and uses the first one whose type it supports, falling back to the plain <img> if none match. This means you only pay AVIF’s larger encode-time cost once per build, while every visitor still gets the smallest format their browser can decode. Frameworks with built-in image components — Astro’s <Image />, Next.js’s Image, and similar — typically generate this exact fallback chain automatically from a single source image, which is usually worth using instead of hand-rolling it.

Where format choice fits in the bigger performance picture

Choosing a smaller format is one lever among several for image performance, and not always the highest-leverage one. Serving an appropriately sized image for the viewport (rather than a large image scaled down by CSS), applying lazy loading to offscreen images, and setting explicit width and height attributes to prevent layout shift typically matter as much or more than the codec itself — a correctly sized JPEG can easily beat an oversized AVIF. Image weight also directly affects Core Web Vitals, particularly Largest Contentful Paint when the hero image is above the fold, and how quickly the browser can even start fetching it depends on the critical rendering path and whether it’s preloaded.

For images served repeatedly across visits, proper HTTP caching headers matter more than shaving a further few percent off file size, since a well-cached JPEG a returning visitor doesn’t re-download beats an AVIF they do. And serving images from a CDN close to the visitor often has a bigger effect on load time than the format difference between WebP and AVIF.

Practical guidance

For new projects without strict legacy browser requirements, WebP is a safe universal upgrade from JPEG and PNG with minimal downside. AVIF is worth adding as the first <source> option when squeezing out maximum compression matters — image-heavy content sites, mobile-first audiences on constrained bandwidth — and the build-time encode cost is affordable. Keep a JPEG (or WebP) fallback in the chain regardless; the marginal size cost of maintaining one is far smaller than the cost of a broken image for whatever fraction of visitors doesn’t support the newest format yet.

The takeaway

AVIF generally compresses smallest, WebP is a strong universal middle ground with faster encoding, and JPEG remains the safest fallback with the widest support. Serve all three through a <picture> element so each visitor gets the smallest format their browser supports, and remember that format choice is only one of several levers — correct sizing, lazy loading, and caching often move the needle just as much.