The complaint sounds blunt, but the diagnosis is close enough to be useful: if your og:image points to an AVIF file, Facebook link previews can fail even while the image loads perfectly on the page itself. 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 Open Graph preview tooling still follows a narrower compatibility path.
Table of Contents
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, better 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 universal image-decoder support inside every crawler and preview system.
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 misbehaving in isolation. It is exposing what the preview pipeline can and cannot reliably consume.
The practical verdict is harsher than the theory
Here is the piece of guidance that matters most in the real world. Webflow’s current Open Graph documentation says AVIF and WebP images aren’t supported for Open Graph images and recommends uploading a new version in JPG or PNG instead. The same documentation says that when Facebook previews are missing an image, one of the first fixes is to make sure Open Graph images are in JPG or PNG format, then re-scrape the URL with Meta’s debugger.
That does not prove some sweeping, eternal ban on AVIF across every Meta surface. It does establish something more useful for publishers, developers, and SEO teams: AVIF is not a dependable format for Facebook link previews. If your workflow needs stable, predictable URL cards, treating AVIF as unsupported for og:image is the sensible operational rule.
The split that avoids broken previews
| Surface | Safer image choice | Why |
|---|---|---|
| Browser-rendered page images | AVIF with fallback | Modern browsers can benefit from better compression and negotiate supported formats |
og:image for Meta link previews | JPG or PNG | Current Open Graph tooling and Facebook preview workflows are more reliable with conservative formats |
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 AVIF into og:image. 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 a design problem. It is an architecture problem.
There is another technical wrinkle here. Cloudflare notes that 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 JPG or PNG URL and leave no room for negotiation. That last step is an engineering inference, but it follows directly from how AVIF delivery and crawler-based previews work.
This is why the phrase “Facebook Debugger doesn’t know AVIF” lands, even if it is not perfectly technical wording. What people really mean is simpler: Meta’s link preview stack is not a place where AVIF can be trusted. For publishing systems, that distinction matters less than the outcome. The link card either renders 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 <picture>, responsive image markup, 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, which is exactly what you want here: explicit metadata, explicit format, explicit dimensions.
A minimal version looks like this:
<meta property="og:image" content="https://example.com/social/article-card.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="Social preview image for the article" />The Open Graph protocol documents those structured properties, and Webflow’s guidance notes that explicitly setting width and height helps the crawler render the image immediately instead of waiting to download and inspect it first. The same help article also advises using JPG or PNG for Facebook-facing Open Graph images.
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 AVIF-based image with a JPG and the old preview still appears, that does not automatically mean the fix failed. It often means the preview needs to be scraped again. Meta’s Sharing Debugger and Webflow’s documentation both point users toward that re-scrape step.
Small details still decide whether the card appears
Format is the headline problem here, 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. Webflow’s Facebook troubleshooting guidance says Open Graph images should be JPG or PNG, recommends at least 1080 pixels wide based on Facebook guidance, and advises adding og:image:width and og:image:height. That is a better recipe than hoping the crawler will infer everything correctly from a transformed asset.
The same logic applies to image URLs that sit behind redirects, signed URLs, cookies, bot filtering, or anti-hotlink rules. Even a perfectly valid JPG can fail if the crawler cannot fetch it cleanly. AVIF simply makes the compatibility margin thinner because you are already asking the preview stack to decode a modern format that current Open Graph tooling still handles inconsistently.
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, but never rely on AVIF for og:image on pages that need Facebook previews to work every time. That one decision removes a surprising amount of ambiguity from CMS behavior, SEO plugins, CDNs, and social testing workflows.
So yes, the original complaint points at something real. 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 an older, stricter preview ecosystem. Once you see that split clearly, the remedy stops being mysterious. Keep AVIF where it shines. Keep Open Graph conservative. 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.
