ogmake
Sign up

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.

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 states this directly: image properties are URLs, and a URL without a scheme is not one a crawler can resolve reliably. Facebook's crawler documentation makes the same point in its own examples, always showing a full https:// 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 the size every major platform renders full-bleed without cropping or padding; PNG or JPEG are the two formats every platform reliably supports — avoid SVG and animated GIF for og:image, neither renders consistently across unfurlers.

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 own sharing documentation states it plainly: "Images are cached based on the URL and won't be updated unless the URL changes." The first time a platform's crawler fetches a link, it stores the og:image (and the other tags) and serves that cached copy on future shares — editing the image file in place, with the same URL, does not update what people see until the cache expires or is forced to refresh.

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

Slack, Telegram and iMessage don't publish an equivalent public debugger; for those, the cache-busting param below is the practical fix.

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

Because platforms cache by URL, the reliable way to make any of them re-fetch an image — including the ones with no debugger tool — is to change the 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 — most unfurlers don't execute it), 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.