Tools Nimbus

Why is my link preview not showing

Tools Nimbus is a free, no-signup developer toolkit that runs entirely in your browser, so your data is never uploaded to a server. A missing link preview is usually one of four faults: tags injected by JavaScript that the crawler never runs, a relative og:image path, an image too heavy for the platform, or a cached older copy of the URL. Fix them with the Tools Nimbus Open Graph and Meta Tag Generator.

Last updated August 2026

Check what the crawler actually receives

Before changing any markup, find out what the other side is reading. A link preview is built from the raw HTML of one HTTP response, fetched once by a bot that is not a browser and does not behave like one. What you see in DevTools is the page after JavaScript has run, which is a different document.

curl -sL -A "facebookexternalhit/1.1" https://example.com/page | grep -i 'og:'

If that prints nothing, or prints placeholder values, you have your answer and none of the platform-specific advice below applies yet. The tags are not in the response. If it prints exactly what you expect, the problem is downstream: the image, the cache, or a platform rule.

Symptoms, causes and fixes

SymptomMost likely causeFix
No card at all, just a bare URLNo Open Graph tags in the server response, or the page is not publicly reachableRender the tags server side and confirm with curl from outside your network
Card appears but the image is missingRelative og:image path, or an image behind authUse a full absolute https URL on a public host
Image shows everywhere except WhatsAppFile heavier than the roughly 300 KB budget, or slow to returnCompress below the budget and keep the response fast
Old image or title keeps appearingThe platform cached the preview for that URLRe-scrape in the platform debugger, or version the image filename
Correct in Slack, wrong on FacebookSeparate caches and separate crawlers, filled at different timesRefresh each platform separately; they never share state
Title and description ignoredDuplicate tags, or tags outside the headKeep exactly one of each tag, inside the head
Works on staging, not in productionCrawler blocked in robots.txt, or a redirect chain to a different URLAllow the social bots and make og:url the final canonical URL
Image is cropped or letterboxedAspect ratio far from 1.91:1Export at 1200x630

Cause 1: the tags are not in the HTML

This is the single most common cause on modern stacks, and it is invisible from the browser. Facebook's crawler reads the raw HTML source and does not execute JavaScript, and the crawlers behind the other major platforms behave the same way. A single-page app that sets its head after mount, or a component that assigns meta tags in an effect, produces a document that is correct in a browser and empty to a bot.

The fix is structural rather than cosmetic: the tags must be in the first response. Server rendering, static generation, or prerendering for bot user agents all work. What does not work is any approach that depends on client JavaScript having run, no matter how early it runs.

A related version of this fault: tags rendered on the server but placed outside <head>. A meta element in the body is not part of the document metadata and is ignored, which is easy to do when the tag is added by a partial or a layout fragment.

Cause 2: the image URL

Assuming the tags are present, the image is where most of the remaining failures live, and the rules are stricter than for images on the page itself.

  • It must be absolute. content="/og.png" is not resolvable by a crawler in any dependable way. Use the full https://example.com/og.png.
  • It must be publicly fetchable. Basic auth on staging, an IP allowlist, a signed URL that has expired, or a hotlink protection rule that rejects unknown referers will all produce a card with no picture and no explanation.
  • It should be 1200x630. That is the 1.91:1 ratio the major platforms crop toward, and it renders cleanly across Facebook, X, LinkedIn, Slack, Discord and iMessage. A square or portrait source gets cropped somewhere unflattering.
  • It should be light. WhatsApp in particular drops thumbnails over roughly 300 KB, silently. Treat that as the ceiling for every platform and you avoid the whole class of problem.

The last two points are a compression job rather than a markup one. The Tools Nimbus Image Compressor will get a 1200x630 export under the budget, and the Image Format Converter will move it to a format the platforms all accept if your source is something exotic. Both run on the Canvas API in your own browser, so the artwork is never uploaded anywhere.

Cause 3: the cache you cannot see

Every platform stores the preview it built the first time a URL was shared, keyed on that exact URL. Nothing you deploy afterwards changes what other people see until that copy is replaced. This is why a page can be provably correct on the server and still preview wrongly, and it is the reason the same link can look different in two different apps.

PlatformHow to force a refresh
FacebookSharing Debugger, then the Scrape Again button
LinkedInPost Inspector re-scrapes the URL on inspection
XNo official tool since the Card Validator was retired in 2022
WhatsAppNo manual refresh; the cached result expires on its own, roughly a week

Because two of those four have no manual override, the reliable move is to change the URL instead of waiting for the cache. Give the image a new filename, or append ?v=2 to it. A different URL has no cache entry anywhere, so every platform refetches at once. Note that this works for the image because og:image is a separate fetch. Versioning the page URL itself is usually not what you want, since that creates a second shareable address for the same content.

Cause 4: the crawler is being turned away

