Twitter Card Tag Generator – The twitter: Meta Block Explained
A Twitter Card is what X renders when someone pastes your link: a title, a summary, usually a picture, sometimes a player or an app button. It is driven by a handful of <meta> tags in your page's <head>, each carrying a name that starts with twitter: and a content value. This generator builds that block for the card type you choose, shows what each type needs, and flags what is missing, malformed or simply not used.
The card type decides everything else
twitter:card is the primary control, and the rest of the block reacts to it. A summary card sets a small square thumbnail beside the text. A summary_large_image card puts a wide banner above it, which is why the image matters much more there. A player card embeds a video or audio player from an https iframe and needs the player's address and its box. An app card links straight into a store listing and takes its title from the store rather than from your page.
That is the whole reason the requirement matrix sits under the selector. Picking a card type and then writing the tags from memory is how pages end up declaring summary_large_image with no image, or a player with no dimensions. The matrix and the validation panel here are generated from one rule table, so they cannot disagree with each other.
Handles, IDs and the two store identifiers
twitter:site is the account the site belongs to; twitter:creator is the person who wrote the page. Both take an @handle, and both have a numeric :id companion that keeps working after a rename. This tool accepts a handle with or without the @ and writes exactly one, because a bare username in twitter:site is one of the most common mistakes in a hand-written block.
App cards carry a sharper trap. The App Store identifies an app by a number, so twitter:app:id:iphone and twitter:app:id:ipad are digits only. Google Play identifies it by a package name such as com.example.app. They are not interchangeable, and each field here rejects the other's format on the spot.
Two outputs, two different escaping rules
The HTML block escapes every value for an attribute: & first, then <, > and the quotes, so a quotation mark in your title cannot close the content attribute early. The Next.js metadata export is a JavaScript literal instead, quoted with JSON.stringify — writing & into a JS string would be a bug, not a safety measure. One rule applies to both: control characters are stripped and line breaks are folded to a single space, since a raw newline is malformed inside an attribute and a syntax error inside a string literal.
Why URLs are checked before they become tags
Every address you type is untrusted text. twitter:image is accepted only as an absolute http or https URL; twitter:player and twitter:player:stream are https only, and an http player is rejected rather than warned about. App deep links may use a custom scheme like myapp://, but never a scripting one. Anything refused is reported on the field and left out of the output instead of emitted, and no URL anywhere in this tool is rendered as a clickable link.
player URL is drawn as a placeholder rather than loaded into an iframe.Keep your Open Graph tags
X's documentation describes falling back to Open Graph for properties where the twitter: equivalent is missing, and every other unfurler — chat apps, forums, messengers — reads only Open Graph. So the two blocks are complementary: write Open Graph for everyone, and twitter: tags where you want control over the card style on X. This tool deliberately emits no og: tag at all; paste your existing markup above and it will tell you which properties would fall back and which would not.
photo card and a gallery card both existed once and were retired. Treat the matrix as a summary of the documentation at the time of writing, and check X's developer documentation before relying on it. Note too that unfurlers cache what they scraped: a corrected tag will not change a post that has already been published, and no generator can clear anyone's cache.