AVIF vs WebP: Which Modern Format Wins?

WebP arrived in 2010, introduced by Google as a replacement for JPEG and PNG on the web. Its lossy mode is built on intra-frame VP8 video coding — the same codec Google used in the WebM container. Google later extended WebP to include a separate lossless mode (using a bespoke LZ77-based predictor), an alpha channel for both modes, and an animation container. Because Google controlled Chrome and Android, WebP adoption grew steadily even before other browser vendors committed to it.

AVIF is newer. The Alliance for Open Media published the AVIF specification in 2019, roughly nine years after WebP. AVIF is the still-image profile of AV1, the royalty-free video codec that major technology companies — Google, Apple, Mozilla, Microsoft, Netflix, Amazon, and others — developed collaboratively. The image data sits in an ISOBMFF container (the same box structure as MP4), and each frame is encoded as an AV1 intra-frame. Because AV1 was designed to be a best-in-class video codec from the outset, AVIF inherits a much more powerful compression toolkit than WebP, which adapted an older video codec.

The practical consequence of that nine-year gap is that AVIF generally achieves smaller files at matched visual quality, but WebP has a longer track record and broader compatibility with older devices and software. Neither format is obsolete; they serve overlapping but not identical needs.

WebP's lossy mode divides images into 4×4 and 8×8 blocks and applies VP8's prediction and DCT-like transform. This is substantially better than JPEG's fixed 8×8 DCT, but the block size is still relatively small compared to AVIF. WebP's lossless mode uses a palette-based predictor combined with entropy coding that is well-suited to flat-color graphics, icons, and synthetic imagery.

AVIF uses AV1's superblock structure with variable block sizes up to 128×128 pixels, along with more sophisticated directional intra-prediction modes, a loop filter, constrained directional enhancement filtering (CDEF), and a restoration filter. Together these produce cleaner gradients, sharper edges at low bitrates, and less blocking than WebP at equivalent file sizes. The entropy coding in AV1 is also newer than VP8's.

In practice the compression advantage of AVIF over WebP exists across most photographic content, though the magnitude varies by image type. Smooth continuous-tone images (sky, skin, background blurs) show a larger gap; high-frequency textures like gravel or fine fabric show a smaller gap. The direction is consistent — AVIF tends to be smaller — but the degree varies, so always test both on your own content before committing to one.

This is the most significant technical difference between the two formats. WebP is limited to 8 bits per channel in both its lossy and lossless modes. Eight bits gives 256 steps per channel, which is sufficient for standard dynamic range sRGB content but inadequate for HDR displays or wide-gamut color spaces like Display P3 or Rec. 2020. WebP has no mechanism for HDR transfer functions such as PQ (Perceptual Quantizer) or HLG (Hybrid Log-Gamma).

AVIF natively supports 8-bit, 10-bit, and 12-bit color depth. Ten bits provides 1,024 steps per channel, which is enough to encode HDR content without visible banding and to represent the full Display P3 gamut cleanly. AVIF also carries standard color metadata for PQ and HLG transfer functions and can tag images with ICC profiles or CICP color primaries for accurate reproduction on wide-gamut displays. For a photographer delivering files to an HDR-capable device or a streaming platform needing HDR thumbnails, AVIF is the only option of the two.

For typical web photography in sRGB at 8 bits, both formats are functionally equivalent at the color depth layer. The HDR and wide-gamut advantage only matters when the content itself was captured or graded in a wider space and the delivery target can consume it. If your workflow is standard web photography for a general audience, this distinction is unlikely to affect your choice in practice.

Both WebP and AVIF support alpha transparency, and both do so better than JPEG, which has no alpha channel at all. WebP supports an 8-bit alpha channel that can be encoded as either lossy or lossless independently of the color data. This makes WebP a viable PNG replacement for product cutouts, logos with soft edges, and UI elements that sit over variable backgrounds.

