Open Graph vs Twitter Cards

Open Graph (Facebook’s meta vocabulary) and Twitter Cards (now used by X) are related but not identical. Most modern sites need both a solid Open Graph set and an explicit Twitter card type for predictable large images on X. This reference explains the overlap, og:type, and title/description length—without turning into a debugger walkthrough.

Generate aligned snippets with the Meta Tag Generator. Keep the OG tags cheat sheet nearby.

What each system is for

System	Typical properties	Primary consumers
Open Graph	og:title, og:description, og:image, og:url, og:type	Facebook, LinkedIn, WhatsApp, Slack, Discord, many others
Twitter Cards	twitter:card, twitter:title, twitter:description, twitter:image	X (Twitter)

Open Graph is the shared baseline. Twitter Cards add card layout control for X.

Minimal combined example

<meta property="og:type" content="article" />
<meta property="og:title" content="Ship notes for October" />
<meta property="og:description" content="What we released and how to try it." />
<meta property="og:url" content="https://example.com/blog/ship-notes/" />
<meta property="og:image" content="https://example.com/og/ship-notes.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />

<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:title" content="Ship notes for October" />
<meta name="twitter:description" content="What we released and how to try it." />
<meta name="twitter:image" content="https://example.com/og/ship-notes.png" />

When Twitter tags still matter

If you omit twitter:card, X may choose a small summary layout even when og:image is large. Setting summary_large_image is the usual fix. Full troubleshooting: Twitter card not showing image. Sizes: X image size.

You do not need Twitter tags for WhatsApp—WhatsApp reads Open Graph (WhatsApp guide).

og:type values (practical set)

Value	Use when
website	Marketing pages, tools, general URLs
article	Blog posts, guides, news stories

Other types exist in the Open Graph ecosystem; prefer these two unless you have a specific integration that documents another value. Wrong or exotic types rarely improve previews and sometimes confuse tooling.

Title and description length

Apps truncate differently. Practical guidance:

• og:title / twitter:title: Lead with the meaning in the first ~60 characters. Longer titles are clipped mid-phrase on some surfaces.
• og:description / twitter:description: About one or two short sentences. Front-load the point; the end may be cut.

These are editorial guidelines, not a single official global maximum published identically by every network. Design cards assuming truncation (best practices).

Avoid conflicting duplicates

Two SEO plugins emitting different og:title values create lottery behavior. Keep one pipeline (CMS settings, framework metadata, or a single layout component). Framework guides: Next.js, Astro, WordPress.

How to verify

1. View Source for both og:* and twitter:*.
2. Link Preview Checker.
3. Network-specific tools after HTML is correct (Facebook/LinkedIn); X often needs a URL variant for cache.

Checklist

• Open Graph complete with absolute image
• twitter:card=summary_large_image when you want large X cards
• og:type is website or article on purpose
• Titles/descriptions readable when truncated
• No duplicate conflicting tags

Universal image failures: og:image not showing.

Practical migration notes

Older sites may have only Facebook-oriented Open Graph tags. Adding twitter:card is a low-risk improvement when you care about X distribution. You rarely need to remove Open Graph to please X—extend, do not replace.

If a CMS offers a single “social description” field, map it to both og:description and twitter:description unless you have a reason to diverge. Divergent copy should be intentional (for example, a shorter X blurb) and documented so localization teams update both.

When auditing a large site, spreadsheet the presence of og:image and twitter:card per template type (home, article, product). Gaps usually cluster by template, not by individual pages, which makes framework-level fixes more valuable than one-off edits.

Field notes from real share failures

Most broken previews are boring: a relative URL, a duplicate plugin tag, a cache that nobody re-scraped, or a file that is fine in Chrome but too heavy for a messenger. Resist the urge to rewrite the entire brand system until those basics are proven in View Source and a private window.

Write down the exact URL string you tested, including trailing slash and query parameters. Support threads go sideways when one person scrapes example.com/page and another shares example.com/page/. Treat the share string as part of the specification.

When you finally change artwork, change the path. Overwriting og.png in place is the most common reason a “fixed” card never appears. Pair the new file with a short note in your changelog so the next person knows which version is live.

Verification habits worth repeating

After every deploy that touches templates or SEO plugins, spot-check three URLs: the homepage, one article or product, and one utility page. Look for a single absolute og:image and open that file logged out. This ten-minute habit catches more regressions than redesigning share cards.

Document the owner of social tags for your stack—theme, plugin, or layout component—in the repository README. When something breaks, people should know which lever to pull first. Ambiguous ownership is how duplicate tags accumulate.

Finally, separate “works in our browser” from “works for crawlers.” If you only validate inside an authenticated preview session, you will ship failures to Facebook, LinkedIn, Slack, Discord, WhatsApp, and X without noticing until a campaign is live.

If you only remember one rule, remember this: crawlers are blunt. They fetch a URL, read tags, fetch an image, and cache aggressively. Your CMS preview, authenticated browser session, and hydrated React tree are not part of that path. Design the HTML and the image file for the crawler first, and human polish second. That ordering keeps share cards reliable while you iterate on the visible page design. When in doubt, ship complete Open Graph plus twitter:card=summary_large_image and verify both in View Source before a product launch. That combination covers the widest set of consumers without exotic per-network types. Teams that standardize on that dual stack spend less time debugging “works on LinkedIn but not on X” tickets, because both networks see explicit, crawlable tags instead of relying on undocumented fallbacks.