AVIF vs WebP vs JPEG: the best image format for the web

AVIF vs WebP, in short: for photos, AVIF usually gives the smallest file at the same visual quality, especially at medium and low qualities, while WebP encodes much faster, is supported by slightly older devices and is the safer default for screenshots and graphics. Both work in every current browser and both are far smaller than JPEG. The best image format for a website is therefore AVIF or WebP for photos, SVG for logos and icons, and lossless WebP for screenshots, with a JPEG fallback where old devices matter. The pillar guide, image optimization for the web, puts format in context with size, compression and loading.

This guide compares the formats, gives the quality settings that produce the savings, and shows how to serve a fallback or let your CMS or CDN convert images automatically.

Quick answer

• Photos: AVIF at quality 50-65, or WebP at quality 75-82. Both look like a JPEG at quality 80 and weigh far less.
• Logos, icons, diagrams: SVG. Never a raster format for line art.
• Screenshots and flat graphics with transparency: lossless WebP, usually much smaller than the PNG.
• JPEG is still fine for a photo already under about 100 KB at its displayed size, for e-mail, and for the Open Graph image.
• Serve with <picture> (AVIF, then WebP, then JPEG), or let the server or CDN pick the format from the browser's Accept header.
• On WordPress, the Modern Image Formats plugin or an optimisation plugin converts uploads; on Shopify the CDN already does it.

AVIF vs WebP compared

Google's WebP compression study found lossy WebP files 25-34 % smaller than JPEG at the same measured quality. AVIF, from the AV1 video codec, keeps smooth gradients, skies and skin tones clean at low qualities where JPEG shows blocks and WebP smears, which is where its advantage over WebP is largest. How much smaller it is depends on the image, so compare both on a few of your own photos: the image compressor converts them in your browser, without uploading, and shows the size before and after for each format you try.

The trade-offs of AVIF are encoding time (several times slower than WebP at the higher-effort settings, which matters in a build step or on a busy server converting on upload) and support on devices that have not been updated in years. Neither matters much with a fallback. JPEG XL is not yet supported in all major browsers, so it is not a web default in 2026.

Why the format matters for speed

The biggest image on a page is usually the Largest Contentful Paint element. As an example, a 480 KB JPEG hero takes about 0.8 s to transfer on a 5 Mbit/s mobile connection; the same image at 140 KB takes about 0.2 s. That can be the difference between an LCP of 3.1 s and 2.5 s, Google's threshold for "good".

Resizing an image changes what the visitor sees (fewer pixels); changing the format keeps the pixels and stores them more efficiently. Do both, in that order: size first, then format.

How getReport checks it

The speed module reads Lighthouse's image delivery results from the PageSpeed Insights run. Lighthouse used to call this audit "Serve images in next-gen formats"; in Lighthouse 13 it is part of the "Improve image delivery" insight. Either way it estimates how many bytes each JPEG and PNG would save in a modern format. The practices module also fetches every <img> directly and flags files over 300 KB, whatever their format.

The technical line lists the files, biggest saving first: that is your work order. An image that is heavy because it has far too many pixels appears in the heavy-files finding instead, and format alone will not fix it; read the best image size for a website first.

Step 1: sort the images into three piles

Open the report's images table (the image size checker shows it on top) and sort each row:

• Photographs: product shots, hero images, team photos. AVIF or WebP.
• Line art: logos, icons, flat illustrations, charts. SVG; if you only have a PNG, lossless WebP.
• Screenshots and UI: sharp edges and text. Lossless WebP, or lossy WebP at quality 90 if the file is large.

The first pile is where the savings are. A catalogue of 40 product photos as 200 KB JPEGs typically sheds megabytes when re-encoded.

Step 2: pick the quality settings

Quality numbers are not comparable between formats: WebP 80 and AVIF 80 are different things. Settings that match the look of a JPEG at quality 80-85:

Higher is not better. WebP at q 100 or AVIF at q 90 is often larger than the original JPEG. Open the original and the converted file side by side at 100 % zoom and pick the lowest quality where you cannot tell them apart.

Step 3: convert

The reference encoders are free and run everywhere:

# One photo to WebP at quality 80
cwebp -q 80 hero.jpg -o hero.webp

# The same photo to AVIF at quality 55, speed 6 (lower is slower and smaller)
avifenc -q 55 -s 6 hero.jpg hero.avif

# A whole folder to WebP
for f in *.jpg; do cwebp -q 80 "$f" -o "${f%.jpg}.webp"; done

In a Node build, sharp resizes and converts in one step:

// convert.js: run with: node convert.js
import sharp from 'sharp';

await sharp('hero.jpg').resize({ width: 1600 }).webp({ quality: 80 }).toFile('hero.webp');
await sharp('hero.jpg').resize({ width: 1600 }).avif({ quality: 55, effort: 4 }).toFile('hero.avif');

For up to 50 images at a time, the image compressor does the same in your browser, with the codecs Squoosh uses.

Step 4: serve with <picture> and a fallback

The <picture> element lists sources in order of preference; the browser takes the first type it supports:

<picture>
  <source srcset="/img/hero.avif" type="image/avif">
  <source srcset="/img/hero.webp" type="image/webp">
  <img src="/img/hero.jpg" width="1600" height="900" alt="Blue running shoe on a white background" fetchpriority="high">
</picture>

Everything that belongs to the image (width, height, alt, loading, fetchpriority, and srcset and sizes for responsive sizes) stays on the <img>; the <source> elements only offer formats. Templates that already use srcset keep it on each <source> and on the <img>.

Step 5: or let the server choose

Content negotiation keeps the HTML unchanged: the server reads the Accept header (Chrome sends image/avif,image/webp,…) and returns the best file that exists. With hero.jpg.avif and hero.jpg.webp beside hero.jpg, on nginx:

# In the http block: which suffix the browser accepts, best first
map $http_accept $img_suffix {
    default        "";
    "~*image/avif" ".avif";
    "~*image/webp" ".webp";
}

# In the server block
location ~* ^/img/.+\.(jpe?g|png)$ {
    add_header Vary Accept;
    try_files $uri$img_suffix $uri =404;
}

Vary: Accept is not optional: without it a CDN caches the AVIF answer and serves it to a browser that asked for JPEG.

Image CDNs do this without configuration: Cloudflare Polish (paid plans) serves WebP to browsers that accept it, Cloudflare's image transformations and Cloudinary pick the format with format=auto and f_auto, imgix with auto=format. Image CDNs and on-the-fly resizing compares them.

Step 6: leave the JPEGs that are fine

Skip photos already under about 100 KB at their displayed size, images in e-mail templates (several desktop mail clients still do not show WebP or AVIF), the Open Graph image (keep it a 1200×630 JPEG or PNG, which every platform previews), and files meant for download or print.

Platform notes

• WordPress accepts WebP uploads since 5.8 and AVIF since 6.5 (when the server's image library supports it), but does not convert your JPEGs. The Modern Image Formats plugin from the WordPress performance team generates WebP or AVIF versions of new uploads (choose under Settings → Media); existing images need their sizes regenerated. ShortPixel, Imagify and EWWW convert the existing library in bulk and serve it through <picture> or rewrite rules. Check that a hard-coded theme hero image is covered too.
• Shopify's CDN serves modern formats automatically for images output with image_url; files hard-coded in the theme's assets folder are not converted.
• Static sites: Astro, Eleventy and Next.js image components convert at build time with sharp.

How to verify

• Re-run the speed test: the format finding passes and fewer files are over 300 KB. Watch LCP if the hero was converted.
• In Chrome DevTools → Network, filter by Img and read the Type column: webp or avif, not jpeg.
• From a terminal: curl -sI -H "Accept: image/avif,image/webp,*/*" https://example.com/img/hero.jpg | grep -i -E "content-type|vary" should show image/avif and vary: Accept when you negotiate on the server.

Common mistakes

• Renaming photo.jpg to photo.webp. The bytes are still JPEG; browsers sniff the content, so it displays, but nothing got smaller.
• Quality 100. A near-lossless WebP is often bigger than the JPEG it replaces.
• Lossy formats for logos and screenshots. Sharp edges smear and text gets halos. SVG for logos, lossless WebP for screenshots.
• Negotiating without Vary: Accept. A shared cache serves AVIF to a browser that cannot show it.
• Converting a 4000 px image. Format saves a share; sending 400 px to a 400 px slot saves nearly everything. Resize first (srcset and sizes), then convert.

Questions people ask

Is AVIF better than WebP?

For photos, usually yes: AVIF typically produces a smaller file at the same visual quality and keeps gradients cleaner at low qualities. WebP encodes much faster, often matches AVIF on screenshots in lossless mode, and runs on slightly older devices. Serve AVIF first with WebP as the fallback, or pick WebP alone if encoding time on your server matters more than the last few kilobytes.

What is the best image format for websites?

It depends on the image. Use AVIF or WebP for photographs, SVG for logos, icons and simple illustrations, and lossless WebP for screenshots and graphics with transparency. Keep a JPEG fallback for photos if you serve visitors on very old devices, and keep the Open Graph image a JPEG or PNG. Resize every image to its displayed size before choosing the format.

What does "serve images in next-gen formats" mean?

It is Lighthouse's advice to replace JPEG and PNG files with modern formats such as WebP or AVIF, which store the same image in fewer bytes. The finding lists each file with the kilobytes it would save. In Lighthouse 13 the same check is part of the "Improve image delivery" insight. Convert the listed files, biggest saving first, and serve them with a fallback.

Why is my AVIF file bigger than the WebP or JPEG?

Usually the quality setting is too high. AVIF quality numbers are not comparable with JPEG or WebP ones: quality 80 or 90 in AVIF is near-lossless and often larger than a JPEG at 80. Try quality 50-65 for photos and compare side by side at 100 % zoom. For screenshots and flat graphics, lossless WebP is often smaller than AVIF.

Do I still need a JPEG fallback for WebP and AVIF?

For most sites it is optional but cheap. Every current browser shows WebP and AVIF, so the fallback only serves visitors on devices that have not been updated in years, plus some e-mail clients and link-preview crawlers. With <picture> or an image CDN the fallback costs nothing at page load, because each browser downloads only one format.