Social Preview Checker

Fetches a page's Open Graph and Twitter Card meta tags plus the real pixel dimensions of its preview image, and classifies the result into the problems that actually break a shared link: missing og:title/og:description/image, a relative og:image URL (Open Graph requires it be absolute), an image below the platform's size minimum, a missing twitter:card, a duplicated tag, and an og:url that doesn't match the page you checked. Applies the twitter:image → og:image fallback chain correctly instead of flagging a missing twitter:image as a problem on its own.

1. Run the CLI against your page

Node.js, no dependencies to install:

node cli/check.mjs https://example.com/your-page --json

Get check.mjs, probe.mjs, analyze.mjs, metatags.mjs and imagesize.mjs from the repo — plain Node, nothing to install. It only ever talks to the URL you pass and whatever it points its preview image at; nothing goes through this site.

2. Paste the JSON output here

Paste the JSON from step 1 and click Check.

Bonus: check any image URL's real dimensions, no CLI needed

Loading an <img> element (unlike fetching its bytes) is not subject to CORS, so this works for a third-party image URL directly in this page -- nothing is uploaded, the image loads straight from its own host to your browser.

Common questions

Why does my og:image not show up on LinkedIn or Slack even though it works on Facebook?

The most common cause this tool catches is a relative og:image URL (like /images/preview.png instead of https://example.com/images/preview.png). The Open Graph protocol requires og:image to be an absolute URL, and crawlers differ in how forgivingly they handle a relative one -- some resolve it against the page URL, others simply fail to load an image at all. The second most common cause is the image being below the platform's minimum size, which some crawlers reject outright rather than upscale. More detail: the fallback chain and size-rule reference.

Do I need a separate twitter:image tag, or does og:image work on X/Twitter too?

You don't strictly need one. Twitter/X's card renderer falls back to og:image when twitter:image is absent (and to og:title/og:description for those tags too), so a page with only Open Graph tags set can still render correctly there. This tool follows that fallback chain rather than reporting a missing twitter:image as a problem on its own -- it only becomes one if the og:image it falls back to has its own issue (too small, unreachable, relative).

What image size does Facebook actually require?

Facebook's own sharing documentation states a minimum of 200x200 pixels, below which the image is commonly not rendered at all, and a recommended size of 1200x630 pixels (a 1.91:1 ratio) for a full-size preview. Platform rendering behaviour is not contractually guaranteed and can change without notice -- treat these as strong, documented defaults rather than an absolute promise.

What image size does Twitter/X's summary_large_image card require?

Twitter's card documentation states a minimum of 300x157 pixels for the large-image card, below which it commonly falls back to a smaller layout or shows nothing, and a recommended size of 1200x628 pixels (roughly a 2:1 ratio).

Why does this need a CLI instead of just checking a URL I type into the page?

Fetching an arbitrary third-party page's HTML from inside a browser tab is blocked by CORS unless that site opts in with an Access-Control-Allow-Origin header, which almost none do -- the same restriction every other response-probing tool in this portfolio runs into. A small local CLI with no such restriction, run from your own machine, does the actual fetching. The one thing the browser CAN do on its own is check an image's real pixel dimensions, since loading an <img> element (unlike a fetch() of its bytes) is not subject to CORS -- this page's third tool does exactly that.

Does a clean report mean my link preview will definitely render correctly everywhere?

No. This checks a specific, documented set of Open Graph and Twitter Card patterns from one page fetch -- it is not a guarantee of how any individual platform's crawler will render the result today, since platforms cache aggressively, sometimes require a manual cache-refresh (LinkedIn's Post Inspector, for instance), and can change their rendering rules without notice. Treat a clean report as evidence these specific, well-documented patterns are correct, not a determination that every platform's preview will look a particular way.