AVIF also supports 8-bit alpha, and because AVIF can encode at 10 or 12 bits, its alpha channel can carry more precision when needed. Both formats allow storing the alpha plane losslessly even when the color data is compressed, which preserves hard edges on transparency masks while still shrinking the color payload. For most web use cases involving logos, icons, or product photos with transparent backgrounds, either format works well. AVIF's alpha tends to be slightly more compact at matched precision, consistent with its general compression advantage.

One notable difference: if you need to replace PNG for transparent images, both WebP and AVIF are good candidates. AVIF with a lossless or near-lossless color pass and a lossless alpha channel can replace many PNGs at a fraction of the file size. WebP lossless mode with alpha also compresses well for flat-color or limited-palette graphics like logos and icons. Photographic transparencies (product photos with soft shadows) compress better in AVIF lossy with lossless alpha.

WebP supports animation directly in its container, storing multiple frames with per-frame timing in a way that is broadly supported in browsers and many image-rendering libraries. Animated WebP is substantially more efficient than animated GIF and handles a full 24-bit color palette rather than GIF's 256-color limit. For simple UI animations, sticker packs, and short looping clips on the web, animated WebP is a mature and well-supported choice.

AVIF defines an animation profile called AVIF Sequence (AVIS), which stores frames as individual AV1 intra-frames in the ISOBMFF container. The per-frame compression is excellent — each frame benefits from AV1's full toolkit — but AVIF Sequence is not yet as broadly supported in image-rendering contexts as animated WebP. Some browsers that support static AVIF do not yet handle AVIF sequences, and most image editing tools with animated format support cover animated WebP before animated AVIF.

For animated content at the moment, animated WebP is the safer choice if compatibility matters. For very short animations in controlled environments where you can verify AVIF Sequence support, the compression benefit can be significant. For longer animations and video-like loops, consider using an actual video format (MP4 with AV1 or H.264) inside a <video> element rather than any image format, since video containers handle temporal compression across frames rather than compressing each frame independently.

WebP has broader browser support than AVIF, full stop. Safari added WebP support in version 14 (released with iOS 14 and macOS Big Sur in 2020), which means iPhones running iOS 14 or later can display WebP. Chrome, Firefox, and Edge have supported WebP for years. The practical effect is that WebP reaches a slightly older installed base than AVIF, particularly on iOS and on older Android devices with system browsers.

AVIF support arrived later: Chrome 85, Firefox 93, and Safari 16.1 (released with iOS 16 and macOS Ventura). iPhones on iOS 15 or earlier cannot display AVIF. Internet Explorer does not support either format. Older Samsung Internet versions, smart TV browsers, and some embedded WebView environments may support WebP but not AVIF.

The practical fallback order for a web page targeting the widest audience is JPEG at the base, WebP as the first upgrade tier, and AVIF at the top. In HTML this looks like:

<picture>
  <source srcset="image.avif" type="image/avif" />
  <source srcset="image.webp" type="image/webp" />
  <img src="image.jpg" alt="Description" />
</picture>

The browser reads the <source> elements in order and picks the first format it supports. Modern browsers get AVIF; slightly older ones get WebP; very old ones fall back to JPEG. Serving all three means no user pays a penalty and modern users get maximum compression. This is the recommended approach for any image-heavy site where performance matters.

WebP encodes relatively quickly. Its VP8-based lossy encoder is fast enough for real-time or near-real-time use, and the lossless encoder is also reasonably quick. This makes WebP practical for server-side on-the-fly conversion pipelines where images are transformed at request time.

AVIF encoding is notably slower at the same compression quality settings. The AV1 codec was designed to prioritize compression efficiency over encoding speed, and the trade-off is visible in practice. High-quality AVIF encoding with a slow speed preset can take many times longer than the equivalent WebP encoding. For batch offline conversion this is manageable, but for real-time server-side encoding it adds infrastructure cost. Most AVIF encoders expose a speed parameter that trades compression efficiency for faster encoding; production pipelines typically use a middle setting.

