See exactly what Facebook, X, LinkedIn, WhatsApp and Slack will render — with real image dimensions decoded from the bytes, not just the meta tags. Detects cloaking, WhatsApp size drops, and image mismatches nobody else catches.
Paste up to 10 URLs. See exactly what Facebook, X, LinkedIn, WhatsApp, Slack and Discord will receive — including whether the site cloaks tags to different crawlers, and whether the og:image will actually render at the size you declared.
uploaded over TLS · deleted within one hour
Every tool on ToolsVale is scoped to one job. Here is exactly what this one does, and what it does not — so you know whether it fits before you start.
Notes from other visitors. Sign in with Google to add yours, or send a private suggestion straight to the developer.
Sign in to leave a comment. We only use Google — no passwords, no email spam.
Sign in with GoogleNo comments yet. Be the first.
A same-page side-by-side against the tools a visitor would otherwise pick. Every value is verifiable on the competitor's current site — flag anything that looks stale.
| Feature | Open Graph Checker this tool | opengraph.xyz | opengraph.to | metatags.io | pacgie.com |
|---|---|---|---|---|---|
| Actual image bytes decoded | Yes — HTTP RANGE 32KB sample, binary header parse | No — trusts meta tags only | No — trusts meta tags only | No — generator only, no live fetch | No — trusts meta tags only |
| Declared vs actual dimension mismatch flag | Yes — highlighted in red with copy-fix | ✗ | ✗ | ✗ | ✗ |
| WhatsApp 300KB / 600KB gate check | Yes — inline warning on WhatsApp preview | ✗ | ✗ | ✗ | ✗ |
| Multi-crawler differential (cloaking detection) | Yes — 7 crawlers with distinct headers, diff grid | No — one fetch only | Limited — UA swap only, no header profiles | ✗ | ✗ |
| Per-platform safe-zone overlay | Yes — interactive toggle for FB/X/LinkedIn/WhatsApp/Discord | ✗ | ✗ | ✗ | ✗ |
| Type-specific tag validation (article, product, video, book) | Yes — required-tag table per og:type | ✗ | Partial | ✗ | ✗ |
| Copy-ready fix snippets with defaults | Yes — auto-filled from existing evidence | Partial — generic templates | Partial | Generator only | ✗ |
| Free URLs per run | 10 | 1 | 1 | 1 | 5 |
| Signup required | ✗ | ✗ | ✗ | ✗ | ✗ |
| Three transparent scores (not one opaque number) | Yes — Metadata / Consistency / Preview | No — no score | Single opaque score | ✗ | ✗ |
Compared on public plans as of the last review date. Competitor features change — if you spot a stale row, please flag it and we'll re-verify.
Every other free tool reads your og:image:width and believes it. When the actual PNG is 800×420 but you declared 1200×630, Facebook caches the wrong dimensions and your preview crops wrong until you force a re-scrape. This tool downloads 32KB of the image via HTTP RANGE, parses the binary header (PNG IHDR chunk, JPEG SOF marker, WebP VP8X box, AVIF ispe box), and reports the truth. Flags mismatches in red before you publish.
Fetches your page as Browser, Googlebot, Facebook (facebookexternalhit/1.1), X (Twitterbot/1.0), LinkedIn (LinkedInBot/1.0), Slack (Slackbot-LinkExpanding), and Discord (Discordbot/2.0) — with the exact User-Agent and Accept headers each one sends. When results differ across crawlers, a highlighted diff grid shows exactly which fields your server is cloaking or blocking. Nobody else does this.
WhatsApp 300KB warning + 600KB hard drop. Facebook 600×315 minimum + 1200×630 recommendation. X summary_large_image downgrade risk at <300×157. LinkedIn 1.91:1 aspect check ±15%. AVIF cross-platform warning for Twitter. Every rule sourced from 2026 platform documentation, not a black-box score. Each verdict shows what triggered it and how to fix it.
Metadata Health (are the required tags present and well-formed?), Crawler Consistency (do all 7 bots receive the same tags?), Preview Readiness (will the image actually render everywhere?). Each score exposes its full breakdown — you can see exactly which sub-check cost you points. Compare that to competitors who show a single 87/100 with no explanation.
Every fixable issue includes a copy button and the exact tag to paste into your — with defaults auto-filled from your existing content. Missing og:image? You get plus the width, height, alt, and secure_url tags. Missing article:published_time? You get a template with the current date. No hunting through Facebook docs at 2am.
Most free Open Graph checkers do one thing: fetch your page, read the meta tags out of the HTML, and show them back to you in a table. If the tags say og:image:width="1200", they trust it. If the tags say twitter:card="summary_large_image", they believe it. When your Facebook preview then renders broken or your WhatsApp link shows as bare text in a chat bubble, the checker gave you no warning because it never looked past the tags.
The gap is the image. Every social platform — Facebook, X, LinkedIn, WhatsApp, Slack, Discord, iMessage, Pinterest — fetches your og:image URL, decodes the file, and makes rendering decisions based on the actual bytes. Not the meta tag. If you declared og:image:width="1200" but uploaded an 800px image, Facebook caches the wrong dimensions, crops the wrong region, and the preview stays broken until you force a re-scrape. If your PNG is 900KB, WhatsApp silently drops the preview entirely and the link renders as unstyled text. Neither of these failures shows up in a meta-tag-only checker.
This Open Graph checker was built to close that gap. It fetches your page as seven distinct social crawlers using the exact User-Agent and Accept headers each one sends. It downloads the first 32KB of your og:image via HTTP RANGE and parses the binary header — PNG IHDR chunk, JPEG SOF marker, WebP VP8X box, AVIF ispe box — to report the real width, height, format, byte size, and alpha channel. Then it runs a deterministic rule engine against every 2026 platform specification: WhatsApp’s 300KB compression threshold and 600KB hard drop, Facebook’s 600×315 minimum for the large card format, X’s 300×157 minimum for summary_large_image, LinkedIn’s 1.91:1 aspect crop, and about a dozen more.
The Open Graph protocol defines dozens of tags. In practice, eight of them drive nearly every social preview you’ll ever ship:
og:title — the headline shown on the card. Keep it under 60 characters for Facebook and 70 for LinkedIn. If missing, platforms fall back to <title>.og:type — the content type. Most pages use website. Blog posts use article. Products use product. Videos use video.other. Books use book. The declared type controls which additional tags are required (see the type-specific section below).og:image — the preview image URL. Must be an absolute HTTPS URL, at least 600×315 pixels for a large Facebook card, ideally 1200×630 for universal compatibility.og:url — the canonical URL for this piece of content. Facebook uses this to de-duplicate shares. Should match your <link rel="canonical"> in nearly every case.og:description — a 2-4 sentence summary shown under the title. 120-160 characters is the sweet spot for most platforms. Without it, platforms may pull the first paragraph of body text or leave the description blank.og:site_name — your site or brand name. Displayed as the source on LinkedIn and some Facebook contexts. Helps trust.og:image:width and og:image:height — declared dimensions of the image. Critical: these must match the actual file. Facebook caches whatever you declare and uses it for layout math. A mismatch is one of the most common causes of broken previews and this checker flags it explicitly.og:image:alt — alternative text for the image. Used by LinkedIn’s accessibility features and screen readers.Every platform has different rules for what constitutes a valid og:image. The table below reflects verified 2026 specifications:
| Platform | Min dimensions | Recommended | Max file size | Aspect ratio |
|---|---|---|---|---|
| 600 × 315 | 1200 × 630 | 8 MB | 1.91:1 | |
| X (Twitter) — summary_large_image | 300 × 157 | 1200 × 628 | 5 MB | 1.91:1 |
| X (Twitter) — summary | 144 × 144 | 400 × 400 | 5 MB | 1:1 |
| 1200 × 627 | 1200 × 627 | 5 MB | 1.91:1 (±10%) | |
| 300 × 200 | 1200 × 630 | 600 KB (hard drop above) | Flexible | |
| Slack | Any | 1200 × 630 | 2 MB | 1.91:1 preferred |
| Discord | Any | 1200 × 630 | 10 MB | Any |
| 600 × 600 | 1000 × 1500 (2:3) | 10 MB | 2:3 vertical preferred |
The single safe choice for most sites is 1200 × 630 pixels at 1.91:1 aspect ratio, under 300 KB, saved as JPG quality 82 or WebP. This renders cleanly on every platform above, ships under WhatsApp’s compression threshold, and stays well below every file-size limit.
Broken social previews almost always fall into one of ten categories. A meta-tag-only checker catches the first two or three. The rest require actually fetching and analyzing the image bytes, or fetching your page as the specific crawler in question.
The obvious one. No og:image, no image in the preview. No og:title, platforms fall back to your <title> and hope. Every meta-tag checker flags this correctly.
Unclosed quotes, wrong attribute (name instead of property), tags outside the <head>. Some CMS plugins strip content that looks like HTML from certain fields. Meta-tag checkers catch some of these.
This is where most checkers fail silently. You wrote og:image:width="1200" in your template, but the file at that URL is actually 800px wide. Facebook fetches the image, sees the mismatch, caches the wrong crop math, and your preview renders with the wrong region visible. Nothing warns you because the meta tag itself is present and well-formed. This OG tag checker downloads 32KB of the image, decodes the binary header, and flags the mismatch explicitly with a copy-ready fix.
WhatsApp silently drops any image over roughly 600KB — no error, no fallback, the link just renders as text in the chat bubble. Between 300KB and 600KB, WhatsApp compresses aggressively and the preview visibly degrades. Almost no free checker warns about this. This one shows a warning inline on the WhatsApp preview card whenever your image crosses either threshold.
If your twitter:card is set to summary_large_image but your image is under 300 × 157 pixels, X silently falls back to the small square summary card. No error, no notification — the wide edge-to-edge card you designed for just doesn’t appear. This checker detects the downgrade risk and flags it.
Facebook, LinkedIn, and most platforms require HTTPS for images. An HTTP image URL means either no card renders or a broken image placeholder shows. The fix is to set both og:image and og:image:secure_url to HTTPS variants.
Facebook uses og:url for share deduplication. Google uses <link rel="canonical"> for search indexing. When these disagree, your Facebook shares point to one URL while Google indexes another. Confusing for users, worse for analytics. This checker cross-validates the two and flags any mismatch.
Some sites (usually accidentally, sometimes via aggressive WAF rules or Cloudflare Bot Fight Mode) serve different HTML to Facebook’s crawler than to a regular browser. The result: preview looks fine when you check the page yourself, but Facebook receives an empty or default response. This checker fetches your page as seven distinct crawlers with each one’s exact headers, then diffs the responses. If any crawler receives different content, a highlighted table shows exactly which field differs where.
If you’re building with React, Vue, Next.js in client-mode, or any SPA framework, your OG tags may be injected into the DOM after page load by JavaScript. Facebook’s crawler doesn’t execute JavaScript — it reads the initial HTML response only. Your browser sees the tags, DevTools sees the tags, this checker sees what crawlers see. If a tag is missing from this checker’s output but visible in your browser DevTools, JavaScript is the culprit and you need server-side rendering.
AVIF images are supported on Facebook, LinkedIn, and Discord but have spotty support on X and older Slack clients. SVG images are almost universally rejected as og:image. GIF works but only shows the first frame. This checker detects the format from the actual binary header (not the file extension, which can lie) and warns about platform-specific compatibility issues.
Beyond the eight core tags, the Open Graph protocol defines additional tags that unlock richer previews depending on your og:type. Missing these means your card renders as a generic link even when you’ve set the correct type. This checker validates the required tags per type and flags anything missing.
<meta property="og:type" content="article">
<meta property="article:published_time" content="2026-08-22T10:00:00+00:00">
<meta property="article:author" content="Author Name">
<meta property="article:section" content="Category">
<meta property="article:tag" content="tag1">
<meta property="article:tag" content="tag2">LinkedIn and Facebook use article:published_time to show a timestamp on the card. Pinterest uses article:author and article:section for rich pin data.
<meta property="og:type" content="product">
<meta property="product:price:amount" content="99.00">
<meta property="product:price:currency" content="USD">
<meta property="product:availability" content="in stock">
<meta property="product:brand" content="Brand Name">Facebook Shops and Pinterest Product Pins read these to display price and availability directly on the share card. Without them, the card renders as a generic link even for a product page.
<meta property="og:type" content="video.other">
<meta property="og:video" content="https://example.com/video.mp4">
<meta property="og:video:type" content="video/mp4">
<meta property="og:video:width" content="1280">
<meta property="og:video:height" content="720">Some platforms — notably Facebook and LinkedIn — will render an inline video player on the share card when these tags are present. Missing og:video:type is the single most common reason video cards render as static images.
<meta property="og:type" content="book">
<meta property="book:author" content="Author Name">
<meta property="book:isbn" content="978-3-16-148410-0">
<meta property="book:release_date" content="2026-01-15">Once this Open Graph checker has flagged an issue, the fix workflow is usually the same regardless of platform:
<head>Every fixable issue in the results includes a “Copy fix” button that yields a ready-to-paste <meta> tag with sensible defaults filled from your existing content. For example, if og:image:width is missing but the checker decoded the actual image as 1200×630, the copy button gives you:
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">Push your update, deploy, or publish. Verify the tag is now present by re-running this checker on the same URL. If the tag appears in the results, the change is live.
This is the step most people skip and it’s why “I already fixed the tags but Facebook still shows the old image” is the most common complaint about Open Graph. Every major platform caches OG data aggressively — Facebook for up to 30 days, LinkedIn for 7 days, WhatsApp for a variable period tied to the recipient device.
?v=2) which WhatsApp treats as a new URL.This checker includes one-click deep-links to Facebook Sharing Debugger, LinkedIn Post Inspector, and Pinterest URL Debugger at the top of every result, with your URL pre-filled. Re-scrape after every meaningful change.
If you’re building with React, Vue, Next.js in client-only mode, Nuxt in SPA mode, Angular, or any framework that renders content client-side, you have a specific Open Graph problem worth spelling out clearly.
Social crawlers — Facebook’s facebookexternalhit/1.1, X’s Twitterbot/1.0, LinkedIn’s LinkedInBot/1.0, WhatsApp, Slack, Discord — do not execute JavaScript. They fetch your HTML, parse the <head> as it arrives from the server, and stop. Whatever your JavaScript does after that is invisible to them.
If your OG tags are injected into the DOM after page load (via react-helmet, next/head in client components, vue-meta without SSR, or manual DOM manipulation), crawlers see an empty or default <head>. Your preview breaks silently — your browser DevTools shows the tags, but no social platform ever sees them.
The fix is server-side rendering. In Next.js, use getServerSideProps or the App Router’s server components with metadata. In Nuxt, use useSeoMeta in a server context. In Remix, use the meta export. In pure client-rendered apps, use a static-site generator that pre-renders each route, or a service like Prerender.io that serves pre-rendered HTML to crawlers specifically.
This checker helps diagnose the JavaScript problem indirectly. If a tag is missing from the results here but visible in your browser DevTools, JavaScript injection is the cause. That’s your signal to move to server-side rendering.
WhatsApp is the most under-served platform in Open Graph tooling. Meta owns it but never released official documentation for how its link preview works. What follows is derived from reverse-engineering, community testing, and direct observation as of 2026:
User-Agent that identifies as WhatsApp. It sends a generic browser-like string. If your server blocks non-browser user-agents at the WAF level, you may accidentally block WhatsApp without knowing it.This checker enforces the size gates explicitly and shows both the 300KB warning and 600KB critical threshold inline on the WhatsApp preview simulation.
Most Open Graph checkers give you one opaque number like “SEO Score: 87/100” with no explanation. This tool gives you three, each with a full breakdown so you can see exactly what’s costing points:
Are the required and recommended tags present, well-formed, and correctly valued? Points are allocated across og:title, og:type, og:url, og:image, og:description, og:site_name, twitter:card, canonical, and type-specific required tags. A score of 80+ means your metadata is essentially complete.
When multi-crawler mode is enabled, this score measures whether all seven crawlers receive the same tags. A score below 100 means at least one crawler is seeing different content — either cloaking, geo-differentiation, or a WAF blocking specific user-agents. A score of 100 with multi-crawler mode off means the check wasn’t run and no consistency conclusion can be drawn.
Will the image actually render correctly on every major platform? Combines: image loads over HTTPS, decoded dimensions meet Facebook’s 600×315 minimum, aspect ratio within LinkedIn’s 1.91:1 tolerance, file size under WhatsApp’s 600KB cap, declared dimensions match actual, alt text present, and recommended 1200×630 size hit. A score above 80 means your preview will render cleanly everywhere; below 50 means at least one platform will fail.
This Open Graph checker is designed to catch problems before you rely on the official debuggers, which are slow, rate-limited, and provide inconsistent feedback. For final verification and cache refresh, the official tools are still authoritative:
The recommended workflow: iterate here to catch and fix issues fast, then verify on the official debuggers once as a final check before shipping. Deep-links to all four official debuggers appear at the top of every result on this page with your URL pre-filled.
Patterns that cause hard-to-diagnose preview failures, seen repeatedly in real-world audits:
name instead of property for og: tags. Correct is <meta property="og:title"> — the wrong <meta name="og:title"> is silently ignored by Facebook. Twitter tags use name, OG tags use property. This is the single most common cause of “the tag is right there but nothing works”.og:image. Must be absolute (starting with https://). Relative URLs like /images/social.jpg fail on every platform.og:image tags without clear ordering. Facebook picks the first, but behavior varies by platform. Declare one primary and use additional tags only if you specifically want to offer alternatives.<head>. Some CMS themes inject OG tags into the <body>. Crawlers stop parsing at </head>. Move them.Paste up to 10 URLs into the checker above. For a single URL, results stream in within about 3 seconds after the initial cold start. Enable multi-crawler mode to fetch as all seven social crawlers in parallel — takes about 7× longer but reveals cloaking that single-crawler checks never see. Every fixable issue includes a copy-ready <meta> tag with defaults filled from your existing content. Deep-links to the four official platform debuggers appear at the top of every result so you can force cache refresh in one click after applying your fixes.
The tool is free, requires no signup, and processes URLs server-side (nothing stored beyond a short cache). Rate-limited to 30 requests per minute per IP. Built for developers, marketers, and technical SEOs who need answers faster than the official debuggers can provide them.
Last reviewed August 2026 · this tool runs server.
Open Graph is a protocol Facebook created in 2010 (adopted by every major platform since) that tells crawlers how to display your link when someone shares it. Tags like og:title, og:description, and og:image control the preview card on Facebook, LinkedIn, WhatsApp, Slack, Discord, iMessage, and dozens of other apps. Without them, your link renders as a bare URL — kills click-through and looks unprofessional.
1200×630 pixels remains the universal standard — 1.91:1 aspect ratio, works cleanly on every major platform. Facebook prefers dimensions rounded to hundreds. WhatsApp needs at least 300×200 to render at all. X requires 300×157 minimum for summary_large_image (below that it silently downgrades to the small square card). File size matters more than most people realize: keep it under 300KB for WhatsApp to render cleanly, hard cap at 600KB or WhatsApp drops the preview entirely.
Facebook caches OG data aggressively — often for 30 days. Once you've fixed the tags, you need to force a re-scrape by pasting your URL into the Facebook Sharing Debugger (developers.facebook.com/tools/debug) and clicking "Scrape Again." This tool includes a one-click deep-link to the debugger at the top of every result. LinkedIn caches for 7 days and has its own Post Inspector; the same link appears next to the Facebook one.
Three most common reasons: (1) your og:image is over 600KB — WhatsApp silently drops it; (2) image is under 300×200 pixels — WhatsApp refuses to render small images; (3) your server is blocking the WhatsApp crawler (which does not identify as WhatsApp — it uses a generic User-Agent). This tool checks all three and shows a warning inline on the WhatsApp preview card when any threshold is crossed.
og:image is read by every platform (including X/Twitter as a fallback). twitter:image is X-specific and overrides og:image on X only. You only need twitter:image if you want to serve X a different image than everyone else — usually not worth the maintenance. Set og:image well and skip twitter:image. Do set twitter:card="summary_large_image" though — that's what triggers the big card format on X.
Because your tags are injected by JavaScript. Facebook's crawler doesn't execute JS — it reads the initial HTML response only. If you're using React, Next.js, or another SPA framework and rendering tags client-side, crawlers see an empty . Fix: use server-side rendering (Next.js getServerSideProps, Nuxt asyncData) or a static generator, or ensure your framework injects tags into the initial HTML payload. This tool sees what crawlers see — if a tag is missing here, it's missing for crawlers.
Two options: (1) update the tags to match the actual image file — the tool shows you the real decoded dimensions with a copy-ready fix; (2) replace the image file so it matches the declared dimensions. Option 1 is faster if the image looks correct visually. Never leave declared dimensions wrong — Facebook uses them for layout math and will crop the wrong region until fixed.
summary_large_image is the wide edge-to-edge card format on X — visually much stronger than the small square "summary" card. X requires the image to be at least 300×157 pixels; below that, it silently falls back to summary. If your og:image is 200×200 and you declared summary_large_image, X shows you a square thumbnail with no warning. This tool detects the downgrade risk and flags it explicitly.
Not directly — Google doesn't use OG tags as a ranking signal. But indirectly, yes: better previews mean higher click-through on social shares, which drives traffic, engagement signals, and backlinks. Google also falls back to og:title and og:description when your