Open Graph Checker
Open Graph tags are the meta tags that decide how a page looks when its link is pasted into Facebook, X, LinkedIn, Slack or a chat app. Enter a URL and this checker fetches the page once, shows exactly which tags and fallbacks each platform will use, renders the four share cards, and checks the share image's real dimensions. The companion guide, check your share cards before you post, walks through fixing what you find; for the broader routine checkup, run the Website Health Check instead.
Last updated:
Want this watched continuously? Monitor this free with myeventwatch — expiry and downtime alerts, no card required.
How the check works
The checker makes one guarded server fetch of the URL you enter, follows redirects, and reads the final page's static HTML — the same HTML a platform scraper sees. It parses the og: and twitter: meta tags, the page <title> and the meta description, then works out, platform by platform, which value each share card will actually show and where that value came from. Values supplied by a fallback are labelled as fallbacks, so a card that looks complete does not hide a missing tag underneath it.
One limit shapes everything else: this is a plain HTTP fetch, not a browser, and platform scrapers are not browsers either — neither runs JavaScript. Tags injected by a script, rendered client-side, or added only after login are invisible here and invisible to Facebook, X, LinkedIn and Slack in exactly the same way. If a tag only exists in your JavaScript bundle, it does not exist for sharing. What you see in the result — final URL, HTTP status, the raw tag table and the four rendered cards — is the static truth the scrapers have to work with.
Fallbacks, the relative-image trap and scraper caches
Each platform falls back differently, which is why one page can look right in one app and broken in another. Facebook reads the og: tags directly. X reads its own twitter: tags first and falls back to the matching og: tags when they are absent. LinkedIn reads the og: tags only, so a perfect Twitter Card setup does nothing for it. Slack reads the og: tags first and then the twitter: tags. The checklist below marks every missing field, every empty field, and every field a platform would fill from a fallback, naming the source it would fall back to.
The most common silent failure is a relative og:image: a value like /images/share.jpg looks fine in your template and in your browser, but most scrapers cannot resolve it against anything, so the card simply shows no image. The fix is always an absolute URL, including the scheme. The second trap is caching: every platform caches what its scraper fetched, so fixing the tags does not update posts that are already out there, and even a fresh preview can keep serving the old card until you ask the platform to re-scrape the URL. Fix the tags first, verify them here, then re-scrape — in that order, or you will cache the broken version again.
Honesty limits: a preview here is a simulation of each platform's documented behaviour, not a screenshot of a live post. Platforms crop, round and truncate differently, change their card layouts without notice, and may treat logged-in and logged-out viewers differently, so treat the cards as a faithful model, not a guarantee. One thing is not simulated: the share image's dimensions are read from the actual image file's headers, not from the og:image:width and og:image:height values the page declares — declared values are claims, and this checker verifies them against the file itself.
What gets checked, and the rules behind it
| Tags checked | og:title, og:description, og:image, og:url, og:type and og:site_name, plus twitter:card, twitter:title, twitter:description and twitter:image — and, as fallback sources, the page <title> and meta description. |
| Recommended image size — 1200 × 630 px | 1200 × 630 is platform guidance, not a formal standard: it is the size Facebook recommends and the large-card size X, LinkedIn and Slack handle best. Smaller images still display, but cards may crop them or fall back to a small thumbnail. |
| Reads the og: tags directly — og:title, og:description and og:image — and falls back to the page <title> and meta description only when the og: tags are absent. | |
| X (Twitter) | Reads twitter:title, twitter:description and twitter:image first; each one falls back to the matching og: tag when absent. twitter:card chooses the card layout, and without it X guesses from what it finds. |
| LinkedIn and Slack | LinkedIn reads the og: tags only — twitter: tags do not help there. Slack reads the og: tags first and then the twitter: tags, so it is the most forgiving of the four. |
| Relative image URLs | og:image and twitter:image must be absolute URLs, scheme included. Most scrapers cannot resolve a relative path, and the result is a card with no image and no error anywhere. |
| Image dimensions | Read from the actual image file — its PNG, JPEG, GIF or WebP headers — together with its byte size and format. The declared og:image:width and og:image:height are shown for comparison but never trusted on their own. |
| Dimensions unknown | Means the checker could not fetch or parse the image file — it timed out, refused the request, or is not in a format whose header it can read. The page's declared dimensions, if any, are then all anyone has, scrapers included. |
Frequently asked questions
Why does my shared link show no image?
The usual causes, in order: there is no og:image at all; the og:image is a relative URL that scrapers cannot resolve; the image is too small or in a place the scraper cannot fetch (behind a login, blocked by robots rules, or answering with an error); or the platform is still showing its cached scrape from before the image existed. Run the check above — it names which of these applies — fix the tag, then ask the platform to re-scrape.
Open Graph vs Twitter tags — do I need both?
In practice, yes. Facebook and LinkedIn read only the og: tags, while X prefers its own twitter: tags and uses the og: tags as a fallback. A complete og: set plus a twitter:card tag covers most cases, but an explicit twitter:title, twitter:description and twitter:image is the only way to make the X card differ from the Facebook card — and Slack reads both sets, og: first.
Why does the live post look different from this preview?
Almost always, caching. Each platform's scraper caches what it fetched for a URL, and editing your tags does not invalidate that cache. A post made before the fix keeps the old card, and even the platform's own debugger can keep showing the cached version until a re-scrape is forced. Less often, the difference is cropping: platforms crop and truncate to their current layout, and this preview is a simulation of documented behaviour, not a screenshot.
Does this checker run JavaScript?
No — and that is deliberate. The checker fetches the static HTML once, exactly as a platform scraper does, and scrapers do not run JavaScript either. A tag added by a script or a client-side framework is therefore missing here for the same reason it would be missing on Facebook, X, LinkedIn and Slack. If your tags are rendered by JavaScript, they need to be in the server-rendered HTML to count for sharing.
What size should og:image be?
Use 1200 × 630 px where you can. That is platform guidance rather than a formal standard — it is what Facebook recommends and the size the large cards on X, LinkedIn and Slack are built around. Keep the file reasonably small, use PNG or JPEG (WebP support varies by scraper), and always reference it with an absolute URL. This checker flags images below 1200 × 630 and tells you the real dimensions it measured from the file.