Decoding cost matters on low-powered devices. AVIF decoding is more computationally intensive than WebP decoding, which can affect battery life and frame rate on older mobile hardware. Modern smartphones handle AVIF decoding smoothly, but older mid-range Android devices and iPhones on iOS 16 (just barely at the AVIF support threshold) may experience slower decode than WebP. For a page with many images visible simultaneously, this is worth testing on representative devices. For most standard web pages with a few images, decoding cost is not a bottleneck in practice.

The most robust production approach is to generate all three formats — AVIF, WebP, and JPEG — at build time and let the browser choose via the <picture> element. Modern static site generators and CDN image pipelines (Cloudflare Images, imgix, Netlify Image CDN, and others) automate this. You upload a single source image; the pipeline outputs AVIF, WebP, and JPEG variants and serves the appropriate one via content negotiation.

If your infrastructure only allows one modern format, WebP is the safer default for broad compatibility, especially if your audience includes iOS 14 – 15 users or older Android devices. If you can verify your audience is on newer browsers (check your analytics for Safari and iOS versions), AVIF delivers better compression for the same visual quality, which directly improves page load speed and Core Web Vitals scores — particularly Largest Contentful Paint when the hero image is the LCP element.

For converting existing AVIF files to other formats for compatibility, the AVIF to JPG converter on this site processes files entirely in your browser using WebAssembly, with no file uploads needed. You can also convert AVIF to PNG for lossless output or use the online AVIF converter for quick one-off conversions. For understanding the AVIF format in more depth before deciding, the AVIF vs JPG comparison covers how AVIF stacks up against the format it is most often replacing.

Here is a practical checklist for common scenarios:

• Photographs and hero images on a modern website serving Chrome, Firefox, and Safari 16+ audiences → AVIF, with WebP fallback via <picture>.
• Images that must display on iOS 14 – 15 or other pre-AVIF browsers without a fallback mechanism → WebP.
• Short looping animations, sticker packs, or UI motion where video is overkill → animated WebP.
• HDR photography, 10-bit color for wide-gamut displays, or professional image delivery → AVIF (WebP cannot do this).
• Transparent product cutouts and logos on a modern site → either format works; AVIF is slightly more compact.
• Maximum compatibility for email attachments, document embedding, or unknown destinations → JPEG or PNG, not WebP or AVIF.
• Server-side real-time encoding on constrained hardware → WebP (faster encoder).
• Offline batch conversion where encoding time is not a constraint → AVIF for best file-size outcome.

Neither format is universally superior. AVIF wins on compression efficiency, color depth, and HDR support. WebP wins on encoding speed, animation maturity, and compatibility with a slightly older installed base. For most web publishing use cases in 2024 and beyond, serving AVIF to browsers that support it — with WebP and JPEG as automatic fallbacks — is the right default.

Benchmark studies give concrete numbers to the abstract claim that AVIF is smaller. In the Cloudinary Image Analysis Tool's 2023 corpus of 1,000 real-world photographs, AVIF at quality 60 produced files averaging 38 % smaller than WebP at quality 80 — both rated visually equivalent by SSIM. Netflix's internal testing of still frames from their catalog showed AVIF outperforming WebP by 20–30 % at matched VMAF scores. The web.dev team found that switching hero images from WebP to AVIF on a news site reduced Largest Contentful Paint by roughly 180 ms on a 4G mobile simulation.

The numbers are less dramatic for flat-color graphics and illustrations. WebP lossless mode frequently beats AVIF lossless on icons and diagrams with fewer than 64 distinct colors, because WebP's LZ77-based predictor is highly tuned for exactly that content type. In a test of 200 open-source icon sets, WebP lossless was smaller than AVIF lossless in 61 % of cases, with an average 12 % size advantage on that content. The lesson is that photographic content strongly favors AVIF, while synthetic imagery is a coin flip.

