Open Graph Preview & Debugger

Paste any URL and see exactly how it renders when shared on Facebook, X, LinkedIn, and Slack — then catch the missing or misconfigured tags before anyone shares a bare link.

We fetch the page on our server to read its tags (same as a social crawler) — nothing is stored.

Want to check whether a live page's images are properly sized too?

Run a free scan →

Open Graph image sizes by platform

One image at 1200 × 630 (a 1.91:1 ratio) covers almost everything. Set that as your og:image and you get a clean full-width card on Facebook, LinkedIn, Slack, and X. The per-platform details, when you need them:

PlatformImage sizeRatioNotes
Facebook / LinkedIn1200 × 6301.91:1The standard large card. Min 600 × 315; under that downgrades to a small thumbnail.
X / Twitter (large)1200 × 6281.91:1Needs twitter:card = summary_large_image. Falls back to OG tags if Twitter tags are absent.
X / Twitter (summary)144 × 144+1:1Small square thumbnail. Used when twitter:card = summary.
Slack / Discord1200 × 6301.91:1Reads standard OG tags. Discord also reads theme-color for the accent bar.
WhatsApp / iMessage1200 × 6301.91:1Reads OG tags; image must be reachable and reasonably small (under ~300 KB is safe).
Pinterest1000 × 15002:3Prefers tall images; uses og:image but rewards portrait pins.

The tags that actually matter

Open Graph has dozens of optional properties, but a share card only needs four things to look right:

  • og:title — the bold headline on the card.
  • og:description — the gray summary line under it.
  • og:image — the picture. Absolute https:// URL, 1200 × 630. This is the one that makes or breaks the share.
  • twitter:card — set to summary_large_image so X shows the big card instead of a thumbnail.

Declaring og:image:width and og:image:height is a nice extra: it lets a platform lay out the card correctly on the very first share, before it has downloaded the image.

Why the preview and the live share can differ

This tool reads the tags that are on the page right now. The platforms, however, cache their crawl results — sometimes for days. So if you just changed your tags, a fresh share elsewhere may still show the old card until the platform re-crawls. To force a refresh, run the URL through the platform's own re-scrape tool: Facebook's Sharing Debugger, LinkedIn's Post Inspector, or X's Card Validator. Use this tool to confirm what those crawlers will see; use their tools to clear the cache.

Common mistakes

  • Relative og:image URL. /images/card.png works in your browser but crawlers need the absolute https://yoursite.com/images/card.png.
  • Image too small. Anything under 600 × 315 drops you to a small thumbnail card on Facebook. Ship 1200 × 630.
  • Wrong aspect ratio. A square or portrait og:image gets center-cropped into the 1.91:1 card, often cutting off text baked into the image.
  • Text baked into the image edges. Cropping varies by platform, so keep important text in the middle 80%.
  • Forgetting twitter:card. Without summary_large_image, X shows a small thumbnail even when your og:image is perfect.
  • Assuming the fix is instant. It is not — the platform cache has to expire or be manually cleared.

Frequently Asked Questions

What is an Open Graph (OG) image?

The Open Graph image is the picture that appears when a URL is shared on social platforms and chat apps. It is set with the og:image meta tag in the page <head>. Platforms read that tag (and the related og:title and og:description) to build the share card. If og:image is missing or broken, the share renders as a bare text link, which gets dramatically fewer clicks.

What size should an Open Graph image be?

Use 1200 × 630 pixels (a 1.91:1 ratio). That is the size Facebook, LinkedIn, Slack, and X (with summary_large_image) all render at full width, and it downsamples cleanly everywhere else. The practical minimum for a large card is 600 × 315 — below that, Facebook falls back to a small thumbnail. Keep the file under about 300 KB so chat apps like WhatsApp and iMessage load it reliably.

Why does this tool fetch the page on the server instead of in my browser?

Browsers block cross-origin requests, so a page running in your browser cannot read another site's HTML. Social platforms have the same need and solve it the same way: their crawlers fetch the page from a server. This tool does exactly that — it requests the page from our server with a normal crawler user-agent, reads the meta tags, and discards the page. Nothing is stored. (This is different from our PNG/JPG to WebP converters, which run entirely in your browser because they work on files you already have.)

My share still shows the old image after I fixed the tags. Why?

Every platform caches the crawl result, often for days. Fixing the tag does not retroactively update shares that were already cached. Use the platform's own re-scrape tool to force a refresh: Facebook's Sharing Debugger, LinkedIn's Post Inspector, and X's Card Validator each re-fetch the page and clear their cache. This tool shows you the current tags so you know what they will pick up on the next crawl.

Do I need both Open Graph and Twitter tags?

Not strictly. X/Twitter falls back to Open Graph tags when Twitter-specific tags are absent, so og:title, og:description, and og:image cover most of the need. The one Twitter tag worth adding is twitter:card = summary_large_image, which tells X to render the big image card instead of a small thumbnail. Beyond that, Twitter tags only matter if you want a different title, description, or image on X than elsewhere.

Why is my og:image not showing up at all?

The most common causes: the og:image URL is relative (e.g. /img/card.png) instead of an absolute https:// URL — crawlers require absolute URLs; the image is behind authentication or blocked by robots.txt; the image is served over http on an https page; or the image is too large and the crawler times out. This tool flags the relative-URL and http cases directly, and loads the image so you can see whether it resolves.

Related Resources

Last updated: