twittercard

Markup

twitter: vs og: tags: the fallback rules

How X chooses between twitter: and Open Graph tags, which twitter: tags have no og: fallback, name vs property, and the shortest head that still works.

Short answer

X reads twitter: tags first and falls back to the matching Open Graph tag when one is missing: twitter:title to og:title, twitter:description to og:description, twitter:image to og:image and twitter:image:alt to og:image:alt; twitter:card, twitter:site and the player and app tags have no og: equivalent.

Key takeaways

  • twitter:card has no real Open Graph replacement; set it explicitly.
  • og:title, og:description and og:image alone are enough text and image for an X card.
  • Use twitter: versions only when you want X to show something different.
  • Write twitter: tags with name= and og: tags with property=.

Pages often carry two parallel sets of social tags, and it is fair to wonder whether you need both. You mostly do not, but the one tag you cannot skip is the one people forget.

Which tag does X read first?

The twitter: tag; the og: tag is used only when the twitter: one is missing. X's markup reference lists the pairs explicitly:

X reads Falls back to
twitter:title og:title
twitter:description og:description
twitter:image og:image
twitter:image:alt og:image:alt
twitter:card og:type (only to infer a summary card)
twitter:site, twitter:creator nothing
twitter:player*, twitter:app:* nothing

The twitter:card row deserves a closer look. If a page has no twitter:card but does have og:type, og:title and og:description, X says it may render a summary card. There is no route from Open Graph to a large image card, so if you want the wide layout you must set twitter:card to summary_large_image yourself.

What is the shortest head that works well?

One twitter: tag plus the usual Open Graph set.

<meta name="twitter:card" content="summary_large_image">
<meta property="og:type" content="article">
<meta property="og:title" content="Notes from rebuilding our search index">
<meta property="og:description" content="What broke, what we measured, and the two changes that fixed it.">
<meta property="og:url" content="https://example.com/notes/search-index/">
<meta property="og:image" content="https://example.com/og/search-index.png">
<meta property="og:image:alt" content="Line chart of query latency falling after the rebuild">

That gives X everything it needs and gives LinkedIn, Facebook, Slack and iMessage the same information. Add twitter:site if you want the card tied to your account. Add og:image:width and og:image:height if you want Facebook and Discord to render the image without measuring it first.

When should I write separate twitter: tags?

When you want X to show something different from other platforms, or when your tooling makes explicit tags easier to audit. Some reasons that come up:

  • A different image. X crops large images to 2:1; LinkedIn and Facebook prefer about 1.91:1. If your image has text near the edges, point twitter:image at a 1200x600 version and og:image at a 1200x630 one.
  • A shorter title. X documents a 70-character limit for titles. If your og:title is long because it doubles as a headline elsewhere, a tighter twitter:title avoids truncation.
  • Plugin output. Yoast SEO and Rank Math both write separate X fields when you fill them in, and fall back to the Facebook/Open Graph values when you do not.

If you do write both, keep them in sync. The most confusing card bugs come from a template that updates og:image while an old hard-coded twitter:image keeps winning on X.

name= or property=?

twitter: tags use name, og: tags use property. That is how each specification writes them:

<meta name="twitter:card" content="summary">
<meta property="og:title" content="...">

Many parsers are forgiving. X will usually read property="twitter:card", and plenty of crawlers accept name="og:title". But forgiving is not the same as guaranteed, and some strict parsers follow the spec exactly. Writing each tag the documented way costs nothing. The inspector flags the swapped spellings as notes.

Do other platforms read twitter: tags?

A few do, which is one more reason to keep them accurate. Slack's link expander reads oEmbed, Twitter Card and Open Graph tags. Discord's documentation says it reads both og: and twitter: titles, descriptions and images, and uses twitter:card set to summary_large_image to pick its large image layout. Apple's Messages, LinkedIn and Facebook work from Open Graph. So a stale twitter:image can show up in a Discord embed too, not just on X.

What about og:type and og:url?

They are not card fields on X, but they are worth setting. og:type only matters to X in the fallback case described above, where it helps X decide to build a summary card when twitter:card is missing. Use website for home and landing pages and article for posts; Open Graph defines a few more types, but almost no platform treats them differently today.

og:url should be the page's canonical address. X shows the domain of the link that was posted, so og:url does not change what appears under the card. Facebook and LinkedIn, on the other hand, use it to group shares of the same page together, so a stray tracking parameter in a shared link still counts toward one URL. Keep it identical to your <link rel="canonical">; when the two disagree, different platforms may pick different addresses. The inspector warns when they differ.

There is also og:site_name, which Discord prints above the title and Apple recommends for the brand instead of stuffing it into og:title. It costs one line.

A quick audit routine

  1. View the page source and search for twitter: and og:.
  2. Check each field appears once per prefix, with the value you expect.
  3. Confirm twitter:card is present and spelled correctly.
  4. Confirm image URLs are absolute https URLs that load in a private window.
  5. Paste the head into the Card Preview & Meta Inspector; the "From" column shows which tag supplied each value.

When a page has no twitter: text tags at all and its card still looks right on X, that is the fallback working as designed, not luck.

Questions

If both tags exist with different values, which wins on X?

The twitter: tag. The og: tag is only a fallback. Other platforms such as LinkedIn and Facebook ignore twitter: tags and use the og: value.

Does X use the HTML title tag or meta description?

X's documentation only describes fallbacks to Open Graph. Do not rely on <title> or <meta name="description"> for X; set og:title and og:description.

Is twitter:image:src still valid?

It is an old spelling you still see on some sites. The current documented tag is twitter:image. Use that.

Is it bad to have duplicate tags?

Duplicating the same tag twice with different values is a problem, because parsers usually take the first and you cannot be sure which. Having both a twitter: and an og: version of a field is normal.

Sources

Keep reading