WebP vs AVIF for AI image citations

AVIF compresses roughly 20-35% smaller than WebP at equivalent quality, but its slower encoding and narrower fallback support make a WebP-with-AVIF picture-element pattern the safest default for ensuring AI crawlers and answer-card renderers can always extract a thumbnail.

TL;DR

AVIF wins on file size (typically 20-50% smaller than WebP) while WebP wins on encoding speed and tooling maturity (Ctrl.blog, 2024).
Both formats are decoded by all major browsers; AVIF reached cross-browser support in January 2024 (RUMvision, 2025).
AI search engines fetch the URLs in your and srcset, then re-encode and resize for answer-card thumbnails — the format you ship still controls what they receive.
Default pattern for AI citation eligibility: AVIF preferred source + WebP fallback + JPEG/PNG ultimate fallback, served through .
Avoid shipping AVIF-only without a fallback; older social-card and AI preview pipelines occasionally bypass and read og:image directly.

What "AI image citation" actually means

AI search engines such as Google AI Overviews, Perplexity, Bing Copilot, and ChatGPT Search render answer cards that include a small thumbnail next to the cited URL. Those engines do not embed your image directly — they fetch the source listed in , srcset, og:image, or twitter:image, then resize and re-encode it for their CDN. For your image to appear, three things must succeed:

The crawler can fetch the image URL without 403/429 throttling.
The pipeline can decode the format you served.
The result fits the dimensions and aspect ratios the answer card expects.

Format choice influences step 2. Even though most modern AI fetchers are based on standard libraries (libavif, libwebp, libjpeg-turbo), real-world failures still happen when assets are AVIF-only, when Accept headers are set narrowly, or when a CDN refuses to serve AVIF to an unrecognized user agent. Treat the format decision as a citation-eligibility gate rather than a performance optimization.

Compression and quality

AVIF is built on the AV1 video codec; WebP is built on VP8 (lossy) and a custom lossless mode. Independent benchmarks consistently show AVIF producing smaller files at equivalent perceptual quality:

Median 50.3% file-size reduction vs JPEG at the same DSSIM, compared to 31.5% for WebP (Ctrl.blog, 2024).
20-35% smaller than WebP at equivalent visual quality for photographic content (practitioner benchmarks aggregated on r/software, 2026).
Both formats support lossless modes; lossless AVIF is competitive with PNG for non-photo content but rarely beats WebP lossless on flat graphics.

For AI thumbnails — typically 600-1200px wide, lossy, photographic — AVIF's compression edge translates to faster transfer to the crawler and lower CDN egress costs. The visual difference at typical web quality settings is imperceptible to human reviewers and to AI image-classification pipelines.

Decode and encode performance

Decode time for both formats is sub-frame on modern hardware and rarely a bottleneck for AI crawlers, which decode asynchronously. Encoding is where the formats diverge sharply:

WebP encodes in roughly 90ms per image at default settings.
AVIF encodes in roughly 4 seconds per image at default settings (around 47x slower than WebP), and can reach 48 seconds per image at maximum quality (practitioner benchmarks aggregated on r/software, 2026).

Implication: for static marketing pages, pre-encode to AVIF as part of the build. For user-generated content, dynamic thumbnails, or on-demand CDN conversion, WebP is the safer default — encoding latency matters because AI crawlers do not retry slow-rendering image endpoints aggressively, and a timeout means no thumbnail at all.

AI engine and crawler support matrix

Crawler / engine	Fetches AVIF	Fetches WebP	Notes
Googlebot-Image	Yes	Yes	Indexes both; downstream display depends on the surface (Search Central docs).
Google AI Overviews	Yes	Yes	Reuses the Google Images pipeline; thumbnails are re-encoded.
Bingbot / BingPreview	Yes	Yes	Bing Webmaster Guidelines do not restrict format; visible content alignment matters more.
PerplexityBot	Yes	Yes	Fetches og:image first; falls back to first content .
ChatGPT-User / OAI-SearchBot	Yes	Yes	Re-encodes for the citation card.
Social card validators (X, LinkedIn)	Partial	Yes	Some validators still misrender AVIF; serve WebP or JPEG for og:image.

The practical risk is not crawler decoding — modern bots all support AVIF — but downstream surfaces such as social cards and email previews that may share infrastructure with AI summary cards. Defaulting og:image to WebP or JPEG protects those surfaces while keeping AVIF on the in-page .

The fallback chain

Use to express priority and let the user agent (or crawler) pick the first format it can decode. The HTML pattern below works for hero images, in-content figures, and structured-data thumbnails alike:

<picture>
  <source type="image/avif" srcset="hero.avif 1x, hero@2x.avif 2x">
  <source type="image/webp" srcset="hero.webp 1x, hero@2x.webp 2x">
  <img src="hero.jpg"
       alt="Descriptive alt text the AI engine can use as caption fallback"
       width="1200" height="630"
       loading="lazy" decoding="async">
</picture>

Rules of thumb:

The inside should always be a JPEG or PNG. This is the format crawlers without picture-element support will fetch, and it is also what most card validators read.
Match width and height exactly. AI thumbnail crops use these for aspect-ratio decisions before fetch.
Set og:image and twitter:image to the WebP or JPEG URL, not the AVIF. Social and AI card pipelines occasionally bypass and read the meta tag directly.
Do not gate AVIF behind a JavaScript loader. AI crawlers that do not execute JS will see no image at all.
Reuse the same canonical URLs for AVIF and WebP variants across pages so CDN caching is effective and the AI re-encode pipeline can deduplicate.

When to choose WebP

The image is generated on demand (user uploads, dynamic charts, signed URLs).
Your CDN charges per-conversion and AVIF encoding cost is material.
The image is a flat graphic, screenshot, or logo where WebP's compression is competitive and lossless mode is preferred.
Your asset pipeline does not yet have a reliable libavif build (legacy CMS, older Node versions).
The audience skews to social-shared content where downstream validators dominate the thumbnail experience.

When to choose AVIF (with fallback)

Static photographic content shipped through a build step.
Pages where image weight is the dominant LCP contributor.
Markets with constrained bandwidth where the 20-50% size reduction is meaningful.
Editorial articles with hero images repeatedly fetched by AI crawlers.
Documentation sites where AI Overviews citations are a primary discovery channel.

Common mistakes

Shipping AVIF-only without a fallback. Card validators on X, LinkedIn, and Slack still misbehave; AI engines may receive a broken thumbnail and drop the visual citation.
Using AVIF for og:image. Open Graph consumers are the most conservative — keep WebP or JPEG here.
Mismatched dimensions in srcset and the width/height attributes, which causes layout shift and aspect-ratio crops in answer cards.
Blocking the image directory in robots.txt. AI thumbnails require crawlable image URLs even if the parent page is allowed.
Lazy-loading above-the-fold hero images. AI crawlers without JS may skip these entirely.
Treating format choice as a ranking signal — it is a citation-eligibility gate, not a relevance lever.

How to validate

Open the URL in PageSpeed Insights and confirm both candidates are listed in the rendered HTML.
Run curl -A "Googlebot-Image" -I https://yourdomain.com/hero.avif to confirm a 200 response and a correct content-type: image/avif.
In Google Search Console, run the URL Inspection tool and confirm the rendered screenshot shows the image. AI Overviews reuses the same fetch pipeline.
For Perplexity, query a phrase your page ranks for and inspect the citation card; if the thumbnail is missing, the og:image URL is the most likely culprit.
Test the social validator chain (Twitter Card validator, LinkedIn Post Inspector, Slack unfurl) before publishing high-traffic pages.

FAQ

Q: Does serving AVIF improve AI search rankings?

No. Format choice does not directly influence ranking signals from Google, Bing, or Perplexity. It influences whether your image actually appears in the answer card by ensuring the crawler can decode and use it. Citation eligibility is a binary gate, not a ranking lever.

Q: Should I drop the element now that AVIF has universal browser support?

Not yet for AI workflows. Even with cross-browser support since January 2024, AI search pipelines and social card validators reuse legacy infrastructure. The fallback is cheap insurance against single-pipeline failure modes and costs nothing in delivered bytes for AVIF-capable clients.

Q: What dimensions should the AVIF source use?

Match the AI thumbnail target — usually 1200x630 (Open Graph) or 1200x1200 (square). Provide 1x and 2x in srcset so high-DPR cards get a sharp thumbnail without an oversized download. Keep the source large enough to crop down without upscaling artifacts.

Q: Will AI crawlers re-encode my AVIF anyway?

Yes. Google, Perplexity, and Bing all re-encode citation thumbnails through their own image CDNs. Your job is to ensure the source decodes successfully and matches the requested aspect ratio. Their re-encode handles delivery format for end users.

Q: Can I use JPEG XL instead?

Not for AI thumbnails today. JPEG XL has not been adopted by Chrome and remains absent from most AI crawler pipelines as of 2026. Stick with the AVIF + WebP + JPEG triplet until cross-pipeline support stabilizes.

Q: Does WebP lossless beat PNG for AI illustrations?

For flat illustrations, charts, and screenshots, WebP lossless typically produces smaller files than PNG at similar fidelity, and all AI crawlers decode it. PNG remains a safe ultimate fallback for accessibility tools and older infrastructure that may still bypass .