Facebook debugger drops AVIF images from URL previews

UPDATE: This article has been updated after additional testing and technical feedback.

The original version stated the issue too broadly. A direct AVIF image can be fetched and displayed by Meta’s Sharing Debugger, and an explicitly declared AVIF og:image may work in some implementations.

The specific issue observed in the original test was more precise: the article URL did not provide an explicit og:image, and Meta’s debugger warned that the image should be explicitly provided even if a value could be inferred from other tags.

The corrected conclusion is therefore narrower: AVIF remains a modern and efficient browser image format, and the original test did not prove that AVIF fails when used as an explicitly declared og:image. The practical issue was not AVIF itself, but missing or incomplete Open Graph metadata, reliance on inferred preview images, CMS guessing, CDN rewriting, or untested preview workflows. For predictable social previews, the image should be explicitly declared through og:image, served from an absolute and publicly accessible URL, correctly typed, dimensioned, and tested on the target platforms. The format decision should come from the actual requirements and behavior of the publishing system and sharing platforms, not from browser rendering alone.

The complaint sounds blunt, but the technical issue is more specific than the original wording of this article suggested. A direct AVIF file can be fetched and displayed by Meta’s Sharing Debugger, and an explicitly declared AVIF `og:image` may work in some implementations. The problem appears when a page relies on inferred images, automated CMS image selection, rewritten image URLs, dynamic format negotiation, or AVIF based image workflows instead of a clearly declared and crawler safe Open Graph image.

That mismatch confuses a lot of publishers because they assume one image pipeline governs everything. It does not. A page view is handled by a browser. A social preview is built by a crawler that fetches metadata, caches it, and turns it into a card. AVIF is a strong modern delivery format for browsers, with documented compression advantages and broad support across major browsers, but reliable Open Graph previews still depend on explicit metadata, predictable URLs, accessible files, correct image properties, and platform specific testing.

A modern format runs into an older sharing pipeline

AVIF has earned its place on the modern web. MDN describes it as a high performance format with much better compression than PNG or JPEG, and recommends fallbacks because support, while broad, is still not identical across every environment. Cloudflare makes the same case from an infrastructure angle, noting that AVIF compresses images significantly better than older generation formats such as WebP and JPEG. For page rendering, that is a real win: fewer bytes, faster delivery, and good visual quality at smaller file sizes.

The trouble begins the moment a URL is shared. Open Graph is the layer that tells platforms which title, description, canonical URL, and image to use. The protocol explicitly defines og:image and structured properties such as og:image:type, og:image:width, og:image:height, and og:image:alt. That sounds flexible, and it is, but flexible metadata is not the same thing as a guarantee that every crawler, CMS, CDN, plugin, cache, and preview system will behave like a modern browser.

Meta’s own documentation describes FacebookExternalHit as the crawler that fetches shared content across Meta’s apps, while the Sharing Debugger is the tool meant to preview and troubleshoot how that content will appear when shared. In other words, the Facebook Debugger is not only a browser image test. It is showing what the preview pipeline can read, fetch, cache, and turn into a social card.

That distinction matters. A browser can load AVIF through responsive markup, fallback rules, CDN negotiation, or performance plugins. A social crawler needs clear metadata and a stable image URL. When the preview depends on inference, automatic image selection, or format rewriting, the result can become fragile even if the page itself looks perfectly healthy.

The practical verdict is more specific than it first looked

The most important correction is this: a direct AVIF image can work in Meta’s debugger. An explicitly declared AVIF og:image may also work in some implementations. The original test did not prove a universal AVIF failure. It showed a more specific issue with a page where the preview image was not explicitly declared through og:image.

That warning is not a small detail. Meta’s debugger said that og:image should be explicitly provided, even if a value could be inferred from other tags. In practical terms, that means the crawler did not receive the preview image in the clean, explicit way it expected.

Here is the clearer distinction:

• A direct AVIF media URL can be fetched and displayed.
• An article URL without an explicit og:image can fail to produce an image preview.
• An explicitly declared AVIF og:image may work in some cases, but it should be tested on the actual platforms that matter.
• A production Open Graph image should not depend on inference, CMS guessing, CDN rewriting, or browser specific image negotiation.

This is where Webflow’s guidance remains relevant. Webflow’s documentation says AVIF and WebP images are not supported for Open Graph images and recommends JPG or PNG instead. That should not be overstated as proof that Meta can never process AVIF. It is better understood as a practical publishing warning: in real CMS and social preview workflows, conservative image formats are still safer for Open Graph.

So the stronger and more accurate recommendation is not “AVIF never works.” The recommendation is this: use AVIF where it improves browser performance, but keep Open Graph images explicit, deterministic, and conservative when preview reliability matters.

The split that avoids fragile previews

That split looks inelegant only until a broken share card costs you traffic, trust, or campaign performance. The browser and the crawler do not need the same asset, and pretending they do is where many setups start to fail.

The bug often sits inside your own image workflow

A lot of teams do not set out to ship fragile Open Graph metadata. It happens quietly. A CMS converts uploaded assets to AVIF. A performance plugin rewrites image URLs. A CDN negotiates the format dynamically. An SEO plugin then picks the main image and emits whatever file the pipeline now considers canonical. The page looks fast and healthy. The preview card disappears.

