What Twitter Cards do
Twitter Cards are meta tags that control how your link looks when posted to X (Twitter). Without them, your tweet shows the URL as plain text and stops there. With them, the URL expands into a visual card with an image, a title, a description, and the site or author handle. That expansion alone is the difference between a tweet that gets scrolled past and a tweet that gets clicked.
X's own data has shown that tweets with cards earn 2 to 3 times more click-throughs than plain-link tweets. The card also signals legitimacy; users are less likely to click an unexpanded link, which now reads as suspicious or unconfigured. For any content distribution strategy that touches X, Twitter Card markup is non-optional.
The four card types and when to use each
summary is the original card type: a small square thumbnail to the left of the title and description. It works for any page but renders smaller in the feed than its larger sibling. Use it for podcasts, profile pages, and content where you do not have a strong visual asset.
summary_large_image is the dominant card style today. The image renders full-width above the text in a 2:1 aspect ratio, roughly 504 pixels wide on desktop. This is what most blogs, landing pages, and articles ship. If you have a quality og:image already, use this card type to make the most of it.
app is a card for native mobile apps that links directly to the App Store or Play Store. It includes app icon, name, and a deep link. Mostly used by app marketing teams. player is for video and audio embeds where the media plays inline within the tweet itself; it requires hosting on an https URL with an iframe whitelist registered with X.
Image specs for summary vs summary_large_image
For summary_large_image, use 1200 by 600 pixels (2:1) at minimum. Smaller images upscale and look soft. Larger images downscale fine. The hard maximum is 5 megabytes; aim for under 300 kilobytes for fast loading in feeds.
For summary, use 144 by 144 pixels at minimum, 4096 by 4096 at maximum, in a 1:1 aspect ratio. Logos and product thumbnails work well at this size. Detail-heavy images do not, since they get cropped and shrunk in the feed view.
Both card types support twitter:image:alt for accessibility. X reads the alt text aloud on screen-reader-driven sessions and uses it as a fallback when the image fails to load. Always include it, especially for image-only cards where the image carries information beyond decoration.
Site, creator, and domain attribution
twitter:site is the X handle of the publishing site (the company or brand). twitter:creator is the X handle of the individual author of the specific piece. Both display under the card title; twitter:creator is shown when present, with twitter:site as a fallback.
Use both if your site has multiple authors. The twitter:creator handle becomes a click-through to the author's X profile, which builds the author's individual following and rewards them for publishing on your site (a common request from contributing writers and an under-used tool for paid contributor programs).
The handles must include the @ symbol and reflect active accounts. Mistyped handles render the card without the attribution row but do not break the card otherwise. Verify against the live X account before deploying.
How Twitter falls back to Open Graph
If twitter:title, twitter:description, or twitter:image are missing, X falls back to the corresponding og:* tag (og:title, og:description, og:image). This means a page with complete Open Graph but no Twitter Card markup still gets a card, though without site or creator attribution and using the default summary_large_image style only if og:image meets the 2:1 ratio.
Practical implication: ship og:* first. Then add only the twitter:* tags that diverge from the og:* values. Most pages only need twitter:card (to specify the type), twitter:site (for attribution), and twitter:creator (for author attribution). The title, description, and image come through Open Graph.
The exception is when you want different content per platform. Some sites use a Twitter-friendly title (shorter, more clickbait-y) that differs from the LinkedIn-friendly title (more professional). In that case, set twitter:title and twitter:description explicitly and let og:* drive everywhere else.
Card validator and deployment
X retired its Card Validator tool in 2023, removing the public-facing way to test cards before posting. The current workflow is to post the URL into a draft tweet (without sending) and visually verify the preview, or use a private DM to yourself. If the card does not render, X is rejecting the markup or has not yet scraped the URL.
First scrapes happen on first share. After that, X caches the result for 7 days. If you change your card markup, the change will not appear until X re-scrapes. Posting the URL again from a different account often forces a re-scrape; in practice it is faster to bump the URL with a no-op query string (?v=2) for the test post.
Common deployment failures: incorrect twitter:card value (typos like "summary_large" or "large_summary_image" silently fall through to the summary card), images served from non-https URLs (X requires https), and X's automated moderation flagging the page as low-quality (the card simply does not render with no error). When in doubt, run the URL through the live preview here, post a test, and confirm before launching campaigns.
What this preview and generator gives you
The tool renders the card the way X would draw it in the timeline, so you can see how the image crops, how the title wraps, and how the description trims before you ever post. As you edit the fields, the preview updates live, which matters more for X than for most platforms because X retired its public Card Validator, leaving the draft-tweet trick as the only other way to see a card before sending. Having a live preview means you are not burning test posts or risking a malformed card in front of your audience.
Alongside the preview, the generator outputs the exact twitter:* meta tags to paste into your page head, including the card type, the image, and the site and creator handles. Because X falls back to Open Graph for the shared fields, the generator focuses on the tags that genuinely differ for X, so you are not duplicating your og:* set unnecessarily. Copy the block, drop it in the head, and the only thing left to handle is X's caching and moderation, which live outside your markup.
Choosing between summary and summary_large_image
The single biggest visual decision is the card type, and the preview makes the trade-off obvious. summary_large_image gives you a full-width banner that dominates the timeline and is the right default for articles, landing pages, and anything with a strong visual. summary keeps a small square thumbnail beside the text, which suits a podcast episode, a profile, or a page whose only image is a logo that would look stretched and awkward at full width. Preview both with your real image and pick the one that actually looks good rather than defaulting blindly to the larger card.
A frequent mistake is choosing summary_large_image while pointing twitter:image at a tall or square asset. X crops it to the wide ratio, which can cut off faces, product edges, or text. If your only available image is square or portrait, either crop a dedicated wide version for the card or switch to the summary type so the image is shown in a shape that fits it. The preview shows you the crop before X does, which is the whole point of checking first.
How cards behave under the current X link policy
X has steadily changed how it treats links in the timeline, and in recent years it has at times shown cards with the headline text hidden, leaving just the image, or reduced the prominence of link posts in the feed. The exact behavior shifts, but the stable advice is unchanged: a strong image carries the card even when the text treatment is minimized, so the image is the field worth getting right above all others. A card that relies on its title to make sense will underperform whenever X chooses to deemphasize that title.
Because the platform's rendering can change without notice, treat the live preview and a real test post as the source of truth rather than any fixed assumption about how cards look. If a campaign depends on the card, post the URL to a throwaway or private account first, confirm the current render, and only then push it to your main audience. The markup being valid is necessary but not sufficient; the live behavior is what your followers actually see.
Cards, AI, and link previews beyond X in 2026
The twitter:* tags were built for one platform, but they overlap heavily with Open Graph, and that overlap is what makes them worth keeping clean in 2026. Tools that unfurl links, including some AI assistants and chat surfaces, read whichever of the Open Graph and Twitter tags they find, so a complete, accurate set raises the odds your link looks intentional wherever it is pasted. Since X already falls back to og:* for the shared fields, the smartest setup is one solid Open Graph block plus a thin layer of twitter:* tags for card type and attribution, which serves both X and the wider ecosystem at once.
Practically, that means you rarely maintain two fully separate tag sets. You write strong og:title, og:description, and og:image once, then add twitter:card, twitter:site, and twitter:creator on top, and only override twitter:title or twitter:image when you deliberately want a different message on X. Use this preview to confirm the X-specific result, use an Open Graph preview to confirm the rest, and you have covered the full range of places a modern link gets rendered without duplicating effort.