Twitter Card Validator (X Card Checker)

What a Twitter card is, and why X can show one you did not write.

Paste a link into a post on X and a box appears under it with a picture, a headline and a line of text. That box is built from a handful of meta tags in your page's head, or, when those are missing, from tags you wrote for someone else. Here is how X decides what goes in it.

What a Twitter card is

A Twitter card, still called that in X's own documentation, is the link preview X attaches to a post that contains a URL. When the link is first shared, X's crawler, which identifies itself as Twitterbot, fetches the page and reads the meta tags in its <head>. Those tags name the layout, the headline, the summary and the image. If they are right, the post carries a clickable card; if they are wrong or absent, it carries whatever X could assemble, which may be a bare link.

The tags are ordinary meta elements with a twitter: prefix, written with a name attribute:

<!-- inside <head> -->
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:site" content="@yourfirm">
<meta name="twitter:title" content="Estate Planning, Explained">
<meta name="twitter:description" content="What a will covers, and what it does not.">
<meta name="twitter:image" content="https://yourfirm.com/img/estate.jpg">

What happened to the official Twitter Card Validator

For years the standard way to check those tags was Twitter's Card Validator, which drew the card for any URL. In August 2022 Twitter posted a notice on its developer forum saying it had removed the preview from the Card Validator, because the previews were not always aligned with how cards actually displayed across platforms. The notice pointed people to the post composer instead: start a new post, paste the link, and the card renders without posting. At the time, the validator page stayed up for submitting new domains and reading its logs. Reports differ on what that page does today, so we will not describe it; the advice in X's notice is the composer.

That leaves two separate questions, and this page answers the first. Are the tags on the page correct and complete? That is a question about your HTML, and a tag check answers it the same way every time. What does the card look like right now? That depends on X's current layout and its cache, and only the composer shows it exactly. For an approximation of the card itself, the OG Image Checker draws it.

The tags, and what each one falls back to

X's markup reference lists every card tag with the Open Graph property it falls back to. The rule, in X's words, is that the card processor "first checks for the Twitter-specific property, and if not present, falls back to the supported Open Graph property." So a page with good og:* tags does not need to repeat them. These are the six tags this checker reads:

Two details in that table do most of the damage. The card type has only a conditional fallback: X says a summary card "may be rendered" when og:type, og:title and og:description exist, which means a page with no twitter:card gets the small layout at best, however good its image is. And the attribution handles have no fallback at all, so a firm that wants its account named on every share has to write them out. X's pages disagree with each other on twitter:site: the card pages call it optional, the markup reference says it is required. This checker marks a missing handle for review rather than as a fail.

summary versus summary_large_image

Almost every article page wants one of two layouts. summary puts a small square thumbnail beside the title; X crops the image to a square on every platform, and its docs give a 1:1 aspect ratio with a 144 by 144 pixel minimum. summary_large_image puts a wide image above the title; the docs give a 2:1 aspect ratio, a 300 by 157 pixel minimum and a 4096 by 4096 maximum. Both layouts take the same title, description and image tags. The choice is the one line only you can make, which is why it is the one line with no dependable fallback.

Pick the large layout when the page has an image made for it, and the small one when all you have is a logo. X's own guidance is blunt on this point: use a unique image representing the page, not a generic one such as a site logo or an author photo that appears on every page.

Why a fix does not show up straight away

X caches card data. Its getting-started guide says content is cached for 7 days after a link with card markup is first posted, and the 2022 notice repeats that card data is cached for up to 7 days before it is refreshed. The notice also mentions adding a unique parameter to the URL as a hint to the crawler to revisit, with a delay before new tags appear on X. So if you correct a headline in your tags, the old card can keep appearing on shares of that URL for up to a week.

For most sites that is a nuisance. For a regulated firm it is a different kind of problem. The card is a headline and a summary on a public feed, attached to your name, and anyone can repost it. If the title that went out overstated a return, a result or a credential, correcting the page does not immediately correct the card. The practical answer is to treat card text as marketing copy that gets reviewed before the first share, the same as the page it points to, rather than something to fix afterwards. This checker shows you exactly which text X will use, including text borrowed from your Open Graph tags, so it can be read before it goes out.

What X needs to fetch the image

A card image fails more often than a card title, and usually for reasons that have nothing to do with the tag. The URL should be absolute, with the scheme and host written out; a relative path such as /img/card.jpg gives the crawler nothing to resolve against. The image has to be publicly reachable: behind a login, a hotlink block or a firewall rule, it will not load. And X's crawler respects robots.txt. The getting-started guide says that if a page with card markup is blocked, no card is shown, and if the image URL is blocked, no image is shown. A site that disallows everything except named search crawlers can switch its own cards off without meaning to; the Robots.txt Checker reads that file.

Common mistakes

• No twitter:card at all. The Open Graph tags are perfect, the image is made for a wide card, and the post shows a small thumbnail or nothing, because the layout was never chosen.
• property= instead of name=. X's parser reads Open Graph tags written with property, and its docs write twitter tags with name. Verand's site audit looks for name="twitter:card", and this checker tells you when it found the tag the other way.
• Two twitter:card tags. A theme sets one and an SEO plugin sets another. X documents that the last one on the page wins; most checkers, this one included, report the first. If they differ, delete one.
• A title written for Google, not for a card. A 70 character maximum is tight. A title tag with the site name appended can run past it: one of the Willowdale Equity articles we checked carries a 71 character title in both tag sets.
• An SVG logo as the image. Unsupported. So is an image over 5MB.
• A twitter:title that disagrees with og:title. Not an error, but it means X shows one headline and LinkedIn or Facebook another. Make the difference deliberate.
• Checking the card and not the page. The composer shows what X displays today, from its cache. The tags show what it will display after the cache refreshes. Check both after a change.

What a good set looks like

For an article: a twitter:card of summary_large_image, a twitter:site handle for the firm and a twitter:creator handle for the author, and complete Open Graph tags carrying the title, description and a unique absolute image URL that X can read by fallback. Add twitter:title or twitter:description only when you want X to say something different from every other platform. Then check the page with this tool, paste the link into the composer, and do it before the first share rather than after.