Twitter Card Not Working: The Most Common Causes and Fixes

A Twitter Card not working shows up as a link on X (formerly Twitter) that renders as plain blue text with no image, no title, and no description — just the raw URL with nothing else. Unlike Facebook, X doesn't offer an official public validator with a manual re-scrape button, which makes this category of bug harder to diagnose by trial and error. The causes are still a fairly short, well-known list, though, and working through them in order resolves most cases.

Confirm the twitter:card tag actually exists

The Twitter Card system needs a specific meta tag — name="twitter:card" with a content value, typically summary or summary_large_image — that isn't part of the Open Graph spec Facebook and most other platforms use. X does fall back to some Open Graph tags when Twitter-specific ones are missing, but that fallback isn't complete or fully reliable, and relying on it is a common reason a card renders inconsistently or not at all. Check your page's raw source for an explicit twitter:card tag before assuming your og:* tags alone are sufficient.

Check you're using summary_large_image, not summary, if you want a large image

This is a frequent point of confusion: twitter:card has more than one valid value, and they render very differently. summary produces a small, square-ish thumbnail alongside the text. summary_large_image produces the full-width image card most people picture when they think of a Twitter Card. If your card is rendering but the image looks cropped into a small square instead of the wide banner you expected, you likely have twitter:card set to summary rather than summary_large_image — this isn't a bug, it's the tag doing exactly what it says, just not what you intended.

Verify the twitter:image tag or a compatible og:image fallback

X will use a dedicated twitter:image tag if present, and will generally fall back to og:image if it isn't — but the fallback behavior has been inconsistent enough over time that relying on it exclusively is riskier than setting twitter:image explicitly. The same rules that apply to og:image apply here: it needs to be an absolute URL, publicly reachable with no authentication, and within X's accepted size and format ranges. An oversized file, an image behind a login wall, or a relative URL path will all cause the image to fail silently, same as with Open Graph.

Check the aspect ratio for summary_large_image specifically

summary_large_image cards expect roughly a 2:1 aspect ratio (a 1200x630 image is the commonly used standard, matching what most platforms expect for og:image as well). An image with a very different aspect ratio — a tall portrait image, for instance — may get rejected or cropped in an unexpected way rather than rendering as intended. If your image loads fine as a summary card but fails specifically when you switch to summary_large_image, aspect ratio mismatch is worth checking before anything else.

Account and app-level restrictions

Less common, but worth ruling out: X has at points applied restrictions on card rendering related to account standing, and some domains have had card rendering suppressed by platform-level policy independent of anything wrong with the markup itself. If every check above passes cleanly — the tags are correct, the image loads, the aspect ratio is right — and the card still won't render for a specific domain while working fine on a test page elsewhere, this is worth considering, though it's genuinely rarer than a markup issue and shouldn't be your first assumption.

There's no official public re-scrape tool — use a cache-busting URL instead

Unlike Facebook's Sharing Debugger or LinkedIn's Post Inspector, X does not provide a widely available public tool to force a re-fetch of a specific URL's card. If you've fixed an issue and the card still isn't rendering when you post the link, it's often because X has already cached a failed or empty result from before your fix. The practical workaround is to change the URL slightly — add or modify a query parameter — so X treats it as a URL it hasn't seen before and fetches it fresh, rather than reusing the empty cached result.

A focused checklist for Twitter Card issues

1. Confirm an explicit twitter:card tag exists, rather than relying on Open Graph fallback alone
2. Check the value is summary_large_image if you expect a full-width image card
3. Confirm twitter:image (or a working og:image fallback) points to an absolute, publicly reachable URL
4. Check the image's aspect ratio is close to 2:1 for summary_large_image
5. Confirm the image is within X's accepted file size and format range
6. If a fix doesn't seem to take effect, try a cache-busting query parameter rather than assuming the fix failed

The difference between an og:type mismatch and a genuinely broken card

Another subtle cause worth checking, particularly for pages that aren't standard articles or products — a video landing page, an app download page, a podcast episode — is an og:type value that doesn't match what the page actually is. X's card rendering can behave differently depending on the declared type, and a mismatch (declaring website when the content is really more like an article, for instance) doesn't always throw an error, but can result in a card that renders with unexpected fields or falls back to a plainer layout than intended. This is easy to overlook because it's not a hard failure — the card still shows something, just not quite what you'd expect from the content. If your card renders but looks visually 'off' compared to similar pages on the same site, checking whether og:type is set consistently across those pages is worth the few minutes it takes.

A note on domains that have never worked, versus domains that recently broke

It's worth treating these as genuinely different investigations, because the likely cause differs. A domain where cards have never rendered correctly, on any page, points toward a fundamental setup issue — no twitter:card tag anywhere in your templates, a sitewide robots.txt rule blocking the crawler, or a shared layout component that never got the Twitter-specific tags added in the first place. A domain where cards worked previously and recently stopped, especially if it's isolated to certain pages rather than the whole site, points more toward a recent deploy, a CDN configuration change, or a shift in how a specific page's content is rendered (a move from server-side to client-side rendering for that section, for instance). Narrowing down which of these you're dealing with before diving into tag-level debugging saves a fair amount of time, since the fix for a sitewide setup gap and the fix for a page-specific regression rarely overlap.

Testing before you rely on it in production

Because X doesn't have an equivalent to Facebook's debugger, the most reliable way to catch a broken card before it matters is testing with an actual post before a campaign depends on it — a scheduled announcement, a paid promotion, anything where the card rendering incorrectly has real cost. Posting to a private or draft-only account you control, or asking a colleague to paste the link and screenshot what they see, catches most of these issues before they're visible to a real audience.

Where useopengraph fits

useopengraph's OG image templates generate images sized correctly for the shared standard most platforms expect (including the 2:1 ratio X's summary_large_image card wants), so the aspect-ratio mismatch that quietly breaks large-image cards isn't something you have to separately verify per platform. The Cache Debugger also checks what X specifically would currently parse for a given URL alongside Facebook, LinkedIn, and other platforms in a single pass — useful precisely because X doesn't offer its own public debugging tool, so an independent check is otherwise hard to come by.