OG Card
Preview.
An OG card is the title, description and image a site shows when a link is shared. This tool fetches a URL, reads its Open Graph and Twitter Card tags, and shows what each platform would display — including which tag supplied each value, and which required tags are missing or malformed.
Corrections welcome — see our editorial policy.
We fetch the page from our server and read only its <head>. The card image is never downloaded by us — your browser loads it directly from the source.
Check the headers behind the page.
Grade its security headers →What is an Open Graph card?
When you paste a link into a chat app, a social network or a messaging client, the receiving platform fetches that page and looks for Open Graph tags — <meta property="og:title">, og:description, og:image and friends. Those tags, not the page's visible content, decide what the preview shows. Open Graph came out of Facebook in 2010 and is now the de-facto standard; X (formerly Twitter) layers its own twitter: tags on top, and falls back to the Open Graph ones when they are absent.
The practical consequence is that a page can look perfect in a browser and render as a bare grey link everywhere else. The tags live in the <head>, so nothing about the visible page tells you whether they are right.
Which tag actually wins?
Consumers resolve each field down a fallback chain, and this is where most confusion comes from. For a title, the usual order is og:title, then twitter:title, then the document's <title>. For a description it is og:description, then twitter:description, then the meta name="description". For an image it is og:image, then twitter:image — with no HTML fallback at all, which is why a page with no image tag simply has no thumbnail.
This tool reports the winning value and names the tag it came from. That distinction matters: if your card shows an old headline, knowing the value came from <title> rather than og:title tells you immediately that the OG tag is missing, not stale.
Where a page emits the same tag twice — common when a CMS and an SEO plugin both write one — consumers overwhelmingly take the first occurrence. This tool does the same, so what you see is what they see.
Why cards break
A small number of causes account for most broken previews.
A relative image URL. og:image="/card.png" is invalid — the specification requires an absolute URL, and most consumers drop it rather than guessing the origin. This is the single most common cause of a missing thumbnail on an otherwise well-tagged page.
No image at all. Without og:image or twitter:image, the card collapses to a text link on most platforms, which is a large difference in how much room the link occupies in a feed.
An image the consumer cannot reach. If the image sits behind authentication, a hotlink block, or a firewall that rejects the platform's crawler, the tag is present and the card is still blank. We report the URL; whether a given platform can fetch it is something only that platform can answer.
Tags added after the head. Metadata injected by client-side JavaScript generally does not exist as far as a link crawler is concerned — most do not execute scripts. If your tags are rendered by the framework at runtime, they need to be server-rendered instead.
Caching. Platforms cache scrape results aggressively, often for days. After fixing tags, a card can stay wrong until the cache expires or you use that platform's own re-scrape tool. Nothing you change on your side clears someone else's cache.
A worked example
Suppose a card shows the right image but the wrong headline. Running the URL here shows title resolving to "Home | Example Co" with the source given as <title>. That single word tells you the whole story: no og:title exists, so the consumer fell through to the document title, which is the site-wide one rather than the article's. Adding og:title fixes it — and until the platform re-scrapes, the old card persists regardless.
What this tool does not do
It does not download the card image. We read the page's <head> and report the image URL; your browser then loads that image directly from its origin to draw the preview above. We deliberately do not fetch and re-serve it, because a service that retrieves arbitrary images on request is an open image proxy, which is a considerably larger abuse surface than this tool needs.
It is not a guarantee. Each platform applies its own rules on top of the tags — minimum image dimensions, aspect-ratio cropping, description truncation, and allowlists for embedded players. A card that looks correct here can still be rendered differently by a specific consumer. Treat this as an accurate reading of your tags, not a rendering promise.
It reads a bounded prefix of the page. We stop at </head>, or after 256 KB if the head never closes, and say so when that happens. A page that emits metadata unusually late may be reported as truncated.
It sees what a server sees. Pages that vary their output by cookie, login state or geography may serve us something different from what you see in your browser — the same limitation every link crawler has.
Common questions
Do I need both og: and twitter: tags? Usually not. X falls back to Open Graph for title, description and image, so a complete set of og: tags covers most consumers. The one twitter: tag worth setting explicitly is twitter:card, which selects between a small thumbnail (summary) and a full-width image (summary_large_image).
What image size should I use? 1200×630 is the widely-supported choice and the aspect ratio most platforms crop toward. Declaring og:image:width and og:image:height lets a consumer reserve space before the image arrives.
My card is still wrong after fixing the tags. That is almost always caching on the platform's side. Each major platform publishes a debugging tool that forces a re-scrape; use theirs, because we cannot clear their cache from here.
Why does the preview here differ slightly from the real thing? The layouts above are approximations of common card shapes, drawn from your tags. They show which values a consumer receives, not a pixel-exact reproduction of any one platform's rendering.
If the page you are checking is your own, the security headers grader is a useful next pass — the same request that fetches your metadata also reveals how the page is served.