Open Graph vs Twitter Cards: Why a Perfect og:image Can Still Show a Tiny Thumbnail on X

Open Graph tags don't actually control how your links look on X (formerly Twitter) by default — a separate set of "Twitter Card" tags does, and the fallback behavior when only one set is present isn't always what you'd expect

The Open Graph protocol (og: tags), originally developed by Facebook, has become the de facto standard that most platforms reference when generating link previews — but X/Twitter developed its own, separate tag namespace (twitter: tags, "Twitter Cards") before widely adopting Open Graph fallback support. Understanding both systems — and specifically when a platform falls back from one to the other — explains why a link preview might look correct on Facebook/LinkedIn but different (or missing elements) on X.

The two tag namespaces

Open Graph (og:):

<meta property="og:title" content="Page Title">
<meta property="og:description" content="Page description text">
<meta property="og:image" content="https://example.com/image.jpg">
<meta property="og:url" content="https://example.com/page">
<meta property="og:type" content="website">

Twitter Cards (twitter:):

<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="Page Title">
<meta name="twitter:description" content="Page description text">
<meta name="twitter:image" content="https://example.com/image.jpg">

The overlap is substantial — twitter:title/twitter:description/twitter:image correspond closely to og:title/og:description/og:image — but they are technically separate attributes, read by different platforms' parsers.

X/Twitter's fallback behavior: twitter:card is the critical tag

X's card-rendering system checks for twitter: tags first — but does fall back to corresponding og: tags for some fields if the twitter: equivalent is absent (e.g., if twitter:title is missing but og:title is present, X's parser may use og:title).

However, twitter:card itself has no Open Graph equivalent — this tag specifies which type of card layout to use (summary, summary_large_image, app, player, etc.), and there's no og: tag that conveys this information. If twitter:card is absent entirely, the fallback behavior can result in a default (often smaller/less prominent) card layout — even if og:image and other Open Graph tags are fully and correctly present — because the specific instruction of "use the large-image card layout" (summary_large_image) has no Open-Graph-based substitute.

The practical symptom: a page with complete Open Graph tags (title, description, large image, all correctly set) but missing twitter:card might render with a small thumbnail (or no image at all) on X — while the same page renders with a large, prominent image on Facebook/LinkedIn (which primarily use Open Graph and don't need a "card type" instruction in the same way) — creating an inconsistent appearance across platforms that can be confusing to diagnose if you're only checking Open Graph tags and not aware of the separate, X-specific twitter:card requirement.

Card types and their layouts

summary: a small, square-ish image alongside title/description — compact card layout.

summary_large_image: a large, prominent image (typically displayed at a wider aspect ratio) above/alongside title/description — the layout most commonly desired for content-sharing purposes, given its visual prominence in the feed.

app: designed for promoting mobile apps — includes app-store links/identifiers rather than a generic webpage preview.

player: for embeddable media (video/audio) — allows the content itself (a video player, for instance) to be embedded inline within the X feed, rather than just a static preview image linking out to the content — requires additional twitter:player tags specifying the embed URL, dimensions, etc., beyond the basic title/description/image tags.

Choosing summary_large_image for most content-sharing purposes is the most common recommendation for blog posts, articles, and similar content — the large-image format is generally more visually engaging in feeds, contributing to (though not solely determining) click-through rates.

Image dimension requirements differ between platforms

Open Graph (for Facebook/LinkedIn primarily): recommended minimum dimensions are often cited around 1200x630 pixels (a roughly 1.91:1 aspect ratio) for og:image — images significantly smaller than recommended minimums may be displayed at reduced prominence, or in some cases not used at all if below certain absolute minimum thresholds.

Twitter Cards (summary_large_image): has its own recommended dimensions/aspect ratio — historically cited around a 2:1 aspect ratio (e.g., 1200x600), which is similar but not identical to the Open Graph recommendation (1.91:1) — meaning an image optimized for one platform's exact recommended ratio might display with some cropping/letterboxing on the other platform, if that platform's renderer enforces its own aspect ratio strictly on an image that doesn't precisely match.

Practical approach: using a single image that's reasonably close to both platforms' recommendations (often landing in a range that works "well enough" for both, even if not pixel-perfect for either's exact preferred ratio) is the common pragmatic choice — most sites don't generate separate images specifically sized for each platform's exact preferred dimensions, accepting minor cropping differences as a trade-off against the complexity of maintaining multiple image variants per piece of content.

LinkedIn: another partial-overlap case

LinkedIn primarily uses Open Graph tags — og:title, og:description, og:image — generally without requiring/using twitter:-namespace tags at all (LinkedIn's parser doesn't specifically need twitter:card the way X does, since LinkedIn's card layout isn't selected via that specific mechanism).

LinkedIn-specific quirks (historically): LinkedIn's link-preview cache has, at various times, been known for being particularly aggressive about caching previews once generated — meaning if a page's Open Graph tags are updated (e.g., correcting a previously-incorrect og:image), LinkedIn might continue showing the old, cached preview for a substantial period, requiring the use of LinkedIn's own "Post Inspector" tool (a cache-refresh-triggering tool, similar in purpose to Facebook's "Sharing Debugger" tool, both of which allow manually triggering a re-fetch of a URL's Open Graph data, bypassing the otherwise potentially-stale cache) to force an update to the cached preview.

Messaging apps and other platforms: largely Open Graph–based, with their own quirks

WhatsApp, Telegram, Slack, Discord, and many other platforms that generate link previews generally rely on Open Graph tags as the primary source — though each platform's specific parser can have its own quirks (image size limits, caching behavior, support for some but not all Open Graph fields) that aren't universally documented/consistent — meaning "correct Open Graph tags" provides a strong baseline for most platforms, but perfect rendering across every platform a link might be shared on isn't fully guaranteed by any single set of tags, given the diversity of independently-implemented parsers across the many platforms where links get shared.

How to use the Open Graph Generator on sadiqbd.com

1. Generate both Open Graph and Twitter Card tags together — ensuring twitter:card (with no Open Graph equivalent) is explicitly set, alongside the Open Graph tags that serve as the broader baseline for most other platforms
2. For summary_large_image card type: verify the specified image meets both platforms' general size recommendations reasonably well, accepting minor aspect-ratio differences as a practical trade-off
3. After updating tags on an existing, previously-shared URL: use Facebook's Sharing Debugger and/or LinkedIn's Post Inspector to force a cache-refresh — without this, platforms may continue displaying previously-cached (now outdated) preview data, regardless of how correct the current tags are

Frequently Asked Questions

If I only have time/resources to implement one tag set, which should I prioritize — Open Graph or Twitter Cards? Open Graph provides the broader baseline (used as the primary or fallback source by most platforms, including X for several fields) — but twitter:card specifically has no substitute, so even a minimal addition of just <meta name="twitter:card" content="summary_large_image"> (alongside otherwise-complete Open Graph tags) captures most of the practical benefit for X specifically, without requiring the full duplication of every twitter: tag — since the other twitter: fields (title, description, image) do fall back to their og: equivalents when absent, as discussed.

Why does my link preview sometimes show an old image/title that I've since changed on the page? This is almost always a caching issue at the platform level (Facebook, LinkedIn, X, etc. cache the Open Graph/Twitter Card data they first fetched for a given URL, and don't necessarily re-fetch on every subsequent share) — the page itself having updated, correct tags doesn't automatically update previously-cached preview data on platforms where the link has already been shared/cached. Platform-specific cache-refresh tools (Facebook Sharing Debugger, LinkedIn Post Inspector, and similar where available for other platforms) are the mechanism for forcing re-fetch of updated tag data for already-cached URLs.

Is the Open Graph Generator free? Yes — completely free, no sign-up required.

Try the Open Graph Generator free at sadiqbd.com — generate both Open Graph and Twitter Card tags together for consistent link previews across platforms.