The Open Graph Debugger is a deep-diagnostics tool for anyone whose Facebook / LinkedIn / X / Slack / Discord / WhatsApp share cards look wrong. Unlike a simple previewer, it stress-tests your URL from every angle a crawler might see it. It re-fetches the page with the actual user-agent strings that facebookexternalhit, Twitterbot, LinkedInBot, Slackbot, Discordbot, WhatsApp and TelegramBot send — so you catch UA-based cloaking, Cloudflare bot-blocking, and firewall rules that silently break previews. It follows the entire redirect chain hop-by-hop with status codes, TTFB and response headers (Cache-Control, X-Robots-Tag, Content-Type). It downloads the og:image and twitter:image, parses dimensions natively (PNG / JPEG / GIF / WebP / SVG — no PIL required), verifies HTTPS, and warns on anything under 200×200 (Facebook won't render it), off-ratio (target 1.91:1), or over 8 MB. It extracts every <script type="application/ld+json"> block and diffs the schema.org headline / description / image fields against your Open Graph tags — a mismatch typically means Google shows one snippet and Facebook shows another. It heuristically detects SPAs where the OG tags only appear after JavaScript runs (most scrapers don't execute JS, so the card silently fails). And it gives you a copy-paste-ready <meta> block that fills in what's missing, with one-click links to Facebook's Sharing Debugger, LinkedIn Post Inspector, and Twitter Card Validator to force a re-scrape after you deploy the fix. Bulk mode debugs up to 10 URLs at once (Pro plan). Everything server-side, SSRF-guarded, and safe on private URLs.
Preview vs debugger — which do you need?
A share-card previewer renders what your card should look like based on inputs you give it. A debugger tells you why the real card is broken. If your share card looks fine, use the preview tool. If it looks wrong in one place (say the Facebook image is missing but Slack unfurls fine), that's a debugger job — every platform's crawler behaves slightly differently and the only way to catch these bugs is to fetch the URL the way each crawler does. This tool re-fetches your page with the exact User-Agent strings facebookexternalhit/1.1, Twitterbot/1.0, LinkedInBot/1.0, Slackbot-LinkExpanding 1.0, Discordbot/2.0, WhatsApp/2.23 and TelegramBot send, then diffs the response against what a browser sees. If Cloudflare returns 403 to Facebook but 200 to your browser, that's the bug — and the debugger surfaces it in seconds.
What breaks Open Graph in production
In our audit data, roughly 60% of broken share cards trace to one of five root causes. 1. Missing og:image — the single most common bug; platforms fall back to a random image on the page (often a logo or ad). 2. og:image too small — anything under 200×200 kills the Facebook preview entirely; anything under 600×315 downgrades to the low-CTR side-image card. 3. og:image over HTTP — Facebook, Slack, and iMessage silently drop insecure images. 4. Bot-blocking / cloaking — Cloudflare bot fight mode, WAF rules, or JS challenges that return 403 or JS challenges to crawler UAs. 5. SPA rendering — OG tags injected via React / Vue / Angular after mount; most scrapers don't execute JS so they see an empty <head>. The debugger checks all five in one run and tells you which is your problem.
The redirect trap
Redirect chains are the invisible killer of share previews. When someone shares example.com/blog/my-post and that 301s to www.example.com/blog/my-post/, some scrapers (notably Slack) follow the redirect and read OG from the final URL, but others (older WhatsApp, some RSS readers) stop at the first hop and get whatever meta tags the redirecting page returns — usually nothing. The debugger traces the entire chain (up to 8 hops), reports every status code and TTFB, and flags dangerous patterns: HTTPS→HTTP downgrades, mixed www / naked-domain flips, chains of 3+ hops (Google drops after ~10), 302 temporary redirects where you meant 301 permanent, and terminal 4xx/5xx errors. If your card works in Slack but not WhatsApp, the redirect chain is where you look first.
Image validation without PIL
The image analyzer downloads the og:image and twitter:image and reads dimensions directly from the raw bytes — no image-processing library required. It parses PNG IHDR chunks, JPEG SOF markers (SOF0 through SOF15), GIF logical-screen dimensions, WebP VP8 / VP8L / VP8X headers, and SVG width/height attributes. For each image we report: exact dimensions, aspect ratio to 3 decimals, byte count, MIME type, HTTPS status, and HTTP response code. Then we cross-check against the ideal for each platform: Facebook large card — 1200×630 at 1.91:1, minimum 200×200, max 8 MB, PNG or JPG; Twitter summary_large_image — 1200×628, minimum 300×157, max 5 MB; WhatsApp — minimum 300×300 or the preview breaks silently. Any deviation shows up as a warning with the exact numbers.
OG vs JSON-LD consistency
Modern pages carry two overlapping metadata layers: og:* for social platforms and <script type="application/ld+json"> for Google's rich results. When they disagree, you get inconsistent branding — Google shows one headline in its SERP, Facebook shows another in the feed, and users lose trust because the click-through page doesn't match either. The debugger extracts every JSON-LD block (including @graph containers), collects headline / name / description / image from every Article, Product, WebPage, and Organization entity, and diffs them against your Open Graph tags. The output tells you exactly which fields match, which mismatch, and gives you the offending values side by side so you can pick which one wins.
Force re-scrape after the fix
Fixing your tags does nothing until every platform's cache expires — which can take a week. Every major platform provides a scraper endpoint you can hit to force an immediate re-scrape: Facebook at developers.facebook.com/tools/debug, LinkedIn at linkedin.com/post-inspector, Twitter at cards-dev.twitter.com/validator, and Pinterest at developers.pinterest.com/tools/url-debugger. The debugger surfaces one-click links to all four with your URL pre-filled, so after you deploy the fix you can invalidate every cache in under a minute. For Slack and Discord, the trick is different: append a cache-busting query string (?v=2) to the shared URL and paste it fresh — those platforms don't have a public debugger but a new URL is always re-scraped.