A page that a browser can load is not necessarily a page a bot can load. Worth checking, in rough order of frequency:

  • robots.txt. A broad disallow blocks the social crawlers along with everything else. They identify as user agents including facebookexternalhit, Twitterbot, LinkedInBot and Slackbot-LinkExpanding.
  • Bot protection. A WAF or challenge page that serves an interstitial to unfamiliar user agents returns HTML with none of your tags in it.
  • Redirects. Crawlers follow them, but the preview ends up describing the destination. If og:url disagrees with where the chain lands, some platforms cache under one URL and display for the other.
  • Encoded characters in the URL. A share link whose percent-encoding has been mangled can point somewhere that does not exist. See why does my URL show %2520 for how that happens.

A minimum set of tags that works

Most preview problems are not caused by missing exotic tags. This set, rendered server side inside the head, covers every major platform:

<meta property="og:title" content="Page title">
<meta property="og:description" content="One or two sentences.">
<meta property="og:image" content="https://example.com/og.png">
<meta property="og:url" content="https://example.com/page">
<meta property="og:type" content="website">
<meta name="twitter:card" content="summary_large_image">

X reads the Open Graph tags when the twitter:* equivalents are absent, so the one line that genuinely earns its place is twitter:card, which chooses the large format instead of the small thumbnail. The Open Graph and Meta Tag Generator produces this block from a title, description, URL and image, and shows a live approximation of the card so you can check the wording and the crop before you deploy.

A checklist

  1. Fetch the page with curl and a crawler user agent. Confirm the tags are in the raw HTML.
  2. Confirm they are inside the head and that there are no duplicates.
  3. Open the og:image URL in a private window. It must be absolute, public and an image.
  4. Check the export is 1200x630 and comfortably under 300 KB.
  5. Run the page through the Facebook Sharing Debugger and read what it reports, not what you expect.
  6. Version the image filename when you change it, since two platforms have no manual cache refresh.
  7. Confirm robots.txt and any bot protection are not turning the crawlers away.

For a sibling asset that fails just as silently, see why is my favicon not showing. If you are choosing a format for the preview image, JPG vs PNG covers which one keeps text sharp at card size, or browse all Tools Nimbus guides.

Frequently asked questions

Why is my link preview not showing on WhatsApp but fine on Slack?+

Almost always the image weight. WhatsApp applies a much tighter budget than the other platforms, in practice around 300 KB, and a short fetch timeout. When the og:image is heavier than that or slow to return, WhatsApp gives up and renders the preview with no picture, or with no card at all. There is no error anywhere in your logs because nothing failed on your side. Compress the image below the budget, keep it at 1200x630, and reshare the link.

Why does my link preview show the old image after I changed it?+

Because every platform caches the preview per URL, not per page load. The first time a URL is shared the crawler fetches your tags and stores the result, and later shares are served from that copy. Facebook keeps it until you click Scrape Again in the Sharing Debugger, LinkedIn until you re-run the URL through Post Inspector, and WhatsApp for roughly a week with no way to force a refresh. Pointing og:image at a new filename, or adding ?v=2 to it, sidesteps every cache at once because it is a different URL.

Do link previews work if my meta tags are added by JavaScript?+

No. Facebook's crawler, and the crawlers behind the other major platforms, read the raw HTML response and do not execute JavaScript. Tags injected after mount by a single-page app or a client-side head library exist in the browser and not in the document the crawler receives, so it sees the empty shell or whatever defaults the template shipped with. The tags have to be in the server response, which means server rendering, static generation or prerendering for crawlers.

Is there still an official Twitter or X card validator?+

No. X deprecated the public Card Validator in 2022 and has not replaced it, so there is no first-party way to preview or force a refresh of an X card. Facebook's Sharing Debugger and LinkedIn's Post Inspector are both still live and still the fastest way to see what a crawler actually receives. Since X reads standard Open Graph tags when the twitter:* equivalents are absent, a page that debugs clean in the Facebook tool is usually correct for X too.

Does og:image need an absolute URL?+

Yes. A relative path such as /og.png is resolved against nothing useful by a crawler and is one of the most common reasons an otherwise correct page previews without a picture. Use the full https://example.com/og.png form, on a host that is publicly reachable and not behind a login, redirect chain or IP allowlist. The same applies to og:url, which should be the canonical absolute URL of the page.

Why does my preview show the wrong title and description?+

Either something else on the page outranks your tags or the crawler never saw them. Duplicate og:title tags mean the platform picks one by its own rules, not the one you edited most recently. A tag placed outside the head is ignored. And when no usable Open Graph tags are found at all, most platforms fall back to the HTML title element and the meta description, which is why a preview can look almost right but never respond to your edits.

Try these browser-based tools mentioned in this guide. Everything runs locally, so your data never leaves your device.