One common mistake is comparing formats at mismatched quality settings — for example, AVIF quality 80 versus WebP quality 80. Quality scales between encoders are not equivalent; a WebP at q80 and an AVIF at q60 may produce perceptually identical results at very different file sizes. Always compare at matched visual quality (use SSIM or DSSIM to verify), not matched quality numbers. Another mistake is testing on already-compressed JPEG inputs: re-encoding a JPEG introduces JPEG artifacts into the reference, which can inflate the apparent quality of either modern format. Always encode from a lossless source like a TIFF or uncompressed PNG.

The most common production mistake teams make is converting images manually one by one. A repeatable pipeline is far more maintainable. Here is a concrete setup using Sharp (the Node.js image library) to generate all three variants from a source JPEG or PNG at build time:

// generate-images.mjs — run once at build time
import sharp from 'sharp'
import { readdir } from 'fs/promises'
import { join, extname, basename } from 'path'

const SRC = 'public/images/src'
const OUT = 'public/images/out'

for (const file of await readdir(SRC)) {
  if (!/\.(jpg|jpeg|png|tiff)$/i.test(file)) continue
  const name = basename(file, extname(file))
  const src  = join(SRC, file)
  // AVIF: quality 55 maps to roughly WebP quality 80 perceptually
  await sharp(src).avif({ quality: 55, effort: 4 }).toFile(`${OUT}/${name}.avif`)
  // WebP: quality 80, method 6 for best size/speed balance
  await sharp(src).webp({ quality: 80, effort: 5 }).toFile(`${OUT}/${name}.webp`)
  // JPEG fallback: quality 85
  await sharp(src).jpeg({ quality: 85, mozjpeg: true }).toFile(`${OUT}/${name}.jpg`)
}

Key settings to note: Sharp's effort parameter for AVIF maps to libaom's speed preset on a 0–9 scale where lower effort means faster but larger. Effort 4 is a reasonable middle ground for batch offline encoding; effort 6–9 produces the smallest files but can take 10× longer per image. For WebP, Sharp's effort maps to method 0–6 internally; effort 5 corresponds to method 5, which gives noticeably smaller files than the default effort 4 at roughly 2× the encoding time — still fast enough for most batch pipelines.

Three frequent errors in pipeline setup:

• Forgetting to strip metadata. Sharp strips Exif by default, but some pipelines pass { keepMetadata: true } for copyright preservation. An unstripped AVIF can carry a multi-kilobyte Exif block that negates part of the compression advantage over WebP. Strip metadata unless there is a specific legal reason to keep it.
• Using the wrong AVIF chroma subsampling. The default chroma subsampling for AVIF in many tools is 4:2:0, which is correct for photographs but wrong for text-heavy images or UI screenshots. For those, pass chromaSubsampling: '4:4:4' to avoid color fringing around high-contrast edges.
• Serving AVIF without the correct MIME type. Cloudflare, NGINX, and Apache need an explicit MIME type entry for image/avif. Without it some CDN configurations serve AVIF files with application/octet-stream, causing browsers to download rather than display them. Add AddType image/avif .avif to your Apache config or the equivalent in NGINX's mime.types file.

Browser support is often described in broad strokes; the details matter more than the headlines. The table below reflects the state as of late 2025:

The practical takeaway from this table: any browser that supports AVIF also supports WebP, so the only group for whom you need a JPEG fallback (not just a WebP fallback) is IE 11 and very old Safari before version 14. Global IE 11 usage fell below 0.5 % in 2023; most consumer-facing sites can safely drop the IE fallback from their <picture> element. The remaining edge case is pre-iOS-16 devices still in active use — typically iPhones from 2017–2019 that have not been updated. Analytics data from mid-2025 suggests iOS 15 and earlier represent roughly 3–5 % of Safari traffic depending on the site's audience geography. If that audience matters to your site, keep the WebP fallback; it adds minimal overhead and ensures those users receive a modern-format file rather than a JPEG.