AVIF Output from a WebP CLI: When to Use It

A CLI named around WebP can still be useful for AVIF output if the workflow supports it. GetWebP CLI can produce WebP by default and AVIF when --format avif is selected. That gives teams a single local workflow for testing both modern formats.

The decision is not "AVIF always" or "WebP always." AVIF can be attractive for photographic compression, but WebP may fit existing delivery systems, fallbacks, CMS behavior, and review processes more easily. Use AVIF when it passes both visual and operational review.

"AVIF is smaller" is not a publishing decision by itself. A useful test has to compare the same source files, record the exact command, inspect visual quality, measure encode cost, verify delivery, and keep a fallback plan.

Know the CLI Behavior First#

For batch conversion, the GetWebP CLI commands reference documents two output formats:

# Default WebP output
getwebp ./test-set -o ./out-webp

# AVIF output
getwebp ./test-set -o ./out-avif --format avif

The important difference is quality mode. WebP output uses auto quality by default. AVIF output uses fixed quality, with a documented default of 55 unless you pass another --quality value.

That means this pair is not an apples-to-apples quality comparison:

getwebp ./test-set -o ./out-webp
getwebp ./test-set -o ./out-avif --format avif

It is a workflow comparison between WebP auto quality and AVIF fixed default quality. That may be exactly what you want for a first pass, but the decision note should say so.

If you want explicit test settings, write them down:

getwebp ./test-set -o ./out-webp --quality 82 --no-auto-quality --json > webp.ndjson
getwebp ./test-set -o ./out-avif --format avif --quality 55 --json > avif.ndjson

The JSON report will show quality and qualityMode for each successful output. For AVIF, expect fixed quality. For WebP, check whether the run used auto or fixed settings.

Start With the Asset Type#

AVIF is worth testing for large photographic images where transfer size matters:

• landing page heroes
• editorial photos
• product lifestyle images
• large gallery images
• background images with photographic detail

Be more cautious with screenshots, UI captures, transparent assets, small icons, and images with fine text. Those assets may still work, but they need close review. Sometimes WebP, PNG, or SVG is the better publishing format.

Use a short decision matrix before running the whole library:

Generate AVIF From the Same Source#

Compare AVIF and WebP from the same resized source file. Do not compare an AVIF generated from a fresh source against a WebP generated from an older compressed export.

Example:

getwebp ./test-set -o ./out-webp --quality 82 --no-auto-quality --json > webp.ndjson
getwebp ./test-set -o ./out-avif --format avif --quality 55 --json > avif.ndjson

Quality scales are not identical between formats. Do not assume that quality 82 in WebP and quality 82 in AVIF mean the same visual outcome. Treat the numbers as settings to test, not equivalent measurements.

Supported raster inputs include JPG/JPEG, PNG, BMP, WebP, HEIC/HEIF, and AVIF. If the source set includes SVG icons, design documents, videos, or archive files, keep them out of the conversion folder.

Also separate AVIF experiments from watch-mode automation. The batch getwebp <path> command supports --format avif; watch mode is a long-running WebP automation workflow. For AVIF rollout decisions, a bounded batch run is easier to audit.

Review Encoding Time#

AVIF may reduce file size for some images, but encoding can take longer depending on settings, hardware, and toolchain. That matters when the workflow runs in CI, processes large catalogs, or supports frequent content updates.

Track:

• output size
• visual approval
• encode time
• failed files
• delivery behavior

If AVIF saves bytes but makes routine publishing too slow, use it selectively. A format choice should fit the team’s workflow, not only a benchmark.

Record the result in a table:

Replace the zeroes with actual values from newSize in the JSON reports. Do not rely only on a single "average saved" number. The biggest page images deserve individual review.

You can extract a compact report with jq:

jq -r '
  select(.type == "convert.completed")
  | .data.results[]
  | select(.status == "success")
  | [.file, .outputPath, .originalSize, .newSize, .savedRatio, .quality, .qualityMode]
  | @tsv
' avif.ndjson

The JSON output reference explains these fields. Keep the report with the visual decision so a future teammate can see whether AVIF was approved because it looked better, saved enough bytes, or simply happened to be smaller.

Use Picture for Conservative Delivery#

When serving AVIF on the web, a conservative pattern is AVIF first, WebP second, and an older fallback last:

<picture>
  <source srcset="/images/hero.avif" type="image/avif" />
  <source srcset="/images/hero.webp" type="image/webp" />
  <img src="/images/hero.jpg" alt="Designer reviewing product packaging samples" />
</picture>

This pattern should be tested in your real templates, CDN, cache layer, and CMS. The markup is only one part of delivery.

MDN's picture element documentation explains how browsers choose sources. MDN's image file type guide gives broader context for AVIF, WebP, JPEG, PNG, and SVG.

After adding the markup, test delivery with real pages:

Do Not Remove WebP Too Early#

Even if AVIF performs well in a test, keep WebP outputs until the site’s delivery path is proven. Some CMS previews, integrations, or downstream platforms may behave differently from the main browser path.

For a rollout, start with a limited set:

• one hero image
• one article featured image
• one product or gallery image
• one image inside a CMS-managed page

Verify that analytics, caches, open graph previews, and templates continue to work as expected.

Do not delete original JPEG or PNG files during the first rollout. Originals are still needed for future formats, re-encoding, social previews, and rollback. The CLI reference notes that original files are not modified or deleted by conversion; keep that property in your workflow instead of turning the rollout into a one-way migration.

Check File Headers and Caching#

After deployment, use the browser network panel to confirm that AVIF files are served with the expected content type and that fallback sources are still reachable. Also check cache invalidation. If the HTML points to a new AVIF file but the CDN serves old markup, users may not receive the format path you tested.

This delivery check is separate from visual quality. Both have to pass before expanding AVIF across a site.

For direct URL checks, request headers and status are often enough:

curl -I https://example.com/images/hero.avif
curl -I https://example.com/images/hero.webp
curl -I https://example.com/images/hero.jpg

If your CDN varies delivery based on Accept, also test with representative Accept headers. The point is not to prove that AVIF exists on disk; it is to prove that the public delivery path serves the intended file and preserves fallbacks.

Keep Source Files and Decision Notes#

Store the original source, WebP output, AVIF output, and review notes together during testing:

hero-source.jpg
hero-q82.webp
hero-q50.avif
decision.txt

The decision note should say why AVIF was approved or rejected. This prevents future teammates from repeating the same test without context.

Example note:

Source: hero-source.jpg
Commands:
  getwebp ./hero-test -o ./out-webp --quality 82 --no-auto-quality --json > webp.ndjson
  getwebp ./hero-test -o ./out-avif --format avif --quality 55 --json > avif.ndjson
Decision: ship AVIF for hero with WebP and JPEG fallback
Reason: AVIF passed desktop/mobile visual review and reduced hero bytes enough to justify slower encode
Holdback: keep WebP default for screenshots and CMS thumbnails
Reviewer: design and frontend

Use AVIF Selectively#

AVIF output is most useful when it improves a real page and the delivery path is ready. It is less useful when it complicates CMS workflows, increases build time too much, or harms screenshots and fine details.

A local CLI makes testing easier because you can compare formats without uploading assets. The publishing decision still depends on quality review, browser delivery, cache behavior, and the operational cost of maintaining another output format.