OG Preview
OG Preview reads your Open Graph and Twitter card tags and shows the link card a crawler will actually render, including the fallbacks — a missing og:title means the card shows your <title>, which usually puts the site name first. It also reports the silent failures: a relative image URL is simply never fetched.
acme.example
Pricing
Three plans, no seat minimums, and a free tier you can keep.
acme.example
Pricing
Three plans, no seat minimums, and a free tier you can keep.
What is wrong with these tags?
How does OG Preview work?
A link card is rendered by somebody else’s crawler from tags on your page, and every way it can go wrong is silent. Nothing throws, nothing logs, and the page looks fine in a browser — the card is just slightly wrong, and the click-through rate is slightly lower, forever.
The fallback chain is what actually renders
Platforms do not require og:title. If it is absent they use <title>, which on most sites is the page name with the site name in front of it — so the card reads “Acme Analytics — Pricing” where it should read “Pricing”. The preview above resolves the chain rather than showing only what is present, and names which source each field came from, because “missing” and “present but wrong” need different fixes.
The failure that looks like success
<meta property="og:image" content="/og/pricing.png"> is valid HTML and completely broken. Crawlers do not resolve relative paths against the page, so the image is never fetched and the card shows a grey box. It is the commonest cause of a card that works in a local preview and shows nothing in production, and it is why a relative image URL is reported as critical rather than as a style note.
Why this parses rather than pattern-matches
The obvious implementation is a regular expression per tag, and it breaks on the first real page: content="a > b" has a > inside a quoted attribute, content='It's here' has an apostrophe that ends a naive scan, and <meta> may be self-closed, unclosed, or have its attributes in any order. So the document is walked once by a scanner that knows about quoting and about raw-text elements, which is the same approach the JSON and XML tools here take.
What this cannot do is fetch your image, because that would mean a network request from a page that promises none. So it checks what is checkable without one — the URL is absolute, the declared dimensions are large enough, the aspect ratio is close to the 1.91:1 every platform crops to, and the alt text exists.
Head markup
<meta property="og:title" content="Pricing" /> <meta property="og:image" content="/static/og/pricing.png" /> <meta name="twitter:card" content="summary" />
Findings
critical og:image "/static/og/pricing.png" is not an absolute URL.
Crawlers do not resolve relative paths.
warning og:description Missing. The card falls back to <meta description>.
warning og:image:alt Missing. Screen readers announce nothing.
info twitter:card "summary" renders a small square thumbnail.What is wrong with these Open Graph tags?
A plausible set of tags with three real defects. The image path is relative, which no crawler resolves; there is no og:description, so the card falls back to the meta description written for search; and there is no alt text.
Head markup
<meta property="og:title" content="Pricing" /> <meta property="og:image" content="/static/og/pricing.png" /> <meta name="twitter:card" content="summary" /> <title>Acme Analytics — Pricing</title> <meta name="description" content="Pricing for Acme Analytics." /> <link rel="canonical" href="https://acme.example/pricing" />
Findings
critical og:image "/static/og/pricing.png" is not an absolute URL. warning og:description Missing. warning og:url Missing. warning og:image:alt Missing. info og:type Missing, so it defaults to "website". info og:site_name Missing.
og:title is present and the <title> is not used — which is the good outcome. Had og:title been absent the card would have read "Acme Analytics — Pricing", with the site name in front of the page name.
What options and edge cases does OG Preview support?
| Parameter | Type | Default | Behaviour & edge cases |
|---|---|---|---|
| og:title | required | falls back to <title> | The card headline. Without it the card uses your <title>, which usually has the site name in front — the card then reads as the homepage rather than the page. |
| og:description | required | falls back to meta description | The two lines under the headline. A meta description is written for a search result; card copy is written for someone deciding whether to click, and they are rarely the same sentence. |
| og:image | required | none | Must be an absolute https URL — crawlers do not resolve relative paths. 1200×630 is the size every platform crops from; below 600×315 the card is scaled up and looks soft. |
| og:image:alt | recommended | none | Read aloud by a screen reader and shown when the image fails to load. Supported by every major platform and almost always omitted. |
| og:image:width / height | recommended | discovered | Declaring them lets the crawler lay the card out before downloading the image. Without them the first fetch of a page is a second request for the picture. |
| og:url | recommended | the fetched URL | The canonical address of the page. Without it, a page reachable at two URLs splits its share counts between them. |
| og:type | recommended | website | "article" unlocks author and publication-time fields and changes how some clients present the card. |
| og:site_name | optional | hostname | Shown above the title by LinkedIn and several chat clients. Without it they print the hostname. |
| twitter:card | recommended | summary | summary_large_image shows the picture at full width; summary shows a small square thumbnail. An unrecognised value is treated as summary. |
| canonical | recommended | none | A <link rel="canonical"> is not an OG tag and matters just as much: it is what stops the same page at two addresses from competing with itself. |
Frequently asked questions
Why is my image not showing in the preview?
Almost always a relative URL. og:image must be absolute — https://acme.example/og/pricing.png, not /og/pricing.png — because the crawler fetches it out of context and has no page to resolve against. It is reported here as critical for that reason. The second most common cause is an image behind a login, and the third is a CDN that blocks the platform's user agent.
I updated the tags but the card did not change. Why?
Crawlers cache. Facebook and LinkedIn keep a card for days, and X caches for about a week. Facebook's Sharing Debugger has a Scrape Again button that clears it; LinkedIn's Post Inspector does the same. Until you do that you are looking at the old tags, which is why a change that worked can appear not to have.
What size should the image be?
1200×630 pixels. That is exactly 1.91:1, the ratio every platform crops to, so nothing is trimmed. Anything below 600×315 is upscaled and looks soft; anything much wider loses its edges. JPEG for photographs, PNG for flat artwork and text, and keep it under about 1 MB — some clients skip larger images rather than waiting.
Do I need Twitter tags if I have Open Graph?
X falls back to Open Graph for title, description and image, so og:* alone will produce a card. What it will not do is pick the right card type: without twitter:card you get the small square summary rather than the large image. One extra tag is worth it, and twitter:title is worth having when the card copy should differ from the link preview elsewhere.
Does this fetch my page or my image?
No. You paste the markup and it is parsed in the tab — the Network panel shows nothing. That is a deliberate constraint rather than a limitation: a tool that fetched your image could measure it, and would also be a server that knows every URL you paste. The checks here are the ones that need no request: absolute URLs, declared dimensions, aspect ratio and alt text.
Which platforms read which tags?
Open Graph is read by Facebook, LinkedIn, Slack, WhatsApp, Discord, Telegram, Pinterest and — as a fallback — X. X's own twitter:* tags win there when present. Some clients add their own expectations on top: Slack wants a square-ish image for its unfurl, and Discord shows a small thumbnail for summary cards and a full-width banner for summary_large_image.