Decide when AVIF is worth adding to a WebP website image

Add AVIF to an existing WebP/JPEG image stack only after comparing the actual exports for your page. AVIF can compress efficiently, but MDN’s format guide also notes that it does not support progressive rendering. That matters most when a large image takes time to load: the browser cannot show an increasingly complete AVIF as bytes arrive. Keep a fallback whether or not AVIF wins your comparison.

Export the same photograph at the same dimensions and crop in AVIF, WebP, and JPEG. Compare each saved file’s size and inspect the subject at the page’s intended display size. Watch details that matter for that image, such as lettering on a package or soft edges around hair. If AVIF offers no useful reduction or visibly weakens a detail you need, the existing WebP/JPEG pair may be the simpler choice. This is a decision about your exports, not a universal ranking of formats.

When AVIF is worth keeping, offer it first, WebP second, and JPEG as the final image. A <picture> element evaluates its <source> elements in order and retains a required <img> fallback. MDN’s <picture> reference documents selection by type and the fallback behavior.

Use matching crops and proportions across the three exports. In the markup, identify the AVIF and WebP files with their MIME type values and put the JPEG path in the final <img>:

<picture>
  <source srcset="/images/feature.avif" type="image/avif">
  <source srcset="/images/feature.webp" type="image/webp">
  <img src="/images/feature.jpg" alt="Lanterns hanging above a cafe table">
</picture>

Replace all three example paths with real files and write alt text for the image’s role on your page. The WebP middle source is useful when AVIF cannot be selected but WebP can; the JPEG remains available as the last fallback.

This extra source is worth keeping only when you can produce and maintain all three files. If an image editor or build process cannot export an acceptable AVIF version, leave that <source> out and keep the WebP/JPEG pair. The page still has a valid fallback chain. Conversely, if you serve only AVIF and JPEG, there is no need for an empty WebP source. The markup should describe files that actually exist, in the order you intend a browser to consider them.

Self-check: Open all three paths directly. Review the page markup for the exact order and type values. Inspect the displayed image in a browser, then temporarily remove the two <source> elements in a local copy of the page and confirm the JPEG still loads. This confirms the fallback path, although it does not prove how every visitor’s browser will select a format.

If an export is missing or uses the wrong path, the corresponding candidate fails. A missing JPEG leaves browsers without a usable last fallback when they cannot use AVIF or WebP. The format stack also cannot compensate for a poor crop or illegible subject; inspect the displayed image at its intended size.

If the AVIF appears in one browser but not another, check the browser’s format support and inspect which candidate it chose before treating that difference as a broken page. The reader-facing test is simpler: each supported viewing condition should still display the intended subject. Keep the JPEG fallback in place while investigating a newer format’s export or server configuration.