Submit a URL to see the title, description, and image a social network would pick up from your Open Graph and Twitter card tags — plus a checklist of missing or invalid tags to fix before you launch.
When you paste a URL into X, LinkedIn, Slack, Discord, iMessage, or any chat app, the platform doesn't run your JavaScript. Instead, its crawler performs a quick server-side fetch of the raw HTML and looks for a handful of tags in the <head>: the Open Graph protocol tags (og:title, og:description, og:image, og:url, og:type, og:site_name), the Twitter card tags (twitter:card, twitter:title, twitter:description, twitter:image), the plain <title> and <meta name="description"> fallbacks, and rel="canonical".
Each platform has its own preference order, but broadly: Open Graph tags win first, the Twitter tags fill in gaps, and the classic HTML tags are the final fallback. That's why a page with a perfect <title> but no og:title can still look wrong when shared — or, more often, why a page that looks flawless in the browser renders as a bare link with a random image in Slack.
The preview image is where most social cards fail. The universally safe target is 1200 × 630 pixels (a 1.91:1 ratio), under 1 MB, served over https://. That ratio is what X uses for summary_large_image cards and what Facebook, LinkedIn, and Slack display by default. Image formats matter too: PNG and JPG are universally supported, while WebP support is inconsistent across crawlers — some platforms simply drop the image if they can't parse the format.
Keep the important content (text, logo, product shot) inside the center of the image with generous padding, because several platforms crop the edges when rendering the card at different aspect ratios. A 40 × 40 favicon is not a substitute — crawlers will reject images below a minimum size and render a text-only card instead.
The most confusing part of Open Graph debugging: you fix the tags, share the link, and the old card still appears. That's because every platform cachesthe crawled result. X, Facebook, and LinkedIn each keep their own copy of your metadata, and they won't re-crawl until you either use their official debugging tool (the X Card Validator, the Facebook Sharing Debugger, or the LinkedIn Post Inspector) or wait for the cache to expire — which can take days.
The practical workflow: fix the tags in your HTML, deploy, verify with a tool like this one that the live HTML is correct, then run the URL through each platform's debugger to force a cache refresh. If the debugger still shows stale data, you almost always have a CDN or edge cache serving old HTML — purge it, or cache-bust the page URL when testing.
Suppose you ship https://acme.com/blog/acme-2-launch. A checked-out version of the head looks like this:
<title>Acme 2.0: Automations for Every Workflow</title> <meta name="description" content="Acme 2.0 adds automations, 40+ integrations, and a new free tier."> <link rel="canonical" href="https://acme.com/blog/acme-2-launch"> <meta property="og:type" content="article"> <meta property="og:title" content="Acme 2.0: Automations for Every Workflow"> <meta property="og:description" content="Acme 2.0 adds automations, 40+ integrations, and a new free tier."> <meta property="og:url" content="https://acme.com/blog/acme-2-launch"> <meta property="og:image" content="https://acme.com/og/acme-2-launch.png"> <meta property="og:site_name" content="Acme"> <meta name="twitter:card" content="summary_large_image"> <meta name="twitter:image" content="https://acme.com/og/acme-2-launch.png">
Every tag is present, the image URL is absolute and https, and the description sits in the 70–155 character sweet spot. When this URL is pasted into Slack or X, the crawler has everything it needs: title, description, and a full-width 1200×630 image. The checker above reports zero errors on a page like this — which is exactly what you want before your launch tweet goes out.
Strictly, no — most platforms fall back to Open Graph when Twitter tags are missing. But adding twitter:card at minimum is worth it, because it controls the card layout on X (summary vs summary_large_image), which no OG tag does.
Each crawler has different limits on image size, format, and response time. A WebP image over 1 MB might pass on Facebook but be dropped by Slack. Serving a compressed 1200×630 JPG or PNG under 1 MB from a stable https URL avoids nearly all of these edge cases.
It depends on the platform. After the tags are fixed and deployed, forcing a re-crawl with the platform's debugger updates the card almost immediately. Without a forced re-crawl, caches can hold the old version for days.
Best practice is yes. The Open Graph spec technically allows relative URLs, and many crawlers resolve them against the page URL, but some pick the wrong base or skip them entirely. An absolute https:// URL is the only version that works everywhere.
No — the checker can only fetch publicly accessible pages, the same way a social network's crawler would. If your page is behind auth, the crawler for X or Slack couldn't see it either, so there would be no card to optimize.
A directory listing with a rich social card gets measurably more clicks. Check your tags, then submit to high-DR directories with confidence.