OG Image Checker

What decides the card a shared link makes, and why it goes wrong.

A link card is assembled by a crawler you never see, from a handful of meta tags, and then cached. Here is which tags matter, what size the image should be on each platform, and why an old card can outlive a correction.

Open Graph and Twitter Card tags

When someone pastes a URL into a LinkedIn post, a Facebook update, an X post or a Slack message, the platform sends a crawler to fetch that page and reads a few <meta> tags from its head. The dominant vocabulary is the Open Graph protocol, published at ogp.me. It names four required properties for every page: og:title, og:type, og:image and og:url. og:description is optional in the protocol and present on almost every card anyway, because it is the line of text under the title.

<!-- the card, as Open Graph describes it -->
<meta property="og:title" content="Roth IRA conversions, explained">
<meta property="og:description" content="A plain guide to the five-year rule">
<meta property="og:image" content="https://example.com/og/roth.png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Chart of a conversion ladder">
<meta property="og:url" content="https://example.com/roth-ira/">
<meta property="og:type" content="article">

<!-- X's own layer; each falls back to og:* when absent, except the card type -->
<meta name="twitter:card" content="summary_large_image">

X keeps its own vocabulary, the Twitter Card tags. Its developer documentation (archived January 2026; the live page no longer loads) says the card processor checks for the Twitter tag first and falls back to the matching Open Graph property: twitter:title to og:title, twitter:description to og:description, twitter:image to og:image. The card type is the exception. For a missing twitter:card the same table says that if og:type, og:title and og:description exist, "a summary card may be rendered". A summary card is the small one, with a square thumbnail beside the text. The wide image only comes with summary_large_image. So a page with complete Open Graph tags and no Twitter tags at all can look right on LinkedIn and small on X. Our open graph checker is the page for the full tag audit; this one is about what the card looks like.

OG image size, platform by platform

The number everyone quotes is 1200 by 630 pixels, a ratio of 1.91 to 1. It comes from Meta, and the platforms do not agree beyond it. These are the figures each one publishes, taken from their own documentation, not from a roundup:

One image can serve all of them if it is built for the tightest case. A 1200 × 630 image meets Facebook's recommendation and sits three pixels above LinkedIn's minimum height; X's large card documents 2 : 1, so a 1.91 : 1 image is not an exact fit there, and how X fits it is X's decision. Keep the text and any face inside the middle of the frame, so a trim at the edges leaves them alone. For the square summary card on X, a wide image loses its sides entirely, which is one more reason to set twitter:card to summary_large_image when the image is the point.

Declaring the size helps too. Meta lists og:image:width and og:image:height as a way to let its crawler render the image immediately on the first share, instead of after it has downloaded and measured it. Open Graph also defines og:image:alt, a description of what the image shows, and asks that a page with an og:image carry one.

Open graph preview: where the platforms differ

A social share preview is not one card drawn four times. X reads its own tags first, so a page can hand X a different title and image from the one LinkedIn shows, deliberately or by accident: a theme writes twitter:title from one field and an SEO plugin writes og:title from another, and they drift. This checker compares them and says so when they differ. LinkedIn says it relies on oEmbed and Open Graph to pull the title, description and image. Slack names oEmbed, Twitter Card and Open Graph tags together and fetches as little of the page as it can with HTTP range requests, which is one more reason to keep the card tags near the top of the head. None of the three platforms that publish guidance say they run a page's JavaScript to find its tags, so a tag inserted by a script after load is safest treated as absent. This tool reads the served HTML for the same reason.

X also gives a piece of advice worth taking in any regulated business: the large-card image should be "a unique image representing the content of the page", not a site logo or an author photo used everywhere. A logo as the card image tells a reader nothing about the article, and it is easy to ship by accident when a theme sets one site-wide default.

Common failures

• No og:image at all. The card has no image you chose. What fills the space, a text-only card or a picture pulled from the page, is the platform's decision. This is the failure the checker's red row names first.
• A relative image URL. /images/card.png means nothing to a crawler reading the tag out of context. The value has to be a full address beginning with https://.
• No twitter:card. Everything else is right and X draws the small square card. One line fixes it.
• An image over the limit. LinkedIn and X both stop at 5 MB. A 4000-pixel PNG exported straight from a design tool can pass that without anyone noticing. This tool cannot weigh the file; check it where you host it.
• A crawler that cannot reach the image or the page. X's troubleshooting guide names a robots.txt that blocks its crawler, and server rules that deny its addresses, as reasons a card does not appear. A firewall or bot wall that lets browsers through can still turn a crawler away.
• An SVG card image. X does not support SVG for cards. Export a PNG or JPG.
• Two sets of tags. A theme and a plugin both write Open Graph tags. The platforms do not document which one they keep. This checker keeps the first and shows its value, so a stale set sitting above the current one is visible.

Why an old image or title lingers

Every platform caches the card, and each documents it differently. LinkedIn's help centre says to allow 48 hours after a metadata change, and offers its Post Inspector to fetch the URL again, with a limit worth reading twice: the refresh "will only affect the URL's preview image and information for new posts". A post already published keeps its old card. Meta's Sharing Debugger re-scrapes a URL on request, and Meta advises using a new URL for a replacement image, because an image changed at the same address may not be picked up. X's guide says its crawler re-reads a page roughly every seven days. Slack caches unfurls across its service for around 30 minutes.

For a firm where a shared post counts as a public communication, that cache is the part to plan around. If a card went out with a figure or a claim that later had to be corrected, fixing the page fixes the next share, not the posts already live. The practical order is to get the card right before the first share, which is what the paste mode on this page is for: paste the head tags of a draft, see the card as a reader will, and have whoever reviews the page review the card at the same time. Other tools let you edit tags after fetching a live page; the point here is to start from a page that does not exist yet.

What a good card needs

An og:image with an absolute URL, made for this page, 1200 × 630 or larger, under 5 MB, with the important content in the centre. An og:title and an og:description written for someone scrolling past, not copied from the meta description by default. og:image:width, og:image:height and og:image:alt. A twitter:card of summary_large_image, and Twitter tags only where you want X to show something different. Then check the card before the page goes out, and again after any template change, because card tags are exactly the kind of thing a theme update rewrites.