A page can have flawless Open Graph tags and still show a broken or generic card when someone posts the link on X. That surprises a lot of developers, because Open Graph is supposed to be the universal standard every platform reads from. X mostly does read it, except for a specific set of tags it checks first, and if those are missing, the fallback behavior isn't always graceful.
Twitter/X Cards Are a Layer on Top of Open Graph, Not a Replacement
The twitter:card family of meta tags, like twitter:title, twitter:description, and twitter:image, was originally built as its own system before Open Graph became the dominant standard. Today, X's crawler checks for twitter:* tags first and falls back to the equivalent og:* tags if they're absent. This is generally good news since it means you often don't need to duplicate everything. But "often" is doing a lot of work in that sentence.
Where the Fallback Actually Breaks
The gap shows up around twitter:card itself, the tag that decides whether the preview renders as a small thumbnail (summary) or a large, full-width image (summary_large_image). There's no Open Graph equivalent for this decision. If twitter:card is missing entirely, X tends to default to the smaller summary format even when your og:image is a large, high-quality banner meant to be the visual focus of the post. The image data was there. The instruction for how to display it wasn't.
twitter:image has its own aspect ratio expectations too, distinct from the roughly 1.91:1 ratio Open Graph generally expects. An image that looks fine as an Open Graph preview can get awkwardly cropped in a Twitter/X card because the two systems don't always agree on ideal proportions, and a crawler that falls back from a missing twitter:image to your og:image doesn't recrop it for you.
The Attribution Tags Nobody Thinks About
twitter:site and twitter:creator are two tags with no Open Graph equivalent at all. They attribute the shared content to an account handle, which shows up as a small byline on the card. Skip them and the card still works, but you lose free attribution every time the link gets shared, which for a content-heavy site adds up over time into a lot of missed brand visibility.
A Debugging Session That Illustrates the Gap
Picture a marketing page with a solid og:image set to a wide banner graphic, og:title and og:description both correctly filled in, and nothing under the twitter: namespace at all. Posted on Facebook or LinkedIn, the preview looks exactly right: full-width image, clean title. Posted on X, the same link shows a small, square-cropped thumbnail alongside the title, because the missing twitter:card tag caused X to default to the compact summary format instead of matching the large-image layout the page's Open Graph tags were clearly built for.
Nobody looking at the page's HTML would call anything "broken." Every tag present is valid. The problem is a single missing line that has no Open Graph equivalent to fall back to, which is exactly why it's easy to overlook during a normal review that's mostly checking for og: prefixes.
Server-Rendered vs Client-Rendered Tags Matter Here Too
The same rendering trap that affects Open Graph tags generally applies just as much to twitter: tags specifically. If these values get injected by client-side JavaScript after the page's initial HTML loads, X's crawler, which typically doesn't execute JavaScript when unfurling a link, never sees them. The page looks completely correct in a browser, since your own browser does run the script, which makes this particular failure mode especially confusing to diagnose without checking the raw, unrendered source directly.
Testing This Without Guessing
The most reliable way to check any of this is the same approach that works for Open Graph tags generally: view your raw page source (not the rendered DOM) and search for twitter: and og: prefixes directly. Reference documentation on how these meta elements are structured and parsed is available at developer.mozilla.org, and the base Open Graph specification itself lives at ogp.me if you need to confirm which og: properties exist to fall back to in the first place.
It's also worth testing on an actual test post rather than assuming the tags are correct because they look right in your editor. Cached previews and JavaScript-injected tags that a crawler never sees are both common enough that "it looks fine in my browser" tells you very little about what X's crawler actually received. web.dev has covered similar rendering gaps for other crawler-facing metadata, and the same debugging approach, checking raw source over rendered output, applies just as well here.
Why This Is Easy to Forget Under Deadline Pressure
Open Graph tags get more attention in most SEO checklists and CMS documentation simply because they're the older, more universal standard, and because Facebook and LinkedIn previews tend to be the ones teams check first when validating a new page. twitter: tags often end up as an afterthought added once, then forgotten on every subsequent page template unless someone specifically remembers to include them in whatever boilerplate gets copied forward. The result is a site where the first few pages have complete Twitter/X card tags and every page built afterward quietly doesn't, because nobody flagged it as a required field going forward.
This is exactly the kind of gap a fixed template or a generator catches automatically, but a manual, page-by-page process tends to miss, since there's no visible error to prompt someone to go back and check.
What This Costs You If You Never Fix It
The practical impact of skipping twitter: tags entirely isn't catastrophic, links still work, the page still gets shared, people still click through. But every card that renders as a small, cropped thumbnail instead of a full-width image is a small, repeated hit to how professional and deliberate a shared link looks, compounding across every single share the link ever gets. For content that lives primarily off social distribution, that's not a trivial cost even though it never shows up as a hard error anywhere in your analytics or your CMS.
It's also one of the easier wins available in technical SEO, precisely because it's so commonly skipped. A handful of extra lines in your page head, correctly set once in a template, fixes the problem permanently for every page that inherits from it, which is a better return on effort than most of the more involved technical fixes teams spend time on.
Writing Both Sets Without Duplicating Effort
The practical fix is treating twitter:* tags as a short, deliberate addition alongside your Open Graph tags rather than an afterthought. That's usually four extra lines: twitter:card, twitter:title, twitter:description, and twitter:image, plus twitter:site if you have a brand account worth attributing. It's not a lot of markup, but it's markup that's easy to forget because the fallback mostly works, right up until the specific case where it doesn't.
EvvyTools' free meta tag generator generates the Twitter/X card set alongside Open Graph and standard meta tags from the same source fields, specifically so this doesn't become a separate manual step that gets skipped under deadline pressure. Additional context on how tag mismatches show up across different platforms, including the caching quirks that make debugging this confusing, is covered in EvvyTools' longer piece on why meta tags don't display the way they were written.
If your Open Graph tags are solid but your X previews still look off, check for a missing twitter:card tag before anything else. It's a small, single line, and it's the one most commonly left out.
Top comments (0)