Open Graph Preview
See how a page's title, description and image will appear when shared on X, Facebook, LinkedIn and Discord — either by fetching a live URL's tags or entering them manually to design a card before you publish.
Enter a URL to fetch its live Open Graph and Twitter Card tags, or switch to manual mode to type a title, description and image URL directly and preview how the resulting share card would look on each platform.
Source
Fetches that page's <head> server-side to read its Open Graph / Twitter Card tags — the same thing any social platform's crawler does. Only the URL you enter is sent; nothing else.
Learn more
What the Open Graph protocol is
The Open Graph protocol is a simple HTML meta-tag standard, originally created by Facebook in 2010, that lets any web page describe itself as a rich object in a social network. Without it, a URL shared on a platform is just a string — the platform has no structured way to know what the page is called, what it's about, or what image represents it, so it falls back to scraping heuristics: the first heading it finds, the first large image, whatever text it can extract. Those guesses are often wrong, which is why a link shared without OG tags renders as a bare URL or an unflattering card with a random cropped image.
The protocol works by adding <meta> tags in the page's <head> with a property attribute beginning og: — og:title, og:description, og:image, og:url — each with a content attribute holding the value. When a platform's crawler fetches the page, it reads those tags and renders a preview card: title, description, image, site name. The same markup is understood by Facebook, LinkedIn, X (via fallback or its own Twitter Card tags), Discord, Slack, WhatsApp and most chat platforms, which is why a single set of tags controls how your links appear across the social web.
How social platforms actually use OG tags
When you paste a URL into a share box, the platform's crawler (Facebook's is called Facebook External Hit, LinkedIn's is LinkedInBot, X's is Twitterbot) fetches the page, parses the meta tags and renders a link preview from them. The crawler doesn't execute JavaScript — it reads the raw HTML response — so OG tags must be in the server-rendered markup, not injected client-side by a script after hydration. This is the single most common reason rich previews fail on client-rendered frameworks: a crawler that fetches the page before React or Vue runs sees an empty <head>.
Each platform caches the result, sometimes aggressively. Facebook caches for roughly 24 hours but respects cache headers; LinkedIn and X cache for about seven days and offer no official purge endpoint, which means a mistaken image or typo'd title can keep showing on shared links for up to a week even after you fix the tags. Preview tools that fetch the live tags exist partly to show you exactly what the cached crawler sees — the raw parsed values, not your intentions.
Required vs. optional OG properties
The four properties that make a functional card are og:title, og:type, og:image and og:url. Of these, og:title and og:image are the de facto minimum every platform expects: without an image, most platforms render a text-only card that gets a fraction of the engagement. og:type (website, article, video.other, etc.) defaults to website when omitted and mainly affects how the object is categorized in Facebook's graph; og:url canonicalizes the shared URL so likes and shares resolve to one canonical address instead of every query-string variant.
A second tier of properties meaningfully improves the card: og:description (the two-to-three-line subtitle — most platforms truncate at roughly 200 characters, and LinkedIn truncates much earlier), og:site_name (the brand shown under the title), og:locale and og:locale:alternate (for multilingual pages), and og:image:width / og:image:height, which let the crawler lay out the card before the image finishes downloading and prevent the layout shift where a broken preview snaps into place. Optional but useful: og:audio and og:video for media objects, and article:published_time / article:modified_time for publishers, which power the "posted 3 hours ago" timestamp on article cards.
OG image best practices
The safe standard image is 1200×630 pixels (a 1.91:1 ratio), which Facebook calls the minimum for a high-quality, full-width card and which LinkedIn, X and Discord all handle well. Smaller images are accepted but get upscaled and blurry on high-DPI displays; Facebook explicitly rejects images below 600×315 and will fall back to the largest image it can find on the page instead — frequently the wrong one. At the other extreme, files above 8MB are rejected, so compress aggressively: a JPEG at quality 80 or a WebP of the same image is typically 100–200KB and visually identical.
Composition matters as much as dimensions. Platforms crop differently: Facebook displays the full 1.91:1 in feed but crops to a tighter 1:1 square in some surfaces, X's in-stream preview is close to 1.91:1 but its summary card crops to 2:1, and LinkedIn applies its own ratios. Keep critical content — logos, faces, text — centered and away from the edges, because every platform's crop is a different bet about where the subject is. Text rendered on the image itself should be large: at 1200×630, anything under roughly 40px tall is unreadable on a phone. And the image must be publicly reachable by a crawler — no authentication, no robots.txt disallow, no redirect chains, no hotlink protection that returns an error page to unknown user agents.
Testing, debugging, and how platforms differ
Every major platform provides a debugging tool, and they're the fastest way to see what the crawler actually cached: Facebook's Sharing Debugger (developers.facebook.com/tools/debug), LinkedIn's Post Inspector, X's Card Validator. These tools re-scrape the page, show the exact tags they parsed, surface warnings (missing properties, image too small, failed fetches) and — on Facebook — let you force a cache refresh, which is the only way to fix a bad preview without waiting out the cache. Always debug with the tool rather than eyeballing your own share, because your browser shows the live page, not the cached snapshot the crawler saw.
OG is not the only card standard in play. Twitter/X ignores most og: tags when its own twitter: card tags are present — twitter:card (summary, summary_large_image, app, player), twitter:title, twitter:description, twitter:image — which is how a page shows a bigger image on X than on Facebook from the same markup. Search engines are the other consumer: Google uses og:title and og:image as signals when generating sitelinks search boxes and can use og: tags as a fallback for its own structured data, while Bing reads og: tags more directly. The pragmatic pattern is: set the four core og: properties, add the twitter: variants only where you want a deliberately different X card, and set og:image:width and height everywhere — a few tags cover every consumer.
Frequently asked questions
How does fetching a URL's tags work without uploading my data?
Fetching a public URL's meta tags requires a server-side request (the same way any social platform's crawler works) — only the URL you type is sent, never any of your own data. Manual mode needs no network request at all.
Why do og:title and twitter:title sometimes differ?
Twitter/X can use its own twitter:title, twitter:description and twitter:image tags instead of falling back to the Open Graph og: equivalents, so a page can intentionally show slightly different copy on X than on Facebook or LinkedIn.
What image size should I use?
1200×630px is the safe standard most platforms expect for a full-size preview image, matching a roughly 1.91:1 aspect ratio.