In X/Twitter card markup, what does <meta name="twitter:card" content="summary_large_image"> change compared with content="summary", and which Open Graph tags does the card fall back to if you omit twitter:title, twitter:description and twitter:image?
answer
- layout selector versus content tags
- small square thumbnail or wide banner
- one tag with no Open Graph equivalent
- fallback runs twitter to og, never back
- name attribute here, property over there
basics
~20 ssummary_large_image renders a wide banner card with the image above the text, while summary renders a small square thumbnail beside it. Omitted twitter:title, twitter:description and twitter:image fall back to og:title, og:description and og:image; twitter:card itself has no Open Graph equivalent.
solid answer
~40 s`twitter:card` selects the card layout. `summary` gives a compact card with a small square thumbnail next to the title and description; `summary_large_image` gives a full-width banner with the image on top, which is what most content sites want. Other documented values are `app` and `player`. The content tags — `twitter:title`, `twitter:description`, `twitter:image` — are optional if you already have Open Graph: X falls back to `og:title`, `og:description` and `og:image` when the twitter-namespaced ones are absent, so most sites emit a full Open Graph block and add only `twitter:card` plus attribution tags like `twitter:site` and `twitter:creator`. The card type itself has no Open Graph counterpart, so if you want the large layout you must declare it explicitly. Note that these tags use `name`, not `property`.
go deeper
Know the two common values — summary for a small thumbnail card, summary_large_image for a wide banner — and that these tags use the name attribute.
Explain the one-way fallback to Open Graph, why a lean head emits only twitter:card plus attribution, and why the card type itself cannot be inherited from og.
An interviewer expects you to reason about drift: duplicated title and description strings across two vocabularies rot at different rates, so decide deliberately which surface gets bespoke copy.
Own the standard for the organisation — which vocabularies are mandatory, who authors card art per card type, and how that is verified before a launch rather than after.
## Two vocabularies, one head A page that wants good previews everywhere usually carries two overlapping sets of tags: the Open Graph block, read by nearly every platform, and a smaller `twitter:*` block read by X. They are not competitors — X reads Open Graph too — so the practical question is which twitter tags actually earn their place. ## What the card types mean `twitter:card` is the one tag with no Open Graph equivalent, and it chooses the layout: - **`summary`** — the compact card. A small, roughly square image sits beside the title and description. Suitable when your art is a logo or an avatar rather than a designed banner. - **`summary_large_image`** — the banner card. A wide image, roughly 2:1, sits above the title and description and dominates the post. This is the default choice for articles, docs and marketing pages. - **`app`** — a card for a mobile app listing, driven by app-id tags rather than a page image. - **`player`** — a card that embeds a playable media iframe, and which requires going through X's approval process; you will almost never author one in an interview answer. ```html <meta name="twitter:card" content="summary_large_image"> <meta name="twitter:site" content="@example"> <meta name="twitter:creator" content="@ada"> ``` ## The fallback rule X documents that when a `twitter:*` content tag is missing, it uses the Open Graph equivalent: `og:title` for `twitter:title`, `og:description` for `twitter:description`, `og:image` for `twitter:image`. This is why the leanest correct markup for a modern site is a complete Open Graph block plus two or three twitter tags — the card type and the attribution handles — rather than a full duplicate set. The fallback runs one way only. Open Graph consumers do not read `twitter:*` tags, so a page that carries only twitter tags previews badly in Slack, LinkedIn, iMessage and everywhere else. If you are going to write one vocabulary, write Open Graph. The exception to leanness is when the two surfaces genuinely want different text — for example a punchier title for a feed than for a Slack unfurl. Then emit `twitter:title` deliberately, knowing it overrides the fallback. ## Attribution tags `twitter:site` names the account the content belongs to, and `twitter:creator` the author's account; both take an `@handle`. They are what puts a byline on the card. `twitter:image:alt` provides alternative text for the card image, the twitter-namespaced counterpart of `og:image:alt`. None of these change the layout. ## Image constraints differ by card type Because the two card types frame images differently, the same file will not serve both well. A `summary_large_image` card wants roughly a 2:1 image; a `summary` card wants roughly 1:1 and crops a wide banner to a square, which usually decapitates any text you baked into it. X documents a 5 MB ceiling for card images and supports JPEG, PNG, WebP and GIF, with animated GIFs reduced to their first frame; SVG is not supported. In practice, pick one card type per site, design the art for it, and check the crop. ## Getting the attribute right `twitter:*` tags are ordinary named metadata: `<meta name="twitter:card" ...>`. Open Graph tags are RDFa terms: `<meta property="og:title" ...>`. Writing `property="twitter:card"` is a frequent copy-paste error, and because a page in that state still previews on non-X platforms from its Open Graph tags, the mistake tends to survive review. When a card renders correctly in Slack but shows the small layout on X, mismatched attributes are the first thing to check, right after confirming that `twitter:card` is present at all. ## What it does not control Card markup does not control fonts, colours, corner radius or button text — the platform owns the rendering entirely. It does not control whether a card appears on a given surface, since platforms decide that themselves, sometimes suppressing cards from accounts or domains they distrust. And it has nothing to do with search: these tags exist to make a shared link legible in a feed.
- If X falls back to Open Graph anyway, is there any reason to emit twitter:title and twitter:description?Only when you deliberately want different copy on that surface — a shorter, punchier title for a feed than for a Slack unfurl or a LinkedIn post. Emitting duplicates of the Open Graph values buys nothing and doubles the number of strings that can drift out of sync during a redesign. Keep `twitter:card`, the attribution handles, and let the rest fall back.
- A page carries a full twitter:* block but no Open Graph tags. What breaks?Everything except X. Slack, LinkedIn, Discord, iMessage and Facebook read Open Graph and do not consume twitter-namespaced tags, so those links unfurl with whatever the scraper can guess from `<title>` and page content. The fallback only runs from twitter to Open Graph, never the reverse, so Open Graph is the block you cannot skip.
- Why does the same image often look wrong when you switch twitter:card from summary_large_image to summary?Because the two layouts frame differently. The large card shows a roughly 2:1 banner; the summary card shows a roughly square thumbnail and centre-crops a wide image to get there, cutting off whatever sat near the left and right edges — usually the text baked into the banner. Design for the card type you declare, and keep important content centred.
saying these in an interview costs you the question
- Writes twitter:card with property= instead of name=
- Believes Open Graph consumers read twitter:* tags
- Duplicates every og tag as a twitter tag for no reason
- Thinks summary_large_image only means a bigger file
- Assumes the card type also changes fonts or colours