What Is a Social Card and How Does It Work?
A social card is the preview a platform builds from your page metadata. Learn how Open Graph and X tags work and how to debug them.
A social card is the preview a social or messaging platform may display when someone shares a webpage URL. Your page supplies metadata in its HTML <head>. A platform crawler fetches the URL, reads fields such as the title, description, image, and canonical URL, then builds its own preview. The platform controls the final appearance, so you must inspect the deployed URL on each service where you plan to share it.
How a social card works
The process has three parts:
- You add page-specific metadata to the HTML head.
- A platform may fetch the URL when it is shared and read the metadata.
- The platform interprets those values and renders a preview according to its own rules.
The Open Graph Protocol defines four basic properties: og:title, og:type, og:image, and og:url. It also describes og:description as an optional but generally recommended field. og:url identifies the canonical URL for the object, while og:image points to its representative image. See the Open Graph Protocol documentation.
X uses related metadata with twitter: names, including twitter:card, twitter:title, twitter:description, and twitter:image. You can publish Open Graph and X metadata together. Do not assume every platform uses the same fallback behavior; verify the destination directly.
Minimal metadata example
Place this in the <head> of the page you want people to share. Replace every example value with data for that page.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>How to Monitor API Latency</title>
<meta name="description" content="A practical guide to measuring and debugging API latency.">
<link rel="canonical" href="https://example.com/guides/api-latency">
<meta property="og:title" content="How to Monitor API Latency">
<meta property="og:type" content="article">
<meta property="og:description" content="A practical guide to measuring and debugging API latency.">
<meta property="og:url" content="https://example.com/guides/api-latency">
<meta property="og:image" content="https://example.com/images/api-latency-card.png">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="How to Monitor API Latency">
<meta name="twitter:description" content="A practical guide to measuring and debugging API latency.">
<meta name="twitter:image" content="https://example.com/images/api-latency-card.png">
</head>
<body>...</body>
</html>
What each field does
| Field | Purpose |
|---|---|
og:title |
Title shown in an Open Graph preview. |
og:type |
Describes the object type, such as an article. |
og:description |
Short summary for the preview. |
og:url |
Canonical URL that identifies the shared object. |
og:image |
URL of the representative preview image. |
twitter:card |
Requests an X card presentation, such as summary_large_image. |
twitter:title, twitter:description, twitter:image |
X-specific title, summary, and image values. |
Adding social cards in common site setups
Static HTML
Write the tags directly in each page template. Generate the values from that page’s title, summary, canonical URL, and image path so every article does not share the same card.
Server-rendered applications
Render the tags in the initial HTML response. A crawler must be able to fetch the deployed URL and see the metadata in the response source; tags added only after client-side interaction may not be read consistently.
Single-page applications
Prefer server-side rendering or pre-rendering for shareable routes. For client-only rendering, inspect the actual response and confirm that the metadata is present before JavaScript runs.
Content management systems
Use the page’s SEO or social settings to set a unique title, description, canonical URL, and image. Then inspect the generated HTML rather than trusting the editor preview.
Inspect the HTML that crawlers receive
Check the deployed URL, not only a local source file. The following commands retrieve the response so you can search for the tags.
curl -L "https://example.com/guides/api-latency" | grep -Ei 'og:|twitter:|canonical'
python - <<'PY'
import requests
from bs4 import BeautifulSoup
url = "https://example.com/guides/api-latency"
r = requests.get(url, timeout=30)
r.raise_for_status()
soup = BeautifulSoup(r.text, "html.parser")
for tag in soup.find_all("meta"):
key = tag.get("property") or tag.get("name")
if key and (key.startswith("og:") or key.startswith("twitter:")):
print(key, "=", tag.get("content"))
canonical = soup.find("link", rel="canonical")
print("canonical =", canonical.get("href") if canonical else None)
PY
const url = 'https://example.com/guides/api-latency';
const html = await (await fetch(url)).text();
for (const match of html.matchAll(/<meta\s+[^>]*(?:property|name)=["']([^"']+)["'][^>]*content=["']([^"']*)["'][^>]*>/gi)) {
const [, key, value] = match;
if (key.startsWith('og:') || key.startsWith('twitter:')) console.log(key, '=', value);
}
Also inspect the canonical link and confirm that the image URL points to the intended asset. The source you inspect should be the same URL you give the sharing platform.
Preview and validation checklist
- Use a unique title and description for each page.
- Set
og:urland the canonical link to the page’s preferred URL. - Use an absolute, publicly reachable image URL.
- Keep Open Graph and X values synchronized unless you intentionally want different copy.
- Fetch the deployed HTML and verify the tags are present in the response.
- Check the preview on each destination service. Platforms can interpret fields and cache results differently.
- After publishing, share the final URL rather than a redirecting or staging URL.
Common problems and fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| No preview appears | The crawler cannot fetch the page, or metadata is absent from the served HTML. | Request the deployed URL with curl -L, confirm the tags exist, and check access rules and redirects. |
| Wrong title or image | Another template value is being emitted, or a platform has a cached preview. | Inspect the final HTML, make values page-specific, then use the destination platform’s current refresh or inspection facility when available. |
| Canonical URL is wrong | og:url and the canonical link point to a different route. |
Set both to the preferred permanent URL and ensure redirects resolve there. |
| X preview differs from Open Graph | X fields have different values or the platform applies different interpretation. | Set the twitter: fields explicitly and inspect the URL on X. |
| Image is missing | The image URL is relative, inaccessible, or not the intended asset. | Use an absolute URL reachable by the crawler and verify it from an external request. |
| Local preview works but production does not | The deployed build omitted head tags or generated them only in the browser. | Inspect production response HTML and move metadata into server-rendered or pre-rendered output. |
Performance, reliability, and maintenance
Social-card generation adds a crawler request to your page, so keep the shared URL reliable and make metadata available early in the response. Use stable canonical URLs and image URLs, avoid changing card assets unnecessarily, and validate after template or routing changes. Platform cache windows and image constraints vary; treat any preview as platform-specific and verify it directly.
For large sites, generate metadata from structured page data instead of copying tags by hand. Add a release check that fetches representative URLs and confirms the required Open Graph and X fields. This catches missing tags, broken URLs, and template regressions before a campaign or release.
Or skip the browser setup
If you need a visual check of the deployed page, ScreenshotNeo can capture it through one request. Its API accepts a URL and returns a PNG, JPEG, WebP, or PDF. Cookie and consent banners, newsletter popups, and chat widgets are removed before the shot. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and response headers identify the page verdict and whether it was billed. An MCP server lets Claude, Cursor, and other MCP clients use take_screenshot, get_page_info, and capture_pdf.
See the ScreenshotNeo API documentation for all options.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com/guides/api-latency -o social-card-page.webp
import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://example.com/guides/api-latency"}, timeout=90)
r.raise_for_status()
open("social-card-page.webp", "wb").write(r.content)
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com/guides/api-latency' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot failed: ${res.status}`);
const data = Buffer.from(await res.arrayBuffer());
await require('node:fs/promises').writeFile('social-card-page.webp', data);
The Free plan includes 1,000 screenshots per month with no card. Paid plans start at $5 for 3,000 shots, and every feature is available on every plan. Create a free ScreenshotNeo account.
FAQ
Is a social card a separate image file?
Usually, no. It is a preview assembled by a platform from your page metadata and referenced image. The image is one component of the card.
Do I need both Open Graph and X tags?
Publishing both gives you explicit values for both metadata systems, but each destination decides how it interprets them. Verify the services you use.
Why does the card look different across platforms?
Platforms control layout, field interpretation, image handling, and caching. The same HTML can therefore produce different previews.
What is the fastest way to diagnose a stale card?
Inspect the deployed HTML first, then use the destination platform’s current inspection or preview tool if it provides one. Confirm that the URL, title, description, and image are the values you intended.


