A social card is the preview a social network or messaging app may create when someone shares a webpage link. The site supplies metadata—usually a title, description, image and canonical URL—in the page’s HTML head. A platform crawler fetches the URL, reads the metadata it can access, and assembles its own preview. The destination platform controls the final appearance, so a card is not a separate file and is never guaranteed to look identical everywhere.
What a social card contains
When a link is pasted into a post, chat or direct message, the service may show a title, summary, image, domain and other context beside the link. That assembled preview is the social card. It is generated from the shared page, rather than uploaded as a required standalone image.
The page owner describes the content with metadata. A crawler then requests the URL and interprets the metadata that is present and accessible. The platform may resize, crop, omit or replace values according to its own rules. Two services can therefore produce different cards from the same HTML.
How the process works
- Add metadata to the page. Put page-specific tags inside the HTML
<head>, normally during the CMS template or server-side rendering step. - A user shares the URL. The destination service receives the link and may request the page with its crawler.
- The crawler reads available values. It looks for title, description, image and URL fields, subject to access controls and its own parser.
- The service builds a preview. The platform chooses layout, image treatment and any fallback values, then displays the card in the feed or conversation.
- The preview may be cached. A later change to your tags might not appear immediately. Check the platform’s current preview or inspection facility when available.
Because the platform decides what to display, metadata is guidance rather than a command. Always inspect the deployed URL on the services where you intend to publish it.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →#1 Best Overall
Open Graph: the common foundation
The Open Graph protocol defines a small core of properties that let a web page become a rich object in a social graph. The four basic properties are:
| Property | Purpose | Typical value |
|---|---|---|
og:title |
The title of the shared object | What Is a Social Card? |
og:type |
The object type | article |
og:image |
A representative image URL | https://example.com/images/social-card.jpg |
og:url |
The canonical URL and permanent identifier for the object | https://example.com/guides/social-cards |
og:description is optional but generally recommended. Write a concise, page-specific summary rather than copying a site-wide slogan. Use an absolute, publicly reachable image URL and the canonical URL you want associated with the shared object.
X card metadata
X supports its own card vocabulary. Common fields include twitter:card, twitter:title, twitter:description and twitter:image. A page can include both Open Graph and X metadata. The names are related, but they are not interchangeable tags, and X or another platform may choose different fallback behavior over time.
| Metadata family | Examples | Use |
|---|---|---|
| Open Graph | og:title, og:type, og:image, og:url, og:description |
Broad social and messaging compatibility |
| X cards | twitter:card, twitter:title, twitter:description, twitter:image |
X-specific card instructions |
Do not assume that every platform will honor a particular field or use the same fallback. Treat the destination’s current preview as the source of truth.
Recommended Free Tools
A practical HTML example
Place tags in the document head generated for the individual page. Replace every example value with the page’s real information:
<head>
<title>What Is a Social Card? | Example Site</title>
<link rel="canonical" href="https://example.com/guides/social-cards">
<meta property="og:title" content="What Is a Social Card?">
<meta property="og:type" content="article">
<meta property="og:description" content="How webpage metadata becomes a social sharing preview.">
<meta property="og:url" content="https://example.com/guides/social-cards">
<meta property="og:image" content="https://example.com/images/social-card.jpg">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="What Is a Social Card?">
<meta name="twitter:description" content="How webpage metadata becomes a social sharing preview.">
<meta name="twitter:image" content="https://example.com/images/social-card.jpg">
</head>There is no universal image size, cache duration or rendering guarantee that applies to every service. Follow the current guidance for each destination and verify the result instead of relying on a template’s assumptions.
Implementing cards in a CMS or framework
Set values per page
Your title, description, canonical URL and image should describe the specific article, product or landing page. A single default image can make every share look identical and can mislead readers.
Render tags in the served HTML
Make sure the metadata exists in the HTML returned to a crawler. If JavaScript inserts tags only after a browser runs the application, a crawler may not see them. View the deployed page source or fetch the production URL and search for og: and twitter: values.
Use an accessible canonical URL and image
The URLs should be absolute and reachable by the destination crawler. Check redirects, authentication requirements, robots or firewall rules, and accidental staging domains. The image URL must point to the intended asset, not a local path or a URL that expires before the card is fetched.
Keep fallbacks intentional
Define sensible defaults for pages that lack custom social data, while allowing editors to override title, description and image. Do not let an empty field silently produce an unrelated site title or image.
How to verify a card before publishing
- Open the production URL, not only a local preview.
- Inspect the generated source and confirm one correct value for each intended field.
- Open the canonical URL and image URL directly from a network that can reach them without logging in.
- Paste the URL into the destination platform’s current card preview or inspection tool, if it provides one.
- Compare the displayed title, description, image and URL with the page you meant to share.
- If an old preview remains, allow for platform caching and use the platform’s refresh or re-scrape control when available.
Diagnosing missing or incorrect cards
No preview appears
- Confirm the shared text is a complete, publicly reachable URL.
- Check that the response is not blocked by authentication, a firewall, an interstitial or crawler restrictions.
- Inspect the deployed HTML; tags added in a client-only render may be absent from the crawler’s response.
- Test the destination’s own preview tool rather than assuming another service’s result predicts it.
The wrong title or description appears
- Search the served source for duplicate Open Graph or X tags and remove conflicting values.
- Check that your CMS did not output a site-wide default after the page-specific value.
- Confirm you shared the canonical URL and not a tracking, redirect or alternate-language URL.
- Use the platform’s refresh mechanism if the HTML is correct but the displayed value is old.
The wrong image appears
- Verify
og:imageandtwitter:imagepoint to the intended absolute URL. - Open the image URL directly and check that it returns the image without a login or expiring token.
- Look for duplicate tags, redirects to an HTML error page, or a platform-specific crop.
- Remember that the platform can select, crop or omit an image even when the tag is valid.
Only some platforms work
Different crawlers parse different fields and apply different policies. Keep both metadata families where appropriate, then test each destination independently. Do not infer a universal fallback rule from one successful service.
Inspecting a deployed page with a screenshot
A screenshot of the rendered page can help you confirm that the public URL loads the expected content, but it does not replace checking the HTML source. For automated checks, capture the production URL after deployment and compare it with your page-specific metadata and destination preview.
Or skip the browser setup
ScreenshotNeo provides a website screenshot API and MCP server. One GET request can return a PNG, JPEG, WebP or PDF. Before capture, it can accept the cookie or consent banner and remove more than 60 known consent platforms, newsletter popups and chat widgets; each step can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads and cache hits are not billed, and the response identifies the page verdict and billing status in X-Page-Verdict and X-Billed headers. Its MCP tools—take_screenshot, get_page_info and capture_pdf—let Claude, Cursor or another MCP client inspect pages.
See the ScreenshotNeo documentation for all options. A basic request for this article’s public URL is:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com/guides/social-cards -o shot.webpThe same request in Python:
import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://example.com/guides/social-cards"}, timeout=90)
open("shot.webp", "wb").write(r.content)And in Node.js:
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com/guides/social-cards' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);ScreenshotNeo supports full-page and element captures, device presets and custom viewports, retina scale, dark mode, waiting for a selector, delay or network idle, custom CSS and JavaScript, click and hide selectors, request blocking, headers, cookies, user agents, authorization, timezone and geolocation, transparent backgrounds, resizing, chosen cache TTLs, signed links, asynchronous webhooks, bulk capture of up to 100 URLs per call, a usage API and an OpenAPI specification. Parameter names used by other screenshot APIs also work, which can simplify migration.
The Free plan includes 1,000 screenshots per month with no card. Paid plans start at $5 for 3,000 shots; every feature is on every plan, and yearly billing gives two months free. Create a free ScreenshotNeo account to start without a card.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOperational and cost considerations
- Source correctness: A screenshot proves what rendered, while source inspection proves which metadata a crawler can read. Use both for release checks.
- Dynamic pages: Wait for the relevant selector or network idle when content or consent UI loads asynchronously.
- Privacy: Do not expose private URLs, cookies or authorization headers in a public capture workflow.
- Reproducibility: Fix viewport, device scale, timezone and user agent when comparing captures over time.
- Billing: For ScreenshotNeo, only clean shots are billed; failed loads, blank pages, bot checks, timeouts and cache hits are identified as non-billed outcomes.
What a social card is not
- It is not necessarily a separate image file that you upload to a network.
- It is not controlled solely by the page author; the destination can alter layout and content.
- It is not proof that every crawler saw the same HTML response.
- It is not a substitute for a useful page title, accessible content or a working canonical URL.
Frequently Asked Questions
Can I create a social card without Open Graph tags?
A platform may fall back to the document title, visible text or another value, but the result is service-dependent. Explicit Open Graph and, where relevant, X metadata gives you clearer control.
Best Value
Should every page use the same social-card image?
Use page-specific images when they improve recognition or explain the content. Keep a deliberate default for pages without custom artwork, and verify how each destination crops it.
Why does viewing source matter if the page looks correct in a browser?
A browser can execute JavaScript and load content that a crawler never receives. The served HTML shows whether the metadata is available at fetch time.
Will changing metadata immediately update an existing post?
Not necessarily. Platforms can cache fetched previews. Check the destination’s current refresh or inspection process and verify the newly deployed URL.
The Bottom Line
A social card is a platform-generated link preview driven by metadata in your page’s HTML. Define page-specific Open Graph and X fields, expose them in the deployed source, and verify the final URL on every destination you care about.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
