ogmake
Sign up
Menu

og:image not showing

A shared link with no preview image, or a stale one, is almost always one of four things: a relative image URL, an oversized or unsupported file, a platform's own cache of an older version of the page, or the tag missing from the page's <head> in the first place. This page covers all four, then goes platform by platform.

Check your URL now Free, no account: shows the tags, the image and the card on each platform.

Fix it per platform

For each platform: what you see, what to check, what to do. Run your URL through the OG image checker first; it covers the tag and image checks below in one pass.

X (Twitter)

LinkedIn

Facebook

Slack

Discord

1. Use an absolute URL

og:image's content must be a full, absolute URL, including scheme and host — https://yoursite.com/path/to/image.png, never /path/to/image.png or a relative path. The Open Graph protocol spec defines og:image as an image URL, and its URL type is an http:// or https:// address. A crawler fetching your page has no reliable base to resolve a relative path against, so use the full URL. If your page currently emits a root-relative path, that is usually the entire fix.

2. Match the size and format platforms expect

1200×630 px (roughly a 1.91:1 ratio) is a safe default. Facebook recommends at least 1200×630 and says to keep images close to 1.91:1 to show the full image in Feed without cropping, with a minimum of 200×200 and a maximum file size of 8 MB. LinkedIn lists a 5 MB maximum, a 1200×627 minimum and a 1.91:1 ratio. X's card documentation describes a 2:1 ratio for large-image cards, so other platforms may crop slightly differently; keep important content away from the edges. PNG and JPEG are the safe formats; X's card docs list JPG, PNG, WEBP and GIF (first frame only for animated GIFs) and state SVG is not supported.

WhatsApp is the tightest on file size in practice. Meta does not publish an exact number in its official docs, but it is widely reported by developers troubleshooting dropped previews that WhatsApp silently declines to show an oversized image — no error, the link just falls back to text-only — somewhere in the 300 KB–600 KB range depending on report. Since there is no official figure to target exactly, the safe move is to keep the file comfortably under 300 KB (a 1200×630 JPEG at quality 75–80 is normally well inside that). Sources reporting this behavior: opengraph.to and getlinkpeek.com.

3. Platforms cache what they unfurl

Facebook's sharing documentation says it caches images by URL: "We cache all images referenced based on each image's URL", so a replaced image needs a new URL, and updating the image does not automatically update the preview of old shares. Other platforms behave similarly in practice: they store what their crawler first saw and may keep showing it — editing the image file in place, with the same URL, may not change what people see until the platform re-fetches.

Two official tools force that refresh and show you exactly what a crawler saw:

Where a platform has no re-scrape tool of its own (for example Slack and Discord), the cache-busting param below is the practical fix.

4. Force a fresh fetch with a cache-busting param

Because Facebook documents that it caches images by URL, and other platforms are widely reported to do the same, the practical way to get a fresh image — including on platforms with no debugger tool — is to change the image URL. Add (or bump) a query parameter that doesn't affect rendering, e.g. ?v=2, and point og:image at that new URL: 

<meta property="og:image" content="https://yoursite.com/card.png?v=2">

Every ogmake URL already includes its own parameters in the signed query string, so changing any rendered field (title, template, etc.) naturally produces a new URL and a fresh, uncached render — see the quickstart. If you're serving a static image file yourself and need to force a re-check without changing its content, appending an incrementing ?v= value is the same trick applied to a file you don't control the caching headers of.

Still not showing?

Confirm the tag is actually present in the page's server-rendered HTML (not injected later by client-side JavaScript — link-preview crawlers generally read the HTML they receive), confirm the page returns a 200 status to the crawler's user agent, and re-run the Facebook Sharing Debugger above — its error list names the exact tag or fetch problem if one exists.

Building the image itself: the free generator makes a one-off PNG with no account, and the quickstart covers a signed API URL you can drop straight into og:image.