That is not simply a design problem. It is an architecture problem.

There is another technical wrinkle here. Browsers supporting AVIF typically advertise that support through the Accept header by including image/avif. That is fine for browser traffic. It becomes risky when your social preview image depends on negotiation rather than on a fixed, explicit file URL. Once a crawler enters the chain, the response path may differ from the one you tested in your own browser.

The safest move is not to make the crawler discover the right format. It is to give it a deterministic Open Graph image URL and leave as little room as possible for inference, rewriting, redirects, format conversion, or cache confusion.

This is why the phrase “Facebook Debugger doesn’t know AVIF” is too broad technically, even though it points toward a real publishing problem. The more accurate point is simpler: Meta’s link preview stack is not a place where publishers should rely on inferred, rewritten, or automatically selected modern image assets. For publishing systems, the distinction matters because the link card either renders cleanly or it does not.

A cleaner implementation costs very little

The fix is not to abandon AVIF across your site. The fix is to separate responsibilities.

Keep AVIF for the page itself where browsers can benefit from it. Use responsive image markup, fallback formats, or your CDN’s browser facing optimization layer. Then give Open Graph its own stable asset, usually a JPG and sometimes a PNG when transparency or exact reproduction matters.

The Open Graph protocol supports a dedicated image URL and structured properties for type, width, height, and alt text. That is exactly what you want here: explicit metadata, explicit format, explicit dimensions.

A conservative production version looks like this:

<meta property="og:image" content="https://example.com/social-preview.jpg">
<meta property="og:image:type" content="image/jpeg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Descriptive text for the social preview image">

A publisher who wants to test AVIF explicitly can test it explicitly:

<meta property="og:image" content="https://example.com/social-preview.avif">
<meta property="og:image:type" content="image/avif">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Descriptive text for the social preview image">

That second version is a valid technical test. But it should be tested in the actual sharing tools used by the publisher, not assumed from browser behavior alone.

That setup also avoids another common editorial headache: cache confusion. Meta’s debugger exists precisely because previews are scraped and cached. If you replace a broken or inferred image with a stable JPG or PNG and the old preview still appears, that does not automatically mean the fix failed. It often means the preview needs to be scraped again.

Small details still decide whether the card appears

Format is one visible part of the problem, but not the only one. A stable preview image should also be publicly accessible, directly fetchable, and large enough for the crawler to use without hesitation. Meta’s documentation recommends specifying og:image:width and og:image:height so the crawler can render the image properly when the page is shared.

The same logic applies to image URLs that sit behind redirects, signed URLs, cookies, bot filtering, anti hotlink rules, CDN transformations, or JavaScript only rendering. Even a perfectly valid JPG can fail if the crawler cannot fetch it cleanly. The risk increases when AVIF appears inside a workflow that also depends on inference, rewriting, negotiation, or incomplete metadata.

There is also a strategic mistake buried in many performance first stacks. Teams optimize for Core Web Vitals, browser byte savings, and responsive delivery, then assume social previews will inherit the gains automatically. They will not. Social cards are part of technical SEO, distribution, and brand presentation, but they obey their own rules.

The job is not finished when the browser is happy. It is finished when the browser, the crawler, the cache, and the share card all agree on the same page identity.

A sharper default for publishers

The safest editorial default is easy to defend and easy to implement: serve AVIF to browsers where it improves performance, but do not rely on inferred AVIF images or workflow generated AVIF assets for Open Graph previews.

That does not mean AVIF is broken. It does not mean Meta can never fetch AVIF. It does not mean every explicit AVIF og:image will fail. The corrected point is narrower and more useful: Open Graph previews need deterministic metadata, stable URLs, declared dimensions, accessible files, and platform testing.

So yes, the original complaint pointed at something real, but the wording needed correction. Facebook’s debugger may not be the villain, and AVIF is certainly not a bad format. The clash sits between a modern web optimization format and a stricter preview ecosystem.

Once you see that split clearly, the remedy stops being mysterious. Keep AVIF where it shines. Keep Open Graph explicit and conservative where reliability matters. That is not glamorous engineering, but it is the version that publishes cleanly, shares cleanly, and keeps your URL previews from turning into empty gray cards.

Author:
Jan Bielik
CEO & Founder of Webiano Digital & Marketing Agency

This article is an original analysis supported by the sources cited below

Sharing Debugger
Meta’s official tool for previewing and debugging how shared URLs appear on Facebook.

Meta Web Crawlers
Meta’s documentation describing FacebookExternalHit and related crawlers used to fetch shared content for previews.

The Open Graph protocol
The original Open Graph specification defining og:image and structured properties such as image type, width, height, and alt text.

Control the look of social shares with Open Graph
Webflow’s help article stating that AVIF and WebP are not supported for Open Graph images and recommending JPG or PNG for reliable social previews.

Image file type and format guide
MDN’s reference explaining AVIF’s compression advantages, browser support, and the need for fallbacks.

Introducing support for the AVIF image format
Cloudflare’s technical overview of AVIF’s compression benefits and browser-side format negotiation.