Paste a link into a chat or a post and something fetches the page, reads a handful of tags from its head, and builds a card. Nothing about that card comes from the visible page — it comes from metadata written for exactly this purpose.
When a preview looks wrong, the page is almost always missing one of five tags, and the platform has fallen back to guessing.
Which tags do the work?
A small set, and the image is the one that matters most.
| Tag | What it sets |
|---|---|
| og:title | the headline on the card |
| og:description | the line underneath |
| og:image | the picture |
| og:url | the canonical address |
| og:type | article, website, video |
The convention came out of one platform in 2010 and spread because everyone needed the same thing. Chat apps, forums and social platforms all read it now, which makes it the closest thing there is to a universal preview standard.
A second, smaller vocabulary exists for one platform in particular, and it falls back to the first when its own tags are absent — so a page with good Open Graph tags gets a reasonable card everywhere without duplicating the work.
Why is the image not showing?
Relative paths, most often. The image URL has to be absolute, because whatever is building the card is fetching it from elsewhere and has no page context to resolve a relative path against.
The second cause is caching. Platforms fetch a preview once and keep it, so correcting a tag does not change a card that has already been built — the fix is to ask the platform to re-fetch, which every major one offers a way to do.
Third is access. An image behind a login, blocked by a robots rule, or served only over an insecure connection may be fetchable by a browser and not by the crawler building the card.
What shape should the image be?
Wide landscape, at roughly 1.91 to 1, which has been the recommendation for over a decade. A 1200 by 630 image is the safe default and is what most tooling assumes.
Square images are used by one card variant and get cropped by the rest, so a square asset is a deliberate choice rather than a safe one. Anything much smaller than about 600 pixels wide may be shown as a thumbnail beside the text instead of above it, which is a visibly weaker card.
Text inside the image needs the same caution as a banner. Cards are cropped at different ratios by different apps, and text near an edge is the part that goes.
How is a search result different?
It is built from the same page and by different rules. A search engine reads the title tag and the meta description, and then feels free to rewrite either one if it judges something on the page a better answer to the query.
The practical limits are about width rather than characters — roughly 60 characters of title and about 155 of description before truncation, varying with the actual letters, since a line of capitals runs wider than a line of lowercase.
The description does not affect ranking and does affect whether anyone clicks, which makes it worth writing and not worth agonising over. Front-loading the useful part protects it from being cut.
What should you check before publishing?
The card, in the places it will be pasted. Rendering the tags into a preview shows the truncation and the crop together, and both are invisible in the markup.
The most common finding is a title that reads well as a page heading and badly as a card, because the site name has been appended and now takes a third of the available width.
For a page that will be shared into several different apps, checking two or three of them covers the variation. They crop differently and truncate at different lengths, and a card that survives the strictest survives all of them.
Does the card need its own image?
Usually, and it is worth the effort. A card image is wide, small on screen, and seen in a list of other cards — which is a different job from a photograph inside an article and rarely done well by the same file.
The version that works is closer to a title card than a picture: a strong background, the headline set large enough to read at card size, and little else. Generating them from a template means every share looks deliberate without a design pass per article.
The alternative — letting the platform choose an image from the page — produces whatever happens to be first, which on many pages is a logo or an author photograph.
Questions people ask
Do I need both vocabularies? Not usually. The fallback handles it unless you want a different card on one platform.
Does the preview affect ranking? No. It affects the click-through rate on a shared link, which is a separate thing.
Can each page have its own image? Yes, and it should. One image across a whole site makes every share look identical.
Why does my card show the wrong old image? It is cached from an earlier fetch. Refresh it through the platform’s own tool.
Write the tags, then look at the card. The Open Graph image size and OG image preview cover the picture, the Twitter card generator and preview handle the second vocabulary, the link preview generator and social share preview render the card, and the SERP preview tool shows the search listing with its truncation.