AVIF vs WebP: compare your files and keep a working fallback

An AVIF export can be larger than the WebP you already serve. Our 1200 × 900 test image produced a 271,295-byte AVIF and a 196,416-byte WebP. Adding the AVIF would increase this image’s download size by about 38.1%. Those encoder settings also preserved different amounts of image detail, so the smaller file alone cannot settle the choice.

There is a second trap: a supported AVIF URL that returned 404 left our Chrome demo with a broken image, even though valid WebP and JPEG files appeared below it in <picture>. A fallback helps the browser select an appropriate format; it does not guarantee a retry after a selected file fails. Compare your actual exports and test their URLs before adding the new source.

Compare the same image

This original synthetic image is 1200 × 900 pixels. It provides a common source for three exports:

The inline pictures are smaller display previews. The download links provide the full original files used for the measurements.

Export	File size
AVIF	271,295 bytes
WebP	196,416 bytes
JPEG	233,215 bytes

For this image, AVIF is 74,879 bytes larger than WebP, about 38.1% of the WebP file’s size. That is a reason to compare your exports, not a rule that AVIF is always larger. The files were encoded at settings labeled “quality 80,” but that number is specific to each encoder; equal settings do not establish equal visual quality. RGB pixel-difference scores cannot establish which image a reader will prefer.

For a useful pipeline comparison, hold the source, crop, and pixel dimensions steady. If one candidate shows a different crop, you cannot tell whether a size difference comes from the format or the changed image. Then compare the files at the width at which readers will actually see them. Inspect the rendition at its intended display size before deciding that its smaller byte count is acceptable.

The test image is synthetic artwork, not a photograph. Its size results cannot stand in for results from a photo library, screenshots, or every other kind of image on your site.

Add AVIF ahead of WebP

The HTML <picture> element lets a browser evaluate source candidates. Put AVIF first, WebP second, and a broadly usable image in the required final <img>. MDN’s <picture> reference explains that selection and the role of <img>.

<picture>
  <source
    srcset="/practice/remediation-pdf-image-01/formats/scene-q80.avif"
    type="image/avif">
  <source
    srcset="/practice/remediation-pdf-image-01/formats/scene-q80.webp"
    type="image/webp">
  <img
    src="/practice/remediation-pdf-image-01/formats/scene-q80.jpg"
    width="1200"
    height="900"
    alt="Original synthetic artwork used to compare image formats">
</picture>

All three paths above point to the same 1200 × 900 comparison image. The type values identify each newer format, while width and height give the browser the image’s dimensions for layout. Keep the original source image as well: the exported files are delivery versions, not a replacement for the material you would use to make another size or format later.

You can inspect the live picture demo and open the linked files individually. The demo is useful for checking selection; the individual URLs help establish whether each candidate exists and loads.

AVIF and WebP each have capabilities beyond the lossy examples here, including lossless encoding and alpha transparency. Those capabilities do not decide whether AVIF will save bytes for a particular image. MDN’s image-format guide also notes that AVIF has no progressive rendering. That is a format consideration, not a measured loading result for these files.

Check what the browser selected

A visible image alone does not tell you which candidate loaded. In a browser’s developer console, select the <img> inside the picture and inspect its resolved source and dimensions:

const image = document.querySelector("picture img");

console.log({
  currentSrc: image.currentSrc,
  naturalWidth: image.naturalWidth,
  naturalHeight: image.naturalHeight,
  complete: image.complete
});

currentSrc identifies the selected URL. naturalWidth and naturalHeight help confirm that the selected image decoded. For a failed image, do not treat complete: true as proof of success: the recorded broken-image case also reported complete: true, with both natural dimensions at zero. Check the selected request in the browser’s Network panel for its response status, then verify that its path and file are correct.

In the recorded Chrome test, the complete example selected the AVIF and reported natural dimensions of 1200 × 900. Removing the first <source> selected WebP; removing both <source> elements selected JPEG. Each of those three files loaded at 1200 × 900.

Repair a selected URL that fails

The most revealing test changed the first, supported AVIF candidate to /missing.avif. Chrome selected that URL, but the image did not load: currentSrc was /missing.avif, and its natural width and height were zero. The valid WebP and JPEG remained unused.

If an image is broken after you add AVIF, begin with the URL shown by currentSrc. Look for a missing file, an incorrect generated path, or a failed network response. Fix the selected candidate or remove its <source> until a valid file is available.

The WebP and JPEG entries supply other candidates during format selection. A production pipeline therefore needs to publish the file named in every emitted srcset, with the intended crop and dimensions, before it publishes the markup that refers to it.

Test scope: The file sizes and browser behavior above come from one original synthetic image and a recorded test in Chrome 154.0.8037.93 on October 7, 2026. The markup guidance is based on the linked MDN references. No real photograph, visual-quality judgment, loading-speed comparison, or other browser was tested.