Free Open Graph Checker
Reads the og and twitter tags, renders the card your link will unfurl into, and fetches the og:image itself, because a broken image is invisible in the markup and obvious to everyone who sees the post.
The five tags that build the card
Open graph is a large vocabulary and almost nobody needs most of it. A link unfurls correctly nearly everywhere with these:
og:title
The card headline. It can differ from your title element and often should: the search result wants keywords first, the share card wants a line someone would read aloud. Falls back to the title element when missing.
og:description
One or two sentences under the headline. Falls back to the meta description, which is usually written for a different audience and reads like it.
og:image
The one that does the work. 1200 by 630, absolute URL, under about 5MB, PNG or JPEG. Keep anything essential away from the edges: feeds crop to their own aspect ratios.
og:url
The canonical address of the content, so shares of a parameterised or tracked variant consolidate onto one URL. Worth keeping in step with your canonical.
twitter:card
summary_large_image, or X may render the small square card and your 1200 by 630 image is wasted. The other twitter tags are optional, since X falls back to the og values.
Why the image is fetched, not just read
Every og checker can tell you an og:image tag exists. That is the easy half, and it is not the half that fails. What fails is the URL inside it: it 404s after an asset rename, it points at a path that only exists in staging, it is relative and therefore unresolvable by a scraper, or it is served from behind a rule that blocks bots. In every one of those cases the markup looks perfect and the card renders with a blank space.
So this tool sends a request to the image URL and reports what came back. It is the same principle the rest of these tools run on: read the thing that decides the outcome, not the thing that describes it. A tag is a claim, and a claim is checkable.
Why a link shows no preview
- A relative og:image. Scrapers do not resolve it against the page the way a browser resolves an img src. This one is reported as broken here rather than as a warning, because the outcome is total.
- The image does not load. Renamed, deleted, or blocked to non-browser requests. Invisible until someone posts the link.
- Tags rendered by JavaScript. Scrapers do not run it. If the tags are injected client side, the card is built from an empty document, which is worth knowing before you debug the tags themselves.
- A stale platform cache. The tags are fixed and the platform is still showing what it fetched last week. Each platform has a debugger that forces a refetch; that is the fix, not another tag change.
- A redirect in the way. Some scrapers follow one hop and stop. If the shared URL redirects more than once before reaching the page with the tags, the card can come back empty.
What this has to do with backlinks
Nothing directly, and it would be easy to pretend otherwise on a site about backlinks. The connection worth making is narrower and true: og tags do not make a page rank, they make a link worth clicking, and the links you do not control are the ones where that matters. A directory listing, a mention in a group chat, a newsletter item. In those moments nobody is there to add a caption, and a bare URL sitting in a feed of cards reads as an accident.
So it belongs in the same set of checks as the rest: a small, fixable, invisible failure that costs something every time it happens and never announces itself.
Honest limits
The preview here is an approximation. Every platform lays its card out differently, truncates at different lengths and crops to its own aspect ratio, so treat this as a sanity check rather than a pixel-accurate rendering. It also cannot see what a platform has cached: if you changed tags recently, the card you get on X or LinkedIn may be older than the one shown here, and only their own debuggers will refresh it. And the image request is a fetch from our servers, so an image blocked by geography or by a rule targeting a specific crawler can behave differently for them than for us.
For the rest of the head, the meta tag checker covers titles, descriptions and robots directives in one read.
You control your own tags. You do not control the pages linking to you.
A share card is fixed once and stays fixed. A backlink on someone else's site is a live thing: it gets pruned in a cleanup, flipped to nofollow in a template rebuild, or stranded on a page that turns noindex. ShipDR reads every listing you track on a schedule and tells you the day one changes.
- Every listing rechecked on a schedule, not once
- Live, dofollow and indexable, read from the page itself
- Told the day a backlink drops or flips
Adding a website and charting its Domain Rating is free, no card. The backlink engine is $10 once, per website, with no subscription.
Fair questions
What are open graph tags?
A small set of meta tags, originally from Facebook, that tell any platform how to render a link to your page: og:title, og:description, og:image, og:url and og:type. They are read by nearly everything that unfurls a link, including X, LinkedIn, Slack, Discord, WhatsApp and iMessage, which is why they matter far beyond the platform that invented them.
Do open graph tags affect SEO?
Not directly. Google does not use og tags as ranking signals, and it prefers the title element and meta description for search results. The indirect effect is real though: a link that unfurls into a clear card gets clicked and reshared more than a bare URL, and shares are how pages reach the people who might link to them. Treat og tags as distribution, not as ranking.
What size should the og:image be?
1200 by 630 pixels is the safe default: it fills the large card on X and Facebook and downscales cleanly everywhere else. Keep it under about 5MB, use PNG or JPEG, and make the URL absolute. Also remember the image is often shown cropped to a different aspect ratio in feeds, so keep anything essential away from the edges.
Why does my link show no image when I share it?
The usual causes, in rough order: the og:image URL is relative, and scrapers do not resolve relative URLs against the page; the image 404s or is blocked to bots; the page requires JavaScript to render the tags, and scrapers do not run JavaScript; or the platform cached an older version of the page from before the tags existed. This tool fetches the image URL to separate the first two from the rest, which is the part you cannot see by reading the markup.
Do I need twitter: tags if I already have og: tags?
Mostly not. X falls back to the open graph tags when the twitter equivalents are missing, so og:title, og:description and og:image already do the work. The one worth adding is twitter:card, because without it X may render a small square card rather than the large image one, and a 1200 by 630 image in a small card is a wasted image.
I fixed the tags but the old preview still shows
Platforms cache aggressively, so the fix is real and the cache is stale. Each has a debugger that refetches on demand: Facebook has the Sharing Debugger, X has the Card Validator, and LinkedIn has the Post Inspector. Run the URL through the relevant one after changing tags. Slack and Discord expire their caches on their own, usually within a day.
Does a missing og:image hurt anything measurable?
It costs clicks on every share, which is easy to underrate because you never see the shares that got no attention. It matters most for the links you did not post yourself: a directory listing, someone recommending your product in a group chat, a newsletter. Those are exactly the moments you are not there to compensate with a good caption, and a bare link in a feed of cards reads as broken.