The worst time to discover a broken link preview is after the launch tweet. You spend a week on a page, you write the announcement, you hit send — and the card that appears is a gray rectangle with a truncated title and no image, because og:image pointed at /images/og.png instead of https://yoursite.com/images/og.png. The post is already out. The card is already cached. You get to fix it and then ask everyone to reshare.
An Open Graph preview solves that by moving the check earlier. Instead of publishing and hoping, you look at what the card will be while the tags are still editable. That is the entire premise of the Open Graph Preview tool: enter your tags, or paste the ones you already have, and see approximate Facebook, X, LinkedIn, Slack, and Discord cards rendered side by side, with a pass/warn/fail verdict on every field.
The reason a single preview is not enough is that every platform reads the same tags and renders them differently. X truncates descriptions at roughly 110 characters; Facebook shows closer to 155. LinkedIn frequently drops the description entirely and shows only the image, title, and domain. Slack collapses the whole thing into a compact attachment with a colored rail. Discord embeds the description prominently but shrinks the image. A title that fits beautifully in a Facebook card can be cut mid-word on X, and you will never notice unless you look at both.
I build toolz.dev and ship pages constantly, and I got tired of the publish-check-fix loop. The tool runs entirely in the browser and makes no network calls at all — it never fetches your URL — which means it also works for pages that are not deployed yet, sit behind a login, or live on a staging domain the official platform debuggers cannot reach.
TL;DR: Open Graph tags control how your link looks when it is shared. Every platform reads the same
og:tags but truncates and lays them out differently, so previewing one platform tells you nothing about the others. The Open Graph Preview tool renders five platform cards from one set of tags, validates each field against current platform limits, parses an existing tag block if you already have one, and hands you a copy-ready<meta>block — all client-side, with no scraping and no upload.
Key Features
Five platform previews from one set of tags
The tool renders approximate cards for Facebook, X in both summary_large_image and summary styles, LinkedIn, Slack, and Discord. They all read from the same fields, so when you trim a title you watch it update everywhere at once. The point is not pixel-perfect fidelity — platforms redesign their cards without warning — but relative fidelity: correct proportions, correct truncation points, correct field ordering, so you can see which platform is the one that breaks.
Paste-and-parse for tags you already have
If the page exists, you rarely want to retype nine fields. Paste the raw HTML — a whole <head>, a view-source dump, or a loose block of <meta> lines — into the parse box and the built-in parser pulls out every og: and twitter: tag it recognizes and loads them into the form. The parser is regex-based rather than DOM-based, which is what lets the same code run in a browser, in Node, and in the desktop build without change.
Per-field validation with real limits
Every field gets a pass, warning, or fail status. A title over about 60 characters fails. A description between 110 and 155 characters warns, because it reads fully on Facebook and LinkedIn but gets cut on X. A relative og:image path fails outright — scrapers do not resolve them. An og:image served over plain http warns, because several platforms refuse to render non-HTTPS images. A twitter:site value that is not a valid handle fails. The verdicts are specific enough to act on rather than a generic "looks fine".
Image rules you can actually follow
Large-image cards on every major platform assume a 1.91:1 image; 1200x630 pixels is the size that satisfies all of them at once. The tool states that target explicitly, flags the failure modes that make images silently disappear, and — because a card with a broken image is the single most common Open Graph bug — renders your actual og:image URL in each preview, falling back to a clear placeholder if the image cannot load.
A copy-ready, correctly escaped meta block
The generated output is a complete tag block, not a fragment. It includes og:image:width and og:image:height, which matter more than most people realize: without them, some scrapers render a text-only card on the first fetch and only show the image after they have downloaded and measured it, which can be several hours later. Values are HTML-escaped, so an ampersand or a quote in your description cannot break out of the attribute and corrupt your markup.
100% client-side, with no scraping
The tool never requests your URL. This is deliberate, and it is worth understanding why: a browser cannot fetch an arbitrary third-party page because of the same-origin policy, and a server-side fetcher would mean shipping your unreleased URLs to somebody else's logs. Working from the tags you supply sidesteps both problems and unlocks the case the official debuggers cannot serve — validating a page that is not live yet. See data privacy in online tools for the broader reasoning.
How to Use the Open Graph Preview Tool
Step 1: Load your tags
You have two paths. If you are writing metadata from scratch, fill in the form: og:title, og:description, og:image, og:url, og:site_name, then pick an og:type and a twitter:card style and add your twitter:site and twitter:creator handles.
If the page already has tags, paste them instead. Open the page, view source (not the browser inspector — more on that distinction below), copy the <head>, and drop it into the parse box. Click Parse tags and everything recognized is loaded into the form. The parser understands the aliases too: og:image:secure_url and og:image:url both feed the image field, and twitter:title, twitter:description, and twitter:image are used as fallbacks when their og: equivalents are absent — which mirrors how the platforms themselves resolve the tags.
Step 2: Read the validation panel
The validation list is ordered the way the fields matter. Fix the fails first: a missing og:image, a relative image path, a title 20 characters over the limit. Then look at the warnings, which are mostly about the gap between platforms — a description that is fine for Facebook but long for X, a missing og:site_name that means your card shows a bare hostname instead of your brand.
The counters at the top of the panel give you a quick read. Zero fails and a couple of warnings is a perfectly shippable state; warnings are trade-offs, not bugs.
Step 3: Compare the cards
This is the step people skip, and it is the one that catches the real problems. Scan all six previews. Is the title cut on the X summary card? Does the description vanish on LinkedIn (it usually does — that is expected)? Does the image look right at 1.91:1, or is your logo cropped because you designed a square graphic and the card renders it wide?
Trim and re-check until every card reads cleanly. A useful discipline: write to the tightest constraint. If your description reads fully at 110 characters, it reads fully everywhere. If your title works at 55, it survives every card and every mobile layout.
Step 4: Copy the meta block and ship it
Copy the generated block into your page's <head>. In a framework — Next.js, Nuxt, SvelteKit, Astro — you will not paste raw <meta> tags, but the block is still your source of truth for exactly which fields to populate in the framework's metadata API.
Then do the step everyone forgets: re-scrape the URL in each platform's debugger. Shipping the fix does not clear the cached card. The Meta Tag Generator is the companion tool here if you also need the standard SEO tags — title, description, canonical, robots — that live alongside the social tags.
How the Open Graph Protocol Actually Works
Open Graph started at Facebook in 2010 as a way to turn a web page into a node in a social graph. The ambition faded; the tag vocabulary stuck, and it is now the de facto standard that Facebook, LinkedIn, Slack, Discord, WhatsApp, Pinterest, iMessage, Signal, and most other link-unfurling software read.
The mechanism is simple. When a link is shared, the platform sends a bot to your URL — facebookexternalhit, LinkedInBot, Slackbot-LinkExpanding, Discordbot, Twitterbot. That bot requests the raw HTML, reads the <head>, extracts the og: and twitter: meta tags, and builds a card. It is a single HTTP GET and a parse. The bot is not a browser: most of these crawlers do not execute JavaScript, which is the root cause of an entire genre of bug.
The tags themselves
Four tags are described as required by the protocol: og:title, og:type, og:image, and og:url. In practice og:description and og:site_name are equally load-bearing, because without them the card is either bare or falls back to whatever text the scraper can find on the page. The tags use the property attribute, not name — <meta property="og:title" content="..." /> — which trips people up because the Twitter tags do the opposite and use name. Most parsers are forgiving about this, but the platforms' own validators are not always, so it is worth getting right.
og: versus twitter: precedence
X reads Twitter Card tags first and falls back to Open Graph when they are absent. That means a page with only og:title, og:description, and og:image still produces a working X card — the fallback is by design.
So what actually needs a twitter: tag? Three things. twitter:card decides the layout, and there is no Open Graph equivalent: without it, X picks a card style based on what it finds, which is not a decision you want to delegate. twitter:site attributes the card to a brand account. twitter:creator credits the author. Everything else can safely come from Open Graph.
The practical rule: write complete Open Graph tags, then add exactly those three twitter: tags. Duplicating twitter:title and twitter:description is harmless but pointless unless you genuinely want different copy on X than elsewhere — which is occasionally a legitimate choice, since X's tighter truncation sometimes justifies a shorter, punchier description.
Image dimensions, ratios, and the cropping problem
The 1.91:1 aspect ratio is the number to internalize. 1200x630 pixels hits it, is large enough for retina displays, and is what Facebook, LinkedIn, and X all render without distortion for large-image cards.
The failure mode is subtle: platforms do not usually reject an off-ratio image, they crop it. Upload a square 1000x1000 graphic and Facebook will center-crop it to 1.91:1, which slices roughly a third off the top and bottom. If your headline text was vertically centered it survives; if you put a logo at the top it does not. Keep meaningful content inside a safe area and away from the edges, because different surfaces crop by slightly different amounts.
The compact X summary card is the exception. It wants a square image, minimum 144x144, and it will center-crop a 1.91:1 banner into a square — which usually destroys it. If you deliberately use summary, supply a square image; if you supply a banner, use summary_large_image.
Keep file size under about 5 MB (Facebook's documented ceiling; other platforms are stricter in practice), serve as PNG, JPEG, or WebP, and always use an absolute HTTPS URL. Relative paths and protocol-relative // URLs are the two most common ways an image silently fails to appear.
Why scrapers cache, and how to bust the cache
Every platform caches the result of scraping your page — typically for around seven days, sometimes longer. This is not stubbornness: a popular link can be shared thousands of times an hour, and re-fetching your page for each share would be a denial-of-service attack conducted by the platform. So they scrape once and reuse.
The consequence is that fixing your tags does not fix the card. The old preview persists for every existing share and for new shares until the cache expires. To force a refresh:
- Facebook: the Sharing Debugger, using the "Scrape Again" button. This also clears the cache used by Instagram and WhatsApp.
- LinkedIn: the Post Inspector. Entering the URL triggers a fresh scrape.
- X: the Card Validator has been deprecated and access is inconsistent. In practice, posting the link is the only reliable refresh.
- Slack: unfurl caches expire on their own; adding a harmless query parameter produces a fresh unfurl immediately.
- Discord: similar — a changed query string is the practical workaround.
That query-string trick is the universal escape hatch: https://example.com/page?v=2 is, to a scraper, a different URL with no cached entry. Use it for testing, not for the canonical link you actually publish, and keep og:url pointing at the clean canonical address so shares of parameterized variants consolidate correctly. The URL Encoder/Decoder is handy when those parameters get complicated.
What happens when tags are missing
Scrapers fall back, and the fallbacks are worse than you would hope.
No og:title and they use the <title> tag — which is usually written for search results and often ends in a pipe and your brand name, reading awkwardly as a card headline. No og:description and they use the meta description, or scrape body text, which can pull in a cookie banner or a navigation label. No og:image and most platforms show a text-only card, though some hunt for any image in the page and may find a logo, an avatar, or a tracking pixel. No og:url and the shared address is used as-is, so ?utm_source=twitter variants are treated as distinct pages and your share counts fragment.
There is one more failure class worth naming, because it is invisible in normal debugging: tags injected by client-side JavaScript. If your meta tags are set by React after hydration, the browser inspector shows them perfectly and the scraper sees nothing, because the scraper never ran your JavaScript. Always verify with view-source or curl, which show the raw HTML the server actually returned — not the DOM after your app has booted. The same applies to pages that return a 401, a login redirect, or a bot-blocking 403 to unauthenticated requests: the scraper gets the error page, not your content.
Common Use Cases
Pre-launch validation
The core case. Before a page goes live, paste the tags you intend to ship and confirm every card renders. This is the one thing the official platform debuggers cannot do, because they must fetch a live URL. A pre-launch check costs thirty seconds and saves the launch-day reshare.
Debugging a broken card
A link is unfurling wrong and you need to know why. Paste the page's current tags, read the validation panel, and the cause is usually immediate: a relative image path, an http image, a description twice the limit, a missing twitter:card. Fix, re-scrape in the platform debugger, done.
Auditing a site's metadata at scale
Working through a site page by page, pasting each <head> and reading the verdict, surfaces the drift that accumulates on any multi-contributor project: one page has Twitter tags and another does not, one description is 300 characters, three pages share the same generic og:image. The tool becomes a quick consistency check rather than a per-page guess.
Designing the share image
When you are choosing or commissioning an og:image, the preview shows you what the crop actually does to it in a wide card versus a square one. Designers routinely hand over a beautiful square graphic that gets butchered by a 1.91:1 crop; seeing that before it ships is cheaper than seeing it after.
Writing copy to the tightest constraint
Because the previews show X's truncation next to Facebook's, they turn an abstract character limit into something visible. Writing a description that reads fully at 110 characters is a discipline that is much easier to hold when you can see the ellipsis appear as you type. The Slug Generator covers the neighboring job of producing the clean URL that og:url should point at.
Working on staging or behind a login
Internal tools, client work under NDA, and pages behind an auth wall are all unreachable by platform debuggers. Because the tool works from tags rather than from a fetch, it handles them identically to a public page.
Platform Comparison
Current best-known guidance. Platforms change these numbers without announcement, and the truncation points are measured in pixels rather than characters — a title full of wide letters clips sooner than one full of narrow ones. Treat these as safe targets, not specifications.
| Platform | Recommended image | Ratio | Title shown | Description shown | Notes |
|---|---|---|---|---|---|
| 1200x630 | 1.91:1 | ~60 chars | ~155 chars | Minimum 200x200; center-crops off-ratio images | |
| X / Twitter (large) | 1200x628 | ~1.91:1 | ~60 chars | ~110 chars | Requires twitter:card=summary_large_image |
| X / Twitter (summary) | 800x800 | 1:1 | ~50 chars | ~90 chars | Minimum 144x144; square image required |
| 1200x627 | ~1.91:1 | ~100 chars | Often hidden | Description frequently dropped from the card | |
| Slack | 1200x630 | 1.91:1 | ~60 chars | ~140 chars | Compact attachment; unfurl cache expires on its own |
| Discord | 1200x630 | 1.91:1 | ~60 chars | ~160 chars | Renders description prominently, image smaller |
The takeaway from the table is the design target: a 1200x630 image, a title at or under 55-60 characters, and a description that lands under 110 gives you a card that renders correctly everywhere without per-platform tuning.
FAQ
What is the correct Open Graph image size?
Use 1200x630 pixels — a 1.91:1 ratio. That satisfies Facebook, LinkedIn, X, Slack, and Discord simultaneously for large-image cards, and is large enough to stay sharp on high-density displays. Keep the file under about 5 MB, serve it over HTTPS at an absolute URL, and keep important text away from the edges since surfaces crop by slightly different amounts. For a compact X summary card, supply a square image of at least 144x144 instead.
Why does my link preview still show the old image after I fixed the tags?
Because the platform cached the result of its earlier scrape, usually for about a week. Updating the tags does not invalidate that cache. Force a fresh fetch through the platform's debugger — the Facebook Sharing Debugger's Scrape Again button, or the LinkedIn Post Inspector. For Slack and Discord, adding a query parameter to the URL produces an uncached preview immediately, which is the fastest way to verify a fix.
Do I need both og: and twitter: tags?
X falls back to Open Graph when the Twitter equivalents are missing, so a page with complete og: tags produces a working X card. What Open Graph cannot express is the card layout, so you should still add twitter:card to choose between the large banner and the compact summary, plus twitter:site and twitter:creator to attribute the card. Those three plus complete Open Graph tags is the efficient combination.
How long should og:title and og:description be?
Keep og:title at or under about 60 characters. For og:description the platforms diverge: X shows roughly 110 characters, Facebook and LinkedIn show closer to 155 to 200. Writing to the tighter X limit means the description reads fully everywhere. Text past the limit is not lost, just hidden behind an ellipsis, so front-load the words that matter.
Why is my preview blank or showing only the URL?
The usual causes, in rough order of frequency: og:image is a relative path rather than an absolute URL; the image is served over plain http; the tags are outside the <head>; the tags are injected by client-side JavaScript that the scraper never executes; or the page returns a non-200 status or a login redirect to the bot. Check the raw HTML with view-source or curl rather than the browser inspector — the inspector shows the DOM after JavaScript has run, which is not what the scraper sees.
Does this tool fetch my URL to read the tags?
No. It makes no network requests at all. It works from the tags you type or paste, and everything is parsed and rendered in your browser. Browsers cannot fetch arbitrary third-party pages because of CORS, and a server-side fetcher would mean sending your unreleased URLs somewhere else. The trade-off is that you supply the tags — and the benefit is that pages on localhost, on staging, or behind a login work exactly like public ones.
Can I preview a page that has not been published yet?
Yes, and it is the main reason to use this rather than a platform debugger. The official debuggers must fetch a live URL, so they are useless before deployment. Here you paste the tags you intend to ship — from your template, your framework metadata object, or a local build — and the previews render immediately.
Do Open Graph tags help my search rankings?
Not directly. They are read by social and chat platforms, not used as a ranking factor by search engines. What they influence is the click-through rate on every share of your link, which drives traffic and, indirectly, the signals that do matter. Think of them as conversion optimisation for shared links rather than as an SEO lever. For the tags that do affect your search snippet, use the Meta Tag Generator.
