AVIF vs WebP, decided

What the numbers actually say

Start with the claims each project makes about itself, because they set the expectations everyone else repeats. Google’s WebP FAQ states that lossy WebP averages 30% more compression than JPEG at equivalent quality, that lossless WebP is 26% smaller than PNG, and that lossy animated WebP is 64% smaller than the same animation as a GIF. Those are Google’s own measurements on Google’s own corpus, so treat them as a ceiling rather than a promise.

For AVIF the most useful public evidence is still Netflix’s evaluation, published on 13 February 2020, which ran AVIF against JPEG, JPEG 2000, WebP and HEIC across five datasets (Kodak, CLIC, Billboard and two Boxshots sets) using PSNR, SSIM, MS-SSIM and VIF. The side-by-side examples are the part worth quoting because they are concrete: one Kodak image at 13,939 bytes as JPEG 4:4:4 against 4,176 bytes as AVIF 4:4:4 at comparable quality, and a Netflix boxshot at 69,445 bytes as JPEG against 40,811 bytes as AVIF. That is a 70% cut in one case and 41% in the other, on the same encoder, which tells you most of what you need to know about single-number comparisons.

The rule of thumb that has held up for us: on photographs at web quality, expect AVIF around 20% to 30% smaller than WebP, and both comfortably smaller than JPEG. The variance between individual images is larger than the difference between the formats, so run your own corpus before rebuilding a pipeline on a blog post’s percentage.

If you want a serious quality study rather than vendor numbers, the one to know is Cloudinary’s CID22 dataset, assembled by Jon Sneyers and colleagues: 250 pristine source images compressed with JPEG, JPEG 2000, JPEG XL, HEIC, WebP and AVIF at high fidelity, producing 22,153 annotated images scored from roughly 1.4 million human opinions. Its main lesson is unglamorous. At high fidelity the modern formats sit much closer together than the marketing gap suggests, and the differences only open up as you push quality down.

Browser support, with dates

WebP was announced by Google in 2010, built on VP8 intra-frame coding, and spent most of a decade as the format Chrome supported and nobody else did. The wait ended with Safari 14 in September 2020; Firefox had landed it in 65 the year before. Since then WebP has been effectively universal, which is why so many sites still stop there.

AVIF is a still image stored as an AV1 keyframe in the ISOBMFF container, specified by the Alliance for Open Media in version 1.0.0 in February 2019. Chrome 85 shipped it in August 2020, so AVIF support and WebP’s last holdout arrived within weeks of each other. Firefox 93 enabled it by default in October 2021 after a long stint behind a preference, and Safari 16.4 completed the set in March 2023. caniuse now puts global AVIF availability above 90%, so a fallback exists for old iOS devices and embedded webviews, not for anybody’s daily driver.

The encoding cost nobody mentions

This is the difference that decides real architectures, and comparison posts skip it because it does not fit in a file-size table. Encoding AVIF is expensive. An AVIF file is an AV1 keyframe, and AV1 encoders find those bytes by searching an enormous space of block partitions, transforms and prediction modes. That search is the compression.

The tradeoff is exposed directly: avifenc takes a speed value from 0 to 10, where 0 is the slowest and smallest and 10 is quick and noticeably worse. The slow end costs seconds of CPU per megapixel; cwebp finishes the same image in a small fraction of that time. Two consequences follow.

• Build-time resizing: not a problem. If your images are processed once per deploy and cached forever, spend the CPU and use a slow speed setting. This is what a static site generator’s image pipeline does.
• On-the-fly resizing: a real problem. If a request for an unseen size triggers an encode, AVIF turns a cheap origin miss into an expensive one, and a cold cache after a deploy can pin your image servers. Either pre-generate the sizes you actually use, or encode at a faster speed setting and accept the larger files.

Decoding is the other side and it is less dramatic, but AVIF decoding is still measurably heavier than WebP’s. On a cheap Android phone, a page full of large AVIFs can trade transfer time for main-thread time, which is not the trade you wanted if you were optimising Largest Contentful Paint.

Where WebP still wins

AVIF is not a strict upgrade, and pretending otherwise leads to pipelines that ship the bigger file. Three cases where WebP comes out ahead:

• Lossless. WebP’s lossless mode was designed for exactly this and generally produces smaller files than AVIF lossless. For screenshots, UI assets and anything with sharp text edges that must stay pixel-exact, WebP is the better choice.
• Flat graphics and illustrations. Logos, charts and diagrams have low entropy, so the sophisticated prediction machinery in AV1 has little to find, and the gap narrows to nothing or reverses.
• Very small images. AVIF’s container carries more structural overhead than WebP’s RIFF container. Under a few kilobytes, an icon or a thumbnail can genuinely come out larger as AVIF than as WebP, which is worth checking rather than assuming.

