← Back to Social Preview Checker
A shared link with no image, the wrong image, or no title almost always comes down to one of five things. Check them in this order -- each one can hide the next.
The Open Graph protocol (ogp.me) requires og:image
to be an absolute URL, not a path relative to the page. A tag like
<meta property="og:image" content="/images/preview.png"> is invalid per spec — some
crawlers resolve it against the page URL anyway, others do not, so a relative URL is the single most
common cause of an image silently failing to appear.
You don't need separate twitter:image, twitter:title, and
twitter:description tags. X/Twitter's card renderer falls back to the matching
og:* tag when its own is absent. What you do need is an explicit
twitter:card value (summary or summary_large_image) —
whether X falls back to plain Open Graph tags with no twitter:card at all is undocumented
and has changed before, so set it explicitly rather than relying on that.
| Platform / card type | Documented minimum | Recommended |
|---|---|---|
| Facebook / LinkedIn (og:image) | 200 x 200 px | 1200 x 630 px (1.91:1) |
| Twitter/X summary_large_image | 300 x 157 px | 1200 x 628 px (~2:1) |
Below the hard minimum, an image is commonly not rendered at all rather than shown smaller. Check your
actual served file's pixel dimensions, not the source image you started from — a build step or
CDN resize can quietly shrink it below the line. This checker fetches the real bytes and reads the
dimensions out of the file header rather than trusting an og:image:width tag, which can go
stale independently of the file it describes.
Many platforms (WordPress SEO plugins especially) inject their own og:title/og:image
tags, which can collide with a hand-written tag already in the template. Most crawlers use the first
matching tag in document order, but which one that is depends on which system rendered its tag first in
the final HTML — view the page's actual source (not the CMS editor) to see which value wins.
Every major platform caches a link's preview aggressively and will keep showing a stale (or blank) result after you fix the tags until it re-crawls the URL. Use that platform's own preview-refresh tool where one exists before concluding your fix did not work — this checker reads the tags and image as they are right now, not what a platform's cache currently shows a visitor.