AVIF vs WebP for Product Photos: A Practical Test Plan

Product photos are one of the worst places to choose an image format by habit. A format that looks fine for a blog thumbnail can damage fabric texture, jewelry highlights, skin tones, packaging edges, or the sharp line between a white product and a white background. Claims such as "AVIF is smaller" or "WebP is safer" do not answer those merchandising risks.

The better approach is to run a small test that reflects the catalog you actually publish. The goal is not to crown one universal winner. The goal is to decide which format, settings, and fallback strategy protect your product presentation while reducing avoidable file weight.

A product-photo comparison needs more than generic compression claims. A defensible test uses the same resized source set, separate output folders, structured conversion reports, named visual reviewers, and storefront checks for the exact places shoppers inspect the image.

Build a Representative Test Set#

Start with 20 to 40 source images from the real catalog. Do not use only polished hero shots, because those often have the cleanest lighting and the easiest backgrounds. Include images that expose compression problems:

• glossy products with specular highlights
• clothing, leather, wood, or fabric texture
• packaging with small text
• white or transparent-background product shots
• lifestyle photos with faces and shadows
• zoomable detail images
• older images from suppliers or marketplaces

Keep the original files unchanged. Put the test copies in a separate folder so the experiment cannot accidentally overwrite production assets.

Define the Real Use Cases#

Product images rarely have one use. The same source might appear as a category thumbnail, a product detail image, a zoom image, and a social preview. Each use case has a different tolerance for artifacts.

Create at least three output sizes before comparing formats:

• thumbnail: the size used in listing grids
• detail: the primary image shown on a product page
• zoom: the largest image users inspect before purchase

Resizing first keeps the test honest. If one format receives a 2400-pixel input while another receives an 1200-pixel input, the comparison is measuring the pipeline, not the format.

Convert WebP and AVIF Separately#

Run each format through a repeatable command, and record the settings. Avoid testing a random quality number once and treating it as evidence. A reasonable first pass is to compare a small range.

For example, test WebP around the quality range you would actually ship:

mkdir -p ./reports

getwebp ./product-test \
  --recursive \
  --output ./out-webp-q78 \
  --format webp \
  --quality 78 \
  --json > ./reports/webp-q78.ndjson

getwebp ./product-test \
  --recursive \
  --output ./out-webp-q84 \
  --format webp \
  --quality 84 \
  --json > ./reports/webp-q84.ndjson

Then test AVIF outputs with the same resized source set:

getwebp ./product-test \
  --recursive \
  --output ./out-avif-q50 \
  --format avif \
  --quality 50 \
  --json > ./reports/avif-q50.ndjson

The specific numbers are starting points, not rules. AVIF and WebP quality scales are not identical, so quality 80 in one format does not mean the same visual result in the other. For WebP, omitting --quality lets GetWebP use auto-quality mode; for AVIF, --format avif uses fixed quality behavior, with the default quality used when you do not pass a value. Keep those modes separate in the report instead of comparing labels.

Summarize each run before visual review:

for report in ./reports/webp-q78.ndjson ./reports/webp-q84.ndjson ./reports/avif-q50.ndjson; do
  jq -r --arg report "$report" '
    select(.type == "convert.completed")
    | .data.results[]
    | [$report, .status, .file, .outputPath, .originalSize, .newSize, .savedRatio, .quality, .qualityMode, (.error // "")]
    | @tsv
  ' "$report"
done

Also fail the test record if any report contains truncation or a batch failure:

jq -r 'select(.type=="convert.truncated" or .type=="convert.failed") | .data' ./reports/*.ndjson

The GetWebP CLI command reference documents --format, --quality, --recursive, --output, and --json; the JSON output guide explains outputPath, savedRatio, quality, and qualityMode.

Review in the Buying Context#

Open the converted images where customers will see them: category grids, product pages, zoom views, quick-view modals, and mobile layouts. A file can pass a side-by-side viewer but fail in the actual buying context if the product edge looks dirty against the page background or the zoom view loses detail.

Review these areas first:

• small printed text on labels
• texture in fabric, grain, food, or cosmetics
• highlight gradients on glossy surfaces
• sharp edges around white-background products
• shadows under products
• skin tones in lifestyle photography

Reject a setting if the artifact is visible during normal shopping. Do not approve an output only because the byte savings look impressive.

Measure More Than File Size#

File size matters, but product photography also affects trust. Track at least four values for each candidate:

• output file size
• visual approval result
• encode time
• delivery support for your target browsers, CMS, CDN, and marketplace exports

AVIF can often produce very small files, especially for photographic content, but it can also take longer to encode depending on tooling and settings. WebP may be easier to fit into existing CMS and fallback workflows. Those operational costs matter when a team is converting thousands of assets, not just one sample.

Choose a Delivery Strategy#

If AVIF wins visually and operationally, you may still keep WebP as a fallback. A conservative HTML pattern is to serve AVIF first, WebP second, and a legacy source last:

<picture>
  <source srcset="/images/shoe.avif" type="image/avif" />
  <source srcset="/images/shoe.webp" type="image/webp" />
  <img src="/images/shoe.jpg" alt="Black leather running shoe" />
</picture>

That pattern should be tested in your own storefront templates, image CDN, cache layer, and analytics environment. The format decision is only useful if the delivery path is reliable.

Document the Decision#

Write down the approved settings, rejected settings, sample size, source images, and review notes. This prevents the same debate from restarting every time a designer, developer, or merchandising manager touches the catalog.

Useful references for the technical background include Google's WebP documentation, MDN's image file type guide, and MDN's documentation for the picture element.

Make the final decision record concrete:

Sample: 32 product images, resized to thumbnail/detail/zoom variants
Reports: webp-q78.ndjson, webp-q84.ndjson, avif-q50.ndjson
Approved: WebP q84 for zoom, AVIF q50 for category thumbnails after storefront test
Rejected: WebP q78 for white-background cosmetics because edge detail softened
Fallback: JPEG source retained, WebP fallback used when AVIF is delivered first
Reviewer: merchandising lead and frontend owner

For product photos, the best format is the one that survives visual review, fits the production workflow, and can be delivered predictably to the shoppers you actually serve.