Social Media Preview
How it would look
The tags
The image URL is where most link previews break
og:image has to be an absolute URL — scheme, host and path. Open Graph defines it that way, and the social crawlers do not reliably resolve a relative path such as /img/share.png against the page they fetched, so a relative value usually yields a text-only card. Next most common is an image that is not publicly reachable: staging behind basic auth, a private bucket, an expired signed URL, or a CDN that turns away unfamiliar user agents. Open the image in a private window before blaming the markup, and keep schemes consistent — an https page pointing at an http image fails quietly.
Two vocabularies, one job
X falls back to og:title, og:description and og:image when the twitter: equivalents are missing, so duplicating every value is rarely worth the effort. The exception is twitter:card, which has no Open Graph counterpart: it picks the compact thumbnail or the wide image, and is better stated than inferred. Facebook, LinkedIn and WhatsApp are built around the og: namespace — do not assume they read twitter: tags. One syntax detail that quietly breaks cards: og: tags use property, twitter: tags use name.
| Tag | What it controls |
|---|---|
og:title | Headline on the card |
og:description | Supporting line; platforms truncate it at different lengths |
og:image | Absolute URL of the preview image |
og:url | Canonical URL; lets a platform treat link variants as one object |
og:type | website for most pages, article for posts |
twitter:card | summary or summary_large_image — picks the layout |
Editing a tag does not update an existing preview
Platforms cache what they scraped the first time a link was shared, and new tags do not invalidate that copy. Facebook's Sharing Debugger and LinkedIn's Post Inspector re-fetch on demand and replace it. X retired its public card validator, so there the practical move is a throwaway query string — a URL the cache has never seen. That confirms a fix but changes nothing for links already in circulation.
What this page can and cannot check
It renders the card from the tags you paste or type and hands the markup back for your head. It does not fetch your live URL: the same-origin policy stops a page reading another site's HTML unless that site opts in, and a fetch that did work would arrive as a browser request, not as the platform's crawler. So it cannot confirm that your image returns 200, that your server sends these tags to a crawler rather than only to a signed-in visitor, or that tags injected by client-side JavaScript are seen at all — social crawlers work from the HTML the server returns and generally do not run scripts. Each platform's own debugger is the only real check.
Share this tool with friends
Free to use, no sign-up, works on any phone.
Frequently Asked Questions
Most often the URL is relative rather than absolute. Open Graph expects a full URL with scheme and host, and social crawlers do not reliably resolve a relative path against the page they fetched. If the URL is already absolute, check the image is reachable without a session: staging behind basic auth, a private bucket, an expired signed URL, or a CDN that blocks unfamiliar user agents all fail quietly and leave a text-only card. Open it in a private window to confirm.
Not safely. Open Graph defines og:image as an absolute URL, and a relative path is the most common reason a preview comes back with no image. Some crawlers may resolve it against the page URL, but there is no guarantee across Facebook, LinkedIn, WhatsApp and X, and the failure is silent. Use the full https URL, and match the page's scheme so an https page does not point at an http image.
Mostly not. X falls back to og:title, og:description and og:image when the matching twitter: tags are absent, so the content is covered. The one worth adding is twitter:card, which has no Open Graph equivalent and selects the layout: summary for the small thumbnail, summary_large_image for the wide one. Watch the attribute difference too — og: tags are written with property, twitter: tags with name.
The platform is serving a cached scrape from the first time that URL was shared, and editing tags does not invalidate it. Facebook's Sharing Debugger and LinkedIn's Post Inspector re-fetch the page on demand and replace the cached copy. X retired its public card validator, so the usual workaround there is appending a query string, which creates a URL that has never been scraped — useful for testing, but it leaves the original link's cached card untouched.
In the head of the document, in the HTML your server returns. Social crawlers do not execute client-side JavaScript, so tags a script adds after load are generally not seen, even though a rendering search crawler might pick them up. If your framework sets meta tags on the client only, move them to server-rendered or prerendered output — and check with view-source or curl rather than devtools, since the inspector shows the DOM after scripts have run.
No. It builds the preview from the tags you paste or fill in and returns the markup for your head. It does not fetch your URL — the same-origin policy stops a page reading another site's HTML unless that site opts in — and it does not validate against a schema or guarantee how any platform will render the card. Use it for tags, wording and layout, then each platform's own debugger to confirm the page and image answer their crawler correctly.