Social Share Preview: How Link Previews Work on Every Platform
A social share preview is the card that appears when someone shares a URL on Facebook, Twitter/X, LinkedIn, WhatsApp, or any messaging app. These previews are generated from meta tags in your HTML — and if those tags are missing or misconfigured, your links look broken. This guide explains how link previews work, how each platform's crawler behaves, and how to use a link preview checker to verify your setup.
What Is a Social Share Preview?
When you paste a URL into a Facebook post, a LinkedIn update, a tweet, a WhatsApp message, or a Slack channel, the platform generates a visual card for that link. This card typically shows:
Title — from og:title or <title>. Description — from og:description or <meta name="description">. Image — from <a href="https://previewog.com/og-image-guide/">og:image</a>. URL/domain — from og:url or the shared URL.
This card is the social share preview. It's assembled automatically by the platform's crawler based on meta tags in your page's HTML. You don't design these cards — you configure the data that platforms use to generate them.
The quality of your social share preview directly affects engagement. A link with a clear title, relevant description, and eye-catching image gets more clicks than a bare URL or a card with a missing image and auto-extracted text.
How Link Previews Work
The process is the same across all platforms:
1. User shares a URL — pastes or types a link into a post, message, or chat.
2. Platform crawler fetches the page — the platform's server-side bot sends an HTTP GET request to your URL.
3. Crawler reads the HTML — it parses the raw HTML response and extracts Open Graph meta tags from the <head>.
4. Platform generates the card — using the extracted title, description, image URL, and other metadata.
5. Platform caches the result — the preview data is stored so future shares of the same URL don't require another fetch.
Here's what the crawler sees:
<head>
<meta property="og:title" content="How to Build a Startup in 2025" />
<meta property="og:description" content="A practical guide to building and launching a startup." />
<meta property="og:image" content="https://example.com/images/startup-guide.jpg" />
<meta property="og:url" content="https://example.com/startup-guide/" />
<meta property="og:type" content="article" />
</head>The crawler makes one request, reads the HTML, and extracts the tags. There's no second pass, no rendering, no waiting for assets to load. It's a fast, single-pass extraction.
Why Crawlers Cannot See JavaScript-Rendered Tags
This is a critical point that trips up many developers: social media crawlers do not execute JavaScript.
If your OG tags are injected into the DOM by React, Vue, Angular, or any other client-side framework, the raw HTML response that the crawler receives will not contain those tags.
Example of what the crawler sees when tags are JS-rendered:
<!-- What your server sends -->
<head>
<script src="/app.js"></script>
</head>
<body>
<div id="root"></div>
</body>
<!-- The crawler stops here. It does not run app.js. -->
<!-- og:title, og:image, og:description — none of these exist in the response. -->The fix: server-side render your meta tags. Common approaches:
Next.js (React): Use the <Head> component or Metadata API — Next.js renders it server-side by default.
Nuxt (Vue): Use useHead() composable — Nuxt handles SSR automatically.
Angular Universal: Configure server-side rendering for meta tag injection.
Static site generators (Hugo, Astro, Eleventy): Meta tags are baked into the HTML at build time — no issue.
WordPress / PHP: Tags are in the HTML response by default.
If you can't implement SSR, consider a pre-rendering service that serves static HTML to crawler user agents.
Platform Crawlers: User Agents, Caching, and Tools
Each platform has its own crawler with specific behavior:
Facebook — User agent: facebookexternalhit/1.1. Cache duration: ~30 days. Use the Facebook Sharing Debugger and click "Scrape Again" to clear cache. Does not execute JavaScript. Follows 301/302 redirects. Timeout: approximately 4-5 seconds.
Twitter/X — User agent: Twitterbot/1.0. Cache duration: ~7 days. The standalone Card Validator is deprecated; composing a tweet with a URL triggers a re-crawl. Does not execute JavaScript. Uses <a href="https://previewog.com/twitter-card-types/">twitter:card</a> meta tag to determine card type, falls back to OG tags for content.
LinkedIn — User agent: LinkedInBot/1.0. Cache duration: ~7 days. Use the LinkedIn Post Inspector — inspecting a URL automatically clears the cache. Does not execute JavaScript.
WhatsApp — User agent: WhatsApp/2.x plus facebookexternalhit/1.1. Cache duration: undocumented and inconsistent. No official preview debugger. Sending a URL with an appended query parameter (e.g., ?v=2) forces a fresh fetch. Does not execute JavaScript. WhatsApp reads the same OG tags as Facebook.
Slack — User agent: Slackbot-LinkExpanding 1.0. Cache duration: varies, typically hours. No official debugger. Slack re-fetches when a link is shared in a new channel. Does not execute JavaScript.
Discord — User agent: Discordbot/2.0. Cache duration: varies. No official debugger. Does not execute JavaScript.
Why Changes Don't Appear Immediately
You've updated your OG tags, redeployed your site, and shared the link again — but the old preview still shows up. This is because of caching.
When a platform crawls your URL, it stores the extracted metadata. Subsequent shares of the same URL use this cached data instead of re-fetching the page. Cache durations vary by platform, but the key principle is the same: platforms don't re-fetch your page every time someone shares the URL.
Other reasons your changes might not appear:
CDN caching: Your CDN might be serving a stale HTML response to the crawler. Purge the CDN cache after deploying.
Server-side caching: Your web server or application might cache the HTML response. Clear server caches after updating meta tags.
DNS propagation: If you recently changed DNS records, the crawler might still be reaching an old server.
Reverse proxy caching: Nginx, Varnish, or Cloudflare might cache the response. Ensure crawler user agents get fresh responses.
How to Force Refresh Per Platform
Facebook: Go to Facebook Sharing Debugger, log in with your Facebook account, enter your URL, and click "Scrape Again" to verify the updated preview.
You can also clear the Facebook cache programmatically:
curl -X POST \
"https://graph.facebook.com/?id=https://example.com/your-page/&scrape=true&access_token=YOUR_TOKEN"LinkedIn: Go to LinkedIn Post Inspector, enter your URL, and click "Inspect" — this automatically clears LinkedIn's cache and fetches the page fresh.
Twitter/X: The standalone Card Validator has been deprecated. Open the tweet composer on twitter.com or the X app, paste your URL — the platform fetches and previews the card. You don't need to post the tweet; composing it triggers the re-crawl.
WhatsApp: WhatsApp has no official cache-clearing tool. Append a query parameter to the URL (e.g., https://example.com/page/?v=2) — WhatsApp treats this as a new URL and fetches fresh. Alternatively, wait for the cache to expire naturally or clear the WhatsApp app cache on your device (only affects your local view).
Slack: Share the URL in a new channel or DM — Slack may re-fetch. Editing a posted message containing the URL sometimes causes Slack to re-fetch the preview.
What Happens When OG Tags Are Missing
Platforms have fallback behavior when specific OG tags are absent, but the results are unpredictable:
og:title missing: Facebook and LinkedIn fall back to the <title> tag. Twitter/X checks twitter:title first, then <title>.
og:description missing: Facebook uses <meta name="description">, then the first text on the page. Twitter/X checks twitter:description, then <meta name="description">. LinkedIn uses <meta name="description">, then page text.
og:image missing: Facebook tries the largest image on the page (unreliable). Twitter/X checks twitter:image, then shows no image. LinkedIn shows no image at all.
og:url missing: All platforms use the shared URL as-is.
og:type missing: Facebook and LinkedIn default to website. Twitter/X uses its own twitter:card system instead.
The takeaway: never rely on fallback behavior. Platforms extract page content differently, and the auto-detected title, description, or image is rarely what you want. Always set explicit OG tags.
Facebook's image fallback is particularly unreliable — it picks the "largest" image on the page, which might be a banner ad, a footer logo, or a decorative element.
Messenger vs Social Network Previews
Link previews behave differently in messaging apps versus social network feeds:
Social Networks (Facebook, Twitter/X, LinkedIn): Previews are generated server-side when the post is created. The preview is permanent — it's stored with the post. Updating your OG tags and clearing the cache only affects future shares, not existing posts. Large image cards are the default for URLs with properly sized og:image.
Messaging Apps (WhatsApp, Telegram, iMessage, Slack, Discord): Previews are generated when the message is sent (or when the recipient views it). Some apps re-fetch previews each time the message is viewed. Image display is more constrained — smaller cards, lower resolution. WhatsApp is particularly sensitive to image file size (keep under 300 KB). iMessage generates its own preview using Apple's crawler and doesn't use OG tags consistently.
Key differences: Social networks generate previews at post creation time and they persist permanently. Messengers generate at send or view time and may regenerate. Social networks show large image cards while messengers show smaller, variable-sized cards. Debugger tools are available for social networks but limited or nonexistent for messengers. Neither social networks nor messengers execute JavaScript.
Quick Reference
Platform Comparison: Facebook uses facebookexternalhit/1.1, caches ~30 days, and has the Sharing Debugger with a "Scrape Again" button. Twitter/X uses Twitterbot/1.0, caches ~7 days, and re-crawls when composing a tweet. LinkedIn uses LinkedInBot/1.0, caches ~7 days, and auto-clears cache on Post Inspector inspect. WhatsApp uses WhatsApp + facebookexternalhit, has unknown cache duration, and no official tool — use the query param trick. Slack uses Slackbot-LinkExpanding, caches for hours, and re-fetches when re-shared. Discord uses Discordbot/2.0, has varying cache, and no official tools.
Link Preview Checklist: Set og:title (under 60 characters). Set og:description (150-200 characters). Set og:image (1200x630, absolute HTTPS URL, under 1 MB). Set og:url to canonical URL. Set twitter:card to summary_large_image. Ensure all OG tags are server-side rendered (not JS-injected). Verify the image URL returns 200 OK and is publicly accessible. Check that robots.txt allows crawler user agents. Test with a link preview checker. Test with Facebook Sharing Debugger. Test with LinkedIn Post Inspector.
FAQ
After you update your OG tags and clear the platform's cache, updates appear immediately on Facebook (after clicking "Scrape Again") and LinkedIn (after inspecting). Twitter/X updates within minutes of triggering a re-crawl. WhatsApp has no reliable cache-clearing method — changes may take hours or days to propagate.
Platforms cache link preview data. Facebook caches for ~30 days, Twitter/X for ~7 days, LinkedIn for ~7 days. Use each platform's debugger to clear the cache. Also check for CDN caching, server-side caching, and reverse proxy caching on your own infrastructure.
Use a social share preview tool like PreviewOG to see exactly how your URL will appear on Facebook, Twitter/X, LinkedIn, and WhatsApp. This lets you catch issues before a link goes live.
Each platform has its own card format, image cropping, and text truncation rules. Facebook shows more description text than Twitter. Twitter crops images to 2:1 for summary_large_image cards while Facebook uses 1.91:1. LinkedIn has its own styling. Use platform-specific debuggers or a link preview checker to see the differences.
No. Platform crawlers must be able to access your page via a standard HTTP request. If your page requires authentication, is behind a VPN, or returns a login redirect, crawlers cannot read your OG tags and no preview will be generated.
Yes. You can use the <meta name="robots" content="noindex"> directive or block crawler user agents in your robots.txt. Some platforms respect <meta property="og:restrictions:content" content="alcohol"> to restrict preview generation. However, behavior varies by platform.
Common causes: image file too large (keep under 300 KB), og:image URL not accessible publicly, SSL certificate issues, or server timeout. WhatsApp is less tolerant of slow servers and large assets than other platforms. Test your image URL directly in a browser and check response times.