Write the tags for a page head
Fill in four fields and read back the tags, the search result they produce, and how much of each line survives before the cut.
How it works
A page head carries the same handful of facts several times over, in three vocabularies that do not agree with each other. The title element and the meta description feed a search result. The og properties feed Facebook, LinkedIn, Slack and most chat clients. The twitter names feed one more parser, which reads the og ones as a fallback but not always the ones you expect. Writing all of it by hand means keeping four values consistent across sixteen lines, and the usual failure is a stale copy of the title in one of them.
The cut happens at a width, not at a character count
Every article about title length quotes a number of characters, and every one of those numbers is a translation of something else. A search result is laid out in a proportional font, so the room a line occupies depends on which letters are in it. A lowercase i is about a quarter the width of a capital W at the same size. A heading of sixty narrow letters can sit inside the space that fifty wide ones overflow, and a character counter calls the first one too long and the second one fine.
So this page measures instead. The title and the description are drawn into an off-screen text context in a named font at a named size, and the advance width comes back in pixels. The figure beside each field is that width against its budget, and the preview above is cut at the glyph where the budget runs out. A character count is shown as well, because it is the figure other tools report and comparing the two is instructive, but here it is the second number rather than the first.
Where the budgets come from, and what they are not
Google has never published a pixel figure, and any page presenting one as a specification is presenting a measurement as a rule. The four numbers used here come from the pixel checkers that measured real results and converged: about 580 pixels of title and 920 of description in a desktop result, about 496 and 680 on a phone. They are approximations of a moving target, they were measured in Arial, and Google renders results in a different family whose metrics differ from Arial by a small amount.
Two consequences worth holding onto. A line just under its budget is not safe, because the budget has error bars of its own, so the useful reading is how much room is left rather than a pass or a fail. And a line well over the budget is not wasted: the words past the cut are still indexed even though nobody sees them in the result. Put what a person needs to see at the front, and let the tail work for the index.
The measurement describes the text, not the markup
An ampersand inside a title attribute has to be written as five characters, and a double quote as six, or the attribute ends early and the rest of the line leaks into the page as broken markup. That escaping is done for you here. It is also excluded from every count on this page: a reader sees one ampersand, a search result draws one ampersand, and counting the entity would overstate the length of any title containing one. The tags carry the escaped form and the measurements describe the visible form.
The description box accepts line breaks, because people paste out of a document, and the generated tag collapses runs of whitespace into single spaces. A newline inside an attribute value is legal and renders as a space, so this changes nothing about the output, but it does change the character count. The figure reported is for the collapsed text, which is what actually ships.
A blank social card is nearly always a relative image
The commonest reason a shared link renders as a grey box is an og image whose value starts with a slash. A browser resolves that against the page it came from. A scraper is a separate program fetching a URL it was handed, and most will not resolve it, so the property is read, found unusable, and dropped. The value has to begin with https and name the host every time, even on a site where every other link is root-relative.
Size matters after that. A large-image card is cropped to about 1.9 to 1, which is where 1200 by 630 comes from: it fits that shape and leaves enough resolution for a dense screen. The 1.91 everybody quotes is the same recommendation one revision earlier, when the height was 628. Declaring the dimensions lets the first scrape lay the card out before the file arrives, and declaring dimensions the file does not have gives a card that jumps or crops wrongly.
A canonical is a claim, and it should point at itself
A canonical link names the address you want indexed for this content. On a normal page that address is the page itself, which sounds circular and is the entire point: it settles the question when the same content is reachable with a tracking parameter appended, with and without a trailing slash, or over both http and https. A self-referential canonical is correct for the overwhelming majority of pages, and leaving the override blank here produces one.
Pointing it elsewhere is a deliberate act with a real cost. It asks search engines to drop this address and credit another, and it is honest only when the other address genuinely carries the same content. The check below compares the canonical against the page URL and names the difference it finds, because a canonical that lost its trailing slash and one that points at a different article are the same string mismatch and two unrelated mistakes.
The social title is allowed to disagree with the title element
Those two are written for different readers, and copying one into the other is a missed opportunity rather than a bug. A title element competes in a list of ten results against a query somebody typed, so it wants the searched words near the front and the brand at the end. A social title appears alone in a feed or a chat window, with no query behind it and no competitors beside it, so it can be shorter and plainer, without the keyword scaffolding that earns a click in a search result.
The same split applies to the image, and to the descriptions: nothing in a social card is read by a search engine, and nothing in a search result is read by a card scraper. Leave the override blank and the title is reused, which is the sensible default. Fill it in when the two audiences want different sentences.
Questions
Why does the pixel width here differ from another tool?
Because the two measured in different fonts. A width means nothing without the family and the size it was taken in, and most tools report a number without stating either. This page measures titles at 20px Arial and descriptions at 14px Arial, which is what the published pixel budgets were measured in. Google renders results in a different family, so treat every figure here as a close approximation rather than a threshold.
Is a title over the budget penalised?
No. The words past the cut are still indexed and still count towards what the page is about. What you lose is the part a person reads before deciding to click, so the cost lands on the click-through rate rather than on the ranking. The practical advice is to put the distinguishing words first and treat the tail as material for the index rather than for the reader.
Do I need the twitter tags as well as the og ones?
Mostly not. That parser falls back to og:title, og:description and og:image where the twitter equivalents are missing, so the only line that earns its place unconditionally is twitter:card, which selects the layout and has no Open Graph counterpart. The rest are emitted here because the fallback is a documented courtesy rather than a guarantee, and because an explicit tag is what you edit when the two audiences want different words.
My card still shows the old image after I changed it.
Scrapers cache aggressively, and the cache is keyed on the page address rather than on the image. Facebook's Sharing Debugger and LinkedIn's Post Inspector both offer a re-scrape button that clears their copy. Slack and iMessage hold theirs for hours with no way to flush them. Giving the new image a new filename, rather than replacing the file at the same address, sidesteps every one of those caches at once.
Why is there no og:image:alt?
Because this page has never seen your image and cannot describe it. Alt text is worth adding by hand: screen readers announce it when a card is read aloud, and the description belongs to the picture rather than to the article. Most generators fill it with a copy of the title, which is how a card ends up announcing its own headline twice and telling a listener nothing about the image.
Should I state index and follow in a robots tag?
It changes nothing, because that is the behaviour with no tag at all. Some teams state it anyway so a later switch to noindex is a visible edit rather than a new line, and that is a reasonable habit. The directive worth adding for its own sake is max-image-preview:large, which permits a full-width thumbnail beside the result and is not the default everywhere.
Where in the document do these go?
Inside the head element, in any order. Nothing here depends on position, with one exception worth knowing: a charset declaration has to appear within the first 1024 bytes of the document, so it belongs above this block rather than below it. If your framework already emits a title or a canonical, delete the duplicate here rather than shipping both, because a second one is ignored by some parsers and preferred by others.