The practical version: generate both, compare the byte counts per image, and keep the smaller one. Every decent image pipeline can be told to do that, and it removes the argument entirely.

HDR, 10-bit and hard limits

Beyond compression, the formats have different capability ceilings, and two of them are dealbreakers rather than preferences.

Lossy WebP is 8-bit 4:2:0 only, a direct inheritance from VP8. No 10-bit, no HDR, no wide-gamut signalling worth the name. If you publish photography where colour banding in gradients matters, or you are serving HDR content to displays that can show it, WebP cannot carry it. AVIF supports 8, 10 and 12-bit depth, 4:2:0 through 4:4:4 chroma, and the HDR transfer functions (PQ and HLG) with proper colour primaries.

The other hard limit is dimensional. A WebP image can be at most 16383 by 16383 pixels, straight from Google’s own FAQ, because that is what the VP8 bitstream allows. Encoders simply refuse anything larger. Panoramas, scanned maps, large product zoom images and stitched screenshots all run into this, and there is no flag that raises it. AVIF has no comparable low ceiling.

One thing both formats share: they can carry EXIF and XMP metadata, and most converters copy it across by default. If your source photos came off a phone, that metadata may include GPS coordinates, which is its own kind of problem and one we wrote about separately in what your photos reveal about where you were. Strip metadata explicitly in your pipeline rather than hoping the encoder dropped it.

The JPEG XL detour

Any honest AVIF vs WebP article has to mention the third format, because the answer might change. JPEG XL is technically excellent: better than both on high-fidelity photographic content in most published comparisons, with progressive decoding and a lossless JPEG recompression mode that shrinks existing JPEGs by around 20% and can restore the original file bit for bit.

The browser story has been a mess. Chrome carried a JPEG XL decoder behind a flag, then Google announced its removal in late 2022 citing insufficient ecosystem interest over the existing formats, and it was gone from Chromium by the end of that year. Apple went the other way and shipped JPEG XL in Safari 17 in September 2023, across macOS, iOS and iPadOS, with the caveats that it does not do animation or progressive decoding there.

The situation moved again in November 2025, when Chromium reopened the issue and Google engineers began work on adding a JPEG XL decoder back to Blink, this time built on the memory-safe Rust implementation jxl-rs, with animation support in the patch. As we write this it is not enabled by default in Chrome, and dates for that keep moving, so treat any specific prediction with suspicion. For now: keep an eye on it, do not rebuild your pipeline around it, and if you do add JXL, add it as an extra source above AVIF rather than in place of anything.

Serving both without breaking anything

There are two mechanisms, and mixing them up causes the classic bug where everyone gets the wrong image.

The first is the <picture> element. You list <source> entries with type="image/avif" and type="image/webp", ending with a plain <img> carrying a JPEG or PNG. The browser walks the list in order and takes the first type it can decode, so put AVIF first. It does not compare file sizes, and it does not reconsider: if the first supported entry is a 400 KB AVIF and the WebP below it is 90 KB, everyone gets the 400 KB file. Always set width and height on the <img> so the browser can reserve the space and you do not pay for the format win in layout shift.

The second is content negotiation at the CDN, where the origin looks at the Accept request header (Chrome sends image/avif,image/webp in it) and returns a different body for the same URL. It keeps your markup clean and it has one requirement people forget: the response needs Vary: Accept. Without it, a shared cache stores whichever variant it saw first and serves an AVIF to a browser that cannot decode it, or a JPEG to everyone for the next year. That failure mode and its relatives are covered in our guide to HTTP caching headers, which is the other half of getting images fast.

If you use a framework’s image component, all of this is already handled. Astro’s Picture component, Next.js’ Image and the equivalents in Nuxt and SvelteKit generate the AVIF and WebP variants at build time, emit the full <picture> markup with a srcset per format, and set the dimensions for you. Writing that by hand is a fine way to learn it once and a bad way to maintain it.

What we ship

AVIF first, WebP as the fallback, original JPEG or PNG at the bottom for the long tail, all generated at build time and cached with a content hash. Lossless assets and flat graphics get WebP or PNG instead, chosen by comparing the actual output sizes rather than by rule. Nothing gets encoded at request time unless there is a good reason.

The part worth saying out loud: images are almost always the biggest thing on a page, and a format switch is a bigger performance win than most of the work that gets prioritised over it. Shaving kilobytes off a JavaScript bundle is satisfying, but the arithmetic rarely competes, which is a point we make in the minify vs uglify vs obfuscate comparison as well. Convert the hero image first, then argue about the minifier.

AVIF and WebP in practice