Short answer first: you don't need to duplicate everything. X/Twitter's card processor checks twitter:* tags first, then falls back to whatever Open Graph tags it finds. So if you've got OG in place, you're mostly already covered. The only Twitter-specific tags that actually add something are twitter:card and twitter:site — and maybe twitter:creator if you care about attribution.
That's the post, really. But since the "which tags do what" question always leads to "wait, so which platform reads which" and then "hold on, do I need separate tags for each?", let's get into it.
Where these two things came from
Open Graph was created by Facebook in 2010 and published as an open protocol at ogp.me. The goal was to give any page on the web a way to describe itself — title, description, image, type — so that when someone shared a link, the preview wasn't just a URL and a prayer. LinkedIn, Slack, Discord, iMessage, WhatsApp, and basically every platform that shows link previews adopted it. It became the de facto standard for social metadata.
Twitter Cards came later as Twitter's own format. Same idea, different namespace. The twitter:* tags let you control how links appear in tweets, and they added some card types that OG doesn't have — namely app and player cards for deep-linking to apps or embedding video.
The critical thing that changed the calculus: Twitter added fallback behavior. If twitter:title is missing, it reads og:title. If twitter:image is missing, it reads og:image. This means your OG implementation does double duty — it covers Twitter automatically for all the core stuff.
If you want to read the full breakdown of what lives in <head> and why, meta tags for SEO and social sharing covers the whole picture.
The actual differences
| Open Graph | Twitter Cards | |
|---|---|---|
| Who created it | Facebook (2010) | Twitter/X |
| Namespace | property="og:*" |
name="twitter:*" |
| Platform support | Everywhere (Facebook, LinkedIn, Slack, Discord, iMessage, WhatsApp, and more) | X/Twitter only |
| Card types | website, article, video, music etc. |
summary, summary_large_image, app, player |
| Fallback behavior | N/A — it is the fallback | Falls back to OG for all core tags |
| When you need Twitter-specific tags | Never, for core content | For app/player cards, explicit summary_large_image, and attribution (twitter:site, twitter:creator) |
The thing that trips people up is that twitter:card has no OG equivalent. Open Graph doesn't have a concept of "card type" — it just has og:type, which maps to content types like article or website, not layout types. So Twitter's twitter:card is genuinely extra. You need to declare it if you want a specific card format.
What twitter:card actually controls
There are four card types, but two of them you'll realistically use:
summary — small thumbnail image on the left, text on the right. Compact. Fine for most things but not great for visual content.
summary_large_image — the full-width image above the tweet text. This is what you want for blog posts, articles, and anything where the image is doing real work. It's also what makes the difference between a link that people stop on and one they scroll past.
app — links to an iOS or Android app directly. Has specific fields for app store ID, country, and URL. Only relevant if you're promoting an app.
player — embeds a video/audio player inline. Requires an HTTPS player URL and specific dimensions. Needs Twitter approval for broader use, so probably not worth chasing unless you have a specific video use case.
For a standard blog post or article: summary_large_image. That's the one.
twitter:site and twitter:creator
These two tags aren't about layout — they're about attribution. twitter:site is the @username of the website's Twitter account. twitter:creator is the @username of the content's author.
Neither affects how the card renders visually on X in any dramatic way, but they do show up in some contexts and they're good hygiene for attribution. If you have a Twitter/X account, add twitter:site. If individual posts have different authors who are on Twitter, twitter:creator per-post makes sense. If not, skip it — it's optional.
The minimum setup
Open Graph covers you on every platform except for card type and attribution. Here's the minimum that gives you proper previews everywhere:
<!-- Open Graph — the foundation, required -->
<meta property="og:title" content="Your page title" />
<meta property="og:description" content="Your description — 120–160 chars" />
<meta property="og:image" content="https://yourdomain.com/your-image.jpg" />
<meta property="og:type" content="article" />
<meta property="og:url" content="https://yourdomain.com/your-page" />
<!-- Twitter/X — the two that actually add something -->
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:site" content="@yourusername" />
That's it. Seven tags. Everything else is either covered by OG fallback or genuinely optional.
The og:image here is doing the heavy lifting for both platforms — X reads it via fallback, every other platform reads it directly. The image needs to be an absolute URL (no relative paths), and for summary_large_image specifically, you want something at least 300×157 and ideally 1200×675 for the full-width card to look right. The full breakdown on dimensions, aspect ratios, and the file-size ceiling that decides whether crawlers even load your image: og:image size guide.
And if you want to understand the full Open Graph tag set — og:image:alt, og:image:width, the absolute-URL gotcha — the dedicated piece is here: Open Graph tags explained.
When you actually need more than the minimum
Most content sites don't. The seven tags above cover the vast majority of use cases.
You'd go beyond that for:
App promotion — if you're linking to an app on the App Store or Play Store, twitter:card=app with the relevant store fields gets you a card with a direct install button on X. Worth it if app downloads are the goal.
Video content — twitter:card=player lets you embed a video player inline. The setup is involved and requires Twitter to whitelist your player URL. Unless video is your core product, this probably isn't worth it.
Multi-author publications — if different posts genuinely have different authors who are active on Twitter, per-post twitter:creator attribution is worth adding.
Explicit card type control — if you're on a platform that defaults to summary and you want summary_large_image, you can't rely on OG fallback to set that. It has to be explicit. This is the most common reason people add twitter:card even when they already have full OG coverage.
The "do I need to duplicate everything?" answer
No. Concretely:
twitter:title— skip it. X readsog:title.twitter:description— skip it. X readsog:description.twitter:image— skip it unless you specifically want a different image for X. X readsog:image.twitter:card— add this. No OG equivalent.twitter:site— add this if you have an X account.twitter:creator— add per-post if it's relevant.twitter:app:*andtwitter:player:*— only if you're doing app or video cards.
The duplication instinct comes from old tutorials written before Twitter added fallback behavior, or from generators that spit out every possible tag "just to be safe." Safe, but unnecessary.
Sources (retrieved 2026-06-03):
- X Developer Platform — Twitter Cards getting started guide — card types, fallback behavior, tag reference
- The Open Graph protocol — ogp.me — origin, tag definitions, type system