Open Graph Tags vs. Twitter Cards: Do You Need Both?
Open Graph is the protocol nearly every platform reads by default. Twitter/X has its own twitter:* tags and only falls back to og:* when they're missing. Here's what to actually put on your page.
August 9, 20264 min read
If you've ever pasted a link into Slack, iMessage, LinkedIn, or Discord and watched a title, description, and image appear, you were looking at Open Graph metadata. It's a protocol Facebook published in 2010, and it quietly became the default that almost every platform reads when it needs to render a link preview. Twitter/X is the one major exception with a metadata system of its own — and that's where the confusion about "do I need both" comes from.
What Open Graph actually is
Open Graph tags live in your page's <head> as og:* meta tags: og:title, og:description, og:image, og:url, og:type, and a handful of others. Any platform that wants to show a rich preview of a link — Facebook, LinkedIn, Slack, Discord, iMessage, WhatsApp — reads these tags when it crawls the URL. There's no separate registration or opt-in; if the tags are present and valid, the preview renders. This is why Open Graph is the one you should treat as non-negotiable: it's the baseline that covers the largest number of surfaces with the least amount of tag-specific work.
What Twitter Cards add
X maintains its own metadata namespace — twitter:card, twitter:title, twitter:description, twitter:image, and a few type-specific fields for player and app cards. X's crawler checks for twitter:* tags first. If it finds a valid twitter:card value, it uses the twitter:* fields to build the preview. If those tags are absent, X falls back to reading your og:title, og:description, and og:image instead. In practice this means a page with only Open Graph tags will still get a card on X — but you lose control over which card type renders, because that choice is made by the twitter:card value, and there's no Open Graph equivalent for it.
That's the actual technical relationship: Open Graph is the general-purpose protocol most platforms read unconditionally, and Twitter Cards are a platform-specific overlay that X checks first and only skips if it's missing. Neither replaces the other. Open Graph doesn't work on X's card-type selection, and Twitter Cards don't work anywhere except X.
The main card types and when they render
- summary — a small, roughly square image next to the title and description. Renders when twitter:card is set to "summary" or when X falls back to og:* tags without finding an explicit card type suited to a large image.
- summary_large_image — a full-width image above the title and description, the format most links use on X today. Requires twitter:card set explicitly to "summary_large_image"; there's no Open Graph field that triggers it.
- player — an embedded video or audio player that plays inline in the timeline. Requires additional twitter:player:* fields pointing at an embeddable player URL, not just a static image.
- app — a card promoting a mobile app with install buttons, built from twitter:app:* fields referencing App Store / Play Store IDs.
So: do you need both?
Yes, if you care how your links look on X specifically. Set full Open Graph tags for every other platform, and add twitter:card (almost always summary_large_image) so X doesn't default to the smaller summary layout or guess wrong. You generally don't need to duplicate twitter:title, twitter:description, or twitter:image if they're identical to your og:* values — X's fallback handles that for you. The one tag that has no Open Graph substitute, and the one most sites forget, is twitter:card itself.
What to actually put on your page
- og:title, og:description, og:image, og:url, og:type — the baseline every page needs regardless of platform.
- og:image at 1200x630px — the safe size that displays correctly across Facebook, LinkedIn, Slack, and X's large-image card without cropping oddly.
- twitter:card set to summary_large_image (or summary, player, app if that's a better fit) — this is the one tag Open Graph can't provide for you.
- twitter:title, twitter:description, twitter:image only if they need to differ from your og:* values — otherwise skip them and let the fallback do the work.
- Validate with a link-preview scanner before shipping, since a missing or malformed og:image is the single most common reason a preview silently fails to render.
This is exactly the gap useopengraph's dynamic OG images and free scanner are built around: generate correctly-sized og:image tags automatically, set twitter:card alongside them, and check the actual rendered output before a broken preview ships to production.
Stop paying per seat
for a usage-shaped problem.
Unlimited teammates, one usage pool. Start free with the scanner — no card required.