Open Graph Preview Tool

How to Preview a Link

Features

The Preview Nobody Checks Until It's Already Live

A link can look perfect in the address bar and still fall apart the moment someone shares it — a blank gray box where an image should be, a title that's just the domain name, a description pulled from random navigation text. None of that shows up while you're writing the page; it only shows up in the share preview, by which point it's usually already been posted. This tool renders that preview before you find out the hard way.

Who Actually Reaches for This

• Bloggers and publishers — confirming a new post's image and title actually show up before sharing it anywhere
• Marketing and social teams — checking a campaign landing page looks right across every platform it'll be shared on, especially once a link is carrying UTM tracking parameters that shouldn't affect how the card renders but occasionally do
• E-commerce teams — verifying product pages show the right image, not a placeholder or unrelated banner
• Developers — testing Open Graph tags right after adding them, without waiting on a platform's own cache to catch up
• Job posters and recruiters — making sure a listing shared on LinkedIn actually shows the role title, not the company homepage's generic card

Where This Data Actually Comes From

Reading another site's page source from inside a browser tab runs into the same wall every cross-site tool does — browsers block it by default. This tool routes the request through a dedicated link-preview service that fetches the page independently and returns its title, description, image and site details, the same underlying approach every social platform's own crawler uses to build a preview in the first place.

A Launch Day Story

A product page goes live, gets shared in a Slack channel for the team to check, and shows up as a bare gray box with no image — despite the page clearly having a hero photo front and center. The image wasn't missing from the page, just from the og:image tag specifically, which platforms read independently of whatever's visually on screen. Running the URL through a preview tool before the official announcement catches exactly this, instead of finding out from a confused reply in the team channel.

The same check matters just as much for a domain that recently moved hosts — if the DNS Lookup Tool shows the migration hasn't fully propagated yet, a preview check can pull stale data from whichever server happens to answer first, which looks like a broken tag when it's really just timing.

Getting a Card That Actually Looks Good

• Use a full, absolute image URL, not a relative path — platforms reading og:image need a complete https:// address to fetch the image directly.
• Aim for 1200×630 pixels. It's the safest size for the 1.91:1 ratio nearly every platform's large card layout expects.
• Write og:title and og:description separately from the page's plain title and meta description — social copy can afford to be shorter and punchier without hurting search rankings.
• Set an explicit og:image on every important page, not just the homepage — otherwise different platforms may each guess a different fallback image independently.
• Re-run this check after any content update, and separately force a refresh on Facebook's Sharing Debugger or X's Card Validator if the live platform is still showing a cached version.

Why X Gets Shown Two Ways Instead of One

Every other platform previewed here renders one fixed layout, but X actually supports two genuinely different card shapes controlled by the twitter:card tag itself — summary_large_image, a full-width photo with text underneath, and plain summary, a small square thumbnail sitting beside the text instead. Which one a page gets isn't automatic; it's whatever value that tag declares, which means the choice is a real design decision rather than something X decides on its own per image.

Seeing both laid out side by side before picking a value is more useful than guessing — a strong hero photo or product shot usually reads better as the large card, where it gets room to actually be seen, while a logo, icon, or text-heavy graphic often looks cramped and pixelated blown up to full width and reads more cleanly as the small thumbnail instead.

Why the Discord and Slack Card Looks Different Again

Internal tools read Open Graph data too, just with their own quirks that don't match Facebook or X. Discord pulls an accent color from a page's theme-color meta tag and draws it as a thin bar down the left edge of the embed — a tag most people set for a browser's mobile address bar, never expecting it to double as a share-card color. Slack's unfurl is pickier about image dimensions than either Facebook or X and will sometimes drop the image entirely rather than crop it awkwardly, which is exactly why a link that looks complete on Facebook can still show up as text-only the moment it's pasted into a work channel. Neither behavior means a tag is broken — they're just a second, less-documented set of rules riding on the same handful of meta tags everything else already reads.

What This Won't Catch

This reads the page fresh every time, which is exactly why it won't reproduce a stale cached preview that Facebook or LinkedIn might still be showing from before a fix — for that specific problem, the platform's own debugger tool is what actually clears its cache. It also can't reach anything behind a login wall or sitting on a local network, since that mirrors exactly what a real crawler would be blocked from as well. And like the daily allowance behind our other lookup tools, checking heavily from one shared connection can occasionally hit a free usage limit before resetting the next day. If the image or title looks right here but the page itself still feels slow to load when a platform's crawler fetches it, the HTTP Header Checker shows whether your server is actually caching responses or rebuilding that page from scratch on every hit.