WebP vs AVIF for websites: size, quality and support
AVIF is usually smaller than WebP at the same quality but encodes more slowly. All major browsers now support both, so serve AVIF with a WebP fallback.
LLaunchScaler·Published ·8 min read
For a website, AVIF usually gives the smaller file at the same visual quality, while WebP encodes faster, renders progressively and reaches a slightly wider set of browsers. Both work in every current major browser, so the practical answer is to serve AVIF first, WebP second and JPEG or PNG last, from one <picture> element or an image CDN.
The format is the second decision, though. An image four times wider than the slot it sits in stays slow in any format, so size first and convert second.
How do WebP and AVIF compare?
AVIF wins on compression and loses on encode time and progressive rendering. WebP is the steadier all-rounder: fast to encode, supported for years, and still far smaller than JPEG or PNG. The table puts the measured and documented differences side by side, each from the format's own documentation or a browser vendor.
WebP
AVIF
File size
Lossy is 25 to 34% smaller than JPEG at equal SSIM; lossless is 26% smaller than PNG (Google)
About 20% smaller than WebP (Next.js); web.dev reports over 50% savings against JPEG, varying with content and settings
Encode time
Fast
Next.js says it "generally takes 50% longer to encode" than WebP
Progressive rendering
Yes
No; MDN notes the file must download fully before it displays
Questions, answered
What people ask about this
01
Is AVIF better than WebP?
AVIF usually produces a smaller file at the same visual quality; Next.js puts it at about 20% smaller than WebP. WebP encodes faster, renders progressively and has slightly wider support, so most sites serve AVIF first and WebP as the fallback.
MDN's summary matches the table: it calls WebP an "excellent choice" and says AVIF "offers slightly better compression, but is not quite as well-supported in browsers and does not support progressive rendering."
Which is better for image quality: WebP or AVIF?
AVIF usually reaches the same visual quality in fewer bytes, and it supports higher color depths than JPEG or PNG, according to MDN. WebP is close behind: MDN calls AVIF's compression only "slightly better". The gap depends on the image, so compare your own hero image at matched quality rather than trusting a single percentage.
Two quality settings are worth knowing before you compare, because the numbers do not mean the same thing across encoders:
cwebp takes -q from 0 to 100 with a default of 75.
sharp defaults to quality 80 for webp() and 50 for avif(), with an effort option (0 to 6 for WebP, 0 to 9 for AVIF, default 4) that trades encode time for size.
So "quality 50" in AVIF is not a lower bar than "quality 80" in WebP; the scales differ. Judge by eye at the size the image will be displayed, then compare bytes. web.dev points to Squoosh (squoosh.app), which runs the AVIF encoder in the browser, for quick comparisons.
Is AVIF supported in all browsers?
Yes, in all current major browsers: Chrome 85 and later, Firefox 93 and later, Edge 121 and later, and Safari with full support from 16.4 on macOS and 16.0 on iOS. What it lacks is historical depth. Visitors on older Safari or Edge versions need a fallback, and MDN recommends providing one in WebP, JPEG or PNG.
WebP has the longer history: Chrome since 32, Firefox since 65, Edge since 18 and full Safari support since 16.0 on macOS. caniuse put full support at about 97% of global usage for WebP and about 95% for AVIF in September 2026. Those gaps are small, but they are real visitors, and a fallback costs you one extra <source> line.
How do you serve both with a picture element?
List the formats from smallest to most compatible inside <picture>. The browser takes the first <source> whose type it supports and ignores the rest, and the <img> inside is both the fallback and the element that carries alt, width, height and loading hints.
Export the master image at the largest width you will ever display, then resize to each width in your srcset (here 800 and 1,600 pixels).
Encode each width to AVIF, for example with avifenc --min 0 --max 63 -a end-usage=q -a cq-level=18 -a tune=ssim hero-800.png hero-800.avif, the settings web.dev suggests as a starting point.
Encode each width to WebP, for example cwebp -q 75 hero-800.png -o hero-800.webp.
Keep a JPEG (or PNG for flat graphics and transparency) at each width for the <img> fallback.
Compare the three files per width. If the AVIF is not smaller than the WebP for a given image, drop the AVIF source for that image.
Keep width and height on the <img> so the browser reserves space before the image arrives. The alt text rules are the same whatever the format; the alt text best practices cover what to write.
How do you set WebP and AVIF in Next.js?
Set images.formats in next.config.js. The default is ['image/webp']. To add AVIF, put it first, because Next.js reads the request's Accept header and serves the first format in the array that matches, falling back to the source image's format when nothing matches or the image is animated.
The Next.js docs attach four caveats to that setting:
They still recommend WebP for most use cases.
AVIF takes about 50% longer to encode, so the first request for each image size is slower; cached requests after that are faster.
Each format is cached separately, so storing both roughly doubles optimized-image storage.
If you self-host behind a proxy or CDN, it must forward the Accept header, or every visitor gets the same format.
next/image also generates the srcset for you from deviceSizes (default [640, 750, 828, 1080, 1200, 1920, 2048, 3840]) and imageSizes, provided you pass a sizes prop that describes how wide the image renders.
Can the server pick the format instead of a picture element?
Yes. The browser sends an Accept header listing the image types it can decode with every image request, and a server, image CDN or next/image can read it and return AVIF, WebP or JPEG from a single URL. The one rule that makes this safe is caching: the response must say which header decided it.
That is what the Vary header is for. MDN explains that a cache needs to know which request headers the server used to choose the content, so it can replay that choice and serve an acceptable variant without asking the server again. Send Vary: Accept on every negotiated image. Without it, a shared cache can store the AVIF answer and hand it to an older browser that asked for WebP, and that visitor sees a broken image.
Check it on a live image with curl -sI -H "Accept: image/avif,image/webp,*/*" https://yoursite.com/hero.jpg, then repeat with -H "Accept: image/webp,*/*". The Content-Type should change between the two requests, and both responses should carry Vary: Accept.
Why doesn't a new format fix an oversized image?
Because the format changes bytes per pixel, not the number of pixels. A 4,000 pixel wide photo in a 400 pixel slot sends about 100 times the pixels the slot can show (ten times the width, ten times the height), and even a 50% format saving leaves it far heavier than a correctly sized JPEG.
Lighthouse checks this directly. It compares each image's rendered size with its actual size and fails the image when the rendered size is at least 4 KiB smaller. In Lighthouse 13 that audit, the modern image formats audit and the image optimization audit were merged into one image delivery insight, so format and sizing now appear together.
The order of work that pays off:
Size each image to its largest displayed width, and use srcset with sizes for responsive layouts.
Load the largest above-the-fold image eagerly with fetchpriority="high" and never with loading="lazy".
Serve AVIF with a WebP fallback for photos and large hero images, where AVIF's size advantage is largest and the image is encoded once and cached. Use WebP alone when encode time matters, such as user uploads converted on the fly, or when you can only store one format.
Your situation
Serve
Photos and hero images, built once at deploy
AVIF, then WebP, then JPEG
Images converted on request with little caching
WebP, then JPEG
Flat graphics, logos, icons
SVG where possible; otherwise compare lossless WebP and PNG
Transparent product shots
AVIF or WebP with alpha, PNG fallback
Next.js with next/image
formats: ['image/avif', 'image/webp'] if storage and first-request latency are acceptable; the default WebP otherwise
Google Search lists both WebP and AVIF among the formats it supports for images, so the choice is about speed and your build pipeline rather than eligibility.
To see which images on a live page are too heavy, run the free scan on LaunchScaler. It needs only your URL and no account, and its speed checks flag legacy JPEG and PNG files that would be meaningfully smaller as AVIF or WebP, images delivered far above their display size, a lazy-loaded LCP image and images rendered without reserved dimensions, among 156 checks across 6 of its 7 categories.
All current major browsers do: Chrome from 85, Firefox from 93, Edge from 121 and Safari with full support from 16.4 on macOS and 16.0 on iOS. Older Safari and Edge versions do not, which is why you keep a WebP or JPEG fallback.
03
Should I use WebP or AVIF for my website?
Use both through a picture element or an image CDN that reads the Accept header, with AVIF first, WebP second and JPEG or PNG last. If you can only produce one format, WebP is the safer single choice.
04
Does converting to AVIF fix a slow Largest Contentful Paint?
Only partly. A smaller format helps, but an image served at four times its display width, lazy-loaded above the fold or discovered late will still be slow. Size the image to its slot first, then change the format.
05
Does WebP or AVIF affect SEO?
Google Search supports both formats for images. The SEO effect comes from speed: a lighter image can load sooner, which helps Largest Contentful Paint, one of the Core Web Vitals.
