Open Graph & Twitter Card Preview
Paste any public URL and this fetches it the way a share-card scraper would, reads the Open Graph and Twitter tags it finds, and shows what each major surface would render from them. The share image is measured from its own bytes rather than from whatever the page declares, so an image that is too small or does not load is reported as what it is rather than as what the markup claims.
Page URL
Unlike the other tools here, this one has to fetch the page from our server, because a browser cannot read another site’s tags. Only public http and https addresses are fetched, redirects and response size are capped, and nothing about the page is stored.
Paste a URL above to see the card each platform would build from its tags, and what is missing.
Make a share image worth the click
The tags are the easy half. Moda is where the 1200x630 that goes in them gets designed.
Try Moda free →Every platform reads the same tags and treats them differently
Open Graph was Facebook's, and it won: LinkedIn, Slack, Discord, WhatsApp, iMessage and most of the rest read og:title, og:description and og:image and build a card from them. X is the exception that still matters. It prefers its own twitter:title, twitter:description and twitter:image, falls back to the Open Graph tags when those are absent, and only renders the wide layout when twitter:card is set to summary_large_image. That is the single most common reason a link looks great in Slack and shows a small square thumbnail on X. Each surface also stops the title and the description at a different point, which is why the same card is read as a full sentence in one place and a fragment in another.
The image is where cards actually break
Most broken cards are not missing a tag. The tag is there and the image behind it is wrong: a relative path that resolves against the wrong base, a file behind a login, an image hosted somewhere that blocks non-browser requests, or something far below the size a platform will show. Facebook refuses images under 200 pixels on either edge outright, and most surfaces drop to a thumbnail below roughly 600x315. This page downloads the declared image from our server, the same way a scraper does, and reads its real format and pixel dimensions out of the file header, so a 60-kilobyte placeholder cannot pass itself off as a 1200x630 hero by declaring og:image:width.
Why this one has a server behind it
Every other tool on this site runs entirely in your browser. This one cannot: a browser is not allowed to read another site's HTML, and the whole job is reading another site's HTML. So the fetch happens on our server, under rules worth stating. Only public http and https addresses are fetched, and the address is checked at the moment the connection is made rather than beforehand, so a hostname that resolves to a private or internal address is refused rather than reached. Redirects are followed a few hops and then stopped, the download is capped, and the request carries no cookies. What comes back to your browser is a set of plain strings; the fetched page's HTML is never rendered into this one. Requests are rate-limited per address, which is the only thing keeping an anonymous endpoint from being used as somebody's proxy.
After you fix the tags, the platforms will still show the old card
Scrapers cache, and they cache for a long time. A corrected og:image will not appear in a Slack unfurl or a Facebook post until that platform re-scrapes the URL, and posting the link again is usually not enough to force it. Each of them runs its own debugger for exactly this — Facebook's Sharing Debugger, LinkedIn's Post Inspector, X's card validator — and running the URL through one clears its cache. This page has no cache at all: it fetches fresh every time, which is what makes it useful for checking a change you just deployed before you go and clear anyone else's.
Frequently asked questions
Why does the card here look different from the real thing?
Because it is our rendering of the tags, not a screenshot of the platform. Every surface restyles its cards on its own schedule, and chasing those visuals would make this page wrong within months. What does stay stable is the part that matters: which tag each platform reads, which fallback it uses when that tag is absent, whether the image is big enough for the wide layout, and roughly where the text is cut. Those are what the preview models.
It says my share image is unreachable, but it loads fine in my browser.
That is the most valuable finding this page produces, and it is usually one of three things. The image may be behind a login or a session your browser has and a scraper does not. It may be served from a host that blocks requests without a browser user agent, which blocks Facebook and LinkedIn the same way it blocks this. Or the URL in the tag may be relative or protocol-relative and resolving correctly for you and not from outside. Open the exact URL shown in a private window with no session and you will normally see it immediately.
Can I check a staging site or something on localhost?
No, and that is deliberate rather than an oversight. The fetch refuses any address that resolves inside a private network — loopback, RFC 1918 ranges, link-local including the cloud metadata endpoint — because an anonymous endpoint that will fetch arbitrary internal URLs on request is a server-side request forgery vector, not a feature. A staging site on a public hostname behind HTTP auth will also fail, for the same reason a real scraper fails on it.
Do you store the URLs people check?
The page is not written to any store. The request is made, parsed and answered, and what is kept afterwards is a count of how many previews have run recently, with no URL attached to it. Ordinary web server logs record that a request happened, as they do for every page on this site.
What size should the share image actually be?
1200 by 630 pixels, in PNG or JPEG, under about a megabyte. That is where every platform's own guidance has converged, it matches the roughly 1.91:1 crop the wide layouts use, and it has enough resolution for a retina display. The common failure is not size but composition: cards crop toward the centre, so a logo in a corner or text near an edge survives in the file and disappears in the card. Keep anything that must be legible inside the middle 80 percent. None of this touches search: these tags are read by social scrapers, not by search crawlers, and they are not a ranking factor.