Open Graph & Twitter Card Preview

Social previews are the cards that appear when you paste a link into Facebook, X, LinkedIn, Slack, Discord, WhatsApp, or any other platform that turns URLs into rich embeds. Done well, they roughly double the click-through rate compared to a plain link, because the card communicates topic, brand, and visual quality before the user has clicked away. Done poorly — or worse, missing entirely — they leave the platform showing a bare URL string, and the click-through penalty is real and measurable. The cards are driven by Open Graph and Twitter Cards meta tags in the page's HTML, which means a small change in how a few <meta> tags are written can be the difference between a clean card and a broken fallback.

Open Graph itself dates to 2010, when Facebook released the protocol to standardize how external pages described themselves to the social graph. The protocol was deliberately small: og:title, og:description, og:image, og:url, og:type, og:site_name, og:locale. Almost every other platform that does link unfurling adopted the same vocabulary: LinkedIn, Slack, Discord, Pinterest, WhatsApp, Telegram, Microsoft Teams, and even Apple Messages all read OG tags first. Twitter Cards were introduced separately in 2012 with a slightly different vocabulary (twitter:card, twitter:title, twitter:description, twitter:image), and convention since then has been to ship both, with twitter:* taking precedence on Twitter and og:* taking precedence everywhere else. Most authors today maintain a single source of truth and emit both tag families with the same content.

Twitter Cards added card types as a first-class concept. summary_large_image is the default for content pages — it produces a horizontal card with the image on top and the headline below, which is the layout that drives most of the CTR uplift. summary is a smaller card with a square thumbnail, useful when you do not have a large hero image. app and player are specialized types for mobile apps and embedded media; they have specific requirements and validation paths. The preview tool here renders both summary_large_image and summary based on what the page declares, so you can confirm the card type is what you intended. Most authors should default to summary_large_image with a 1200×630 image; that combination works on every platform.

LinkedIn has its own quirks worth knowing. It honors og:* tags but is famously aggressive about caching: if you change a page's OG image after LinkedIn has already crawled it, the new image will not appear in shares for hours or days unless you go to LinkedIn's Post Inspector and manually trigger a re-fetch. This catches authors off guard when they update an article, change the cover image, and find that LinkedIn still shows the old one. The preview tool here always shows the current state of the meta tags, not LinkedIn's cached state, so when something looks wrong on LinkedIn after a content update, the workflow is to confirm here that the new tags are in place, then go to Post Inspector to refresh the LinkedIn cache.

Slack does link unfurling differently from the others. Instead of a fixed card layout, Slack treats the link preview as a sidebar quote with a colored left border, the favicon, the title, the description, and an inline image. The border color comes from theme-color in the page's <meta>, which means you can subtly brand your Slack previews by setting a coherent theme-color across your site. Slack also caches link previews per-team, with no public refresh API, so previews that are wrong stay wrong until the cache TTL expires (about a day). The preview tool here shows the current state of the page; if Slack still shows an old preview, you wait it out.

Discord renders embeds with the most flexibility. It honors og:* tags, twitter:image as a fallback, and uses the page's theme-color for the left sidebar of the embed (the visible band on the left side of the unfurl). Discord also supports oEmbed, which lets you customize the author label and the brand line above the title — most pages do not bother, but for content publishers it is a way to put the author's name into the embed. Discord previews appear instantly and are generally the truest live render of what the meta tags say, which makes Discord a useful debugging surface even if your audience is not on Discord. Paste a link into a private channel after deploying to confirm the OG looks right; if it looks right on Discord, it almost certainly looks right elsewhere.

The image is where most preview problems originate. The recommended dimensions are 1200×630 for og:image (about 1.91:1 aspect ratio), under 8 MB, in JPEG or PNG. Smaller images (less than 200×200) are downgraded to a small thumbnail by Twitter and may be dropped entirely by Facebook. Images served behind authentication or hot-link protection are blocked by every platform. Relative URLs in og:image are a frequent bug — they need to be absolute, including the protocol — and the tool here flags them by attempting to resolve relative URLs against the page's canonical URL during fetch. Animated GIFs render as a still frame; for actual motion, you need a video unfurl which has different protocol requirements (og:video plus og:video:type plus og:video:width/height).

Caching strategies on each platform differ enough to be worth a paragraph. Facebook caches OG data for several days; you can force a refresh through the Facebook Sharing Debugger (developers.facebook.com/tools/debug/). Twitter caches for a similar duration; the Twitter Card Validator was deprecated, so the only way to refresh is to wait or to add a meaningless query parameter to the URL to make it a different cache key. LinkedIn's Post Inspector is the only refresh tool; without it, edits do not propagate. Slack and Discord cache per-channel and have no refresh tool. The pragmatic implication: get the OG right before you share the link the first time. The preview tool here is faster than the platform debuggers and does not require a developer account, so it is the right place to verify before posting.

On the technical side, this tool fetches the page server-side rather than client-side. There is a reason: most production CMS-rendered pages set a Content-Security-Policy that blocks fetch from arbitrary origins, and many sites set X-Frame-Options or X-Content-Type-Options that break a client-side fetch in a browser. Server-side fetch is also necessary because the og:* tags often live in the initial HTML, before any JavaScript renders, which means a browser-based fetch sometimes misses them on JS-heavy sites. The server-side fetcher used here implements SSRF protection (it refuses to fetch internal IPs, link-local addresses, and non-HTTP ports) and a 1.5 MB body limit (most pages are well under), so the tool cannot be turned into an internal-network reconnaissance device.

Privacy and rate limits are worth mentioning. The page you preview here is fetched by Omnvert's server, not by your browser, which means we see one outbound request per preview. Logs include the URL but not the page contents — they are kept for a short time for abuse detection and then rotated. The IP-based rate limiter caps each client to thirty previews per minute, which is high enough for normal interactive use and low enough to discourage scripted abuse. If you need bulk preview for hundreds of pages (for example, an SEO audit of a sitemap), the right tool is a scripted scraper with your own server, not this preview UI.

The differentiator versus other social preview tools is that you can see all five major platforms — Facebook, X, LinkedIn, Slack, Discord — in one screen with one fetch. Standalone previewers like metatags.io, opengraph.xyz and others do excellent work for one or two platforms each, but you pay the latency cost of a separate fetch for every tool you open. For a real publishing workflow — write a post, set the OG, verify before publishing — checking all platforms on a single page makes it cheap enough to do every time, and that is the difference between consistently-correct previews and the occasional embarrassing fallback when a CMS template change broke the OG image without anyone noticing.

A few practical patterns. First, set a single OG image as the source of truth for a page and reuse it for both og:image and twitter:image; do not maintain two separate images that can drift. Second, keep og:title under about 60 characters — Twitter truncates around 70, Facebook around 88, but the harshest layouts on LinkedIn and small Slack instances start truncating at 60. Third, write og:description as a self-contained sentence that makes sense without the title — when the title gets truncated, the description has to carry the meaning. Fourth, set a brand color in <meta name="theme-color"> consistently across your site — Slack and Discord both use it for visible accents and it makes your previews look more polished without any per-page work.

This tool pairs naturally with the other Omnvert SEO and developer utilities. The Schema.org JSON-LD Builder covers the related but different problem of structured data for search engines — JSON-LD targets Google and friends, OG and Twitter cards target social. Most production pages need both done correctly. The User Agent Parser is useful when you want to verify which crawler version a platform is sending: FacebookExternalHit, Twitterbot, LinkedInBot, Slackbot, Discordbot all identify themselves clearly. The JSON Viewer helps when you want to inspect the raw meta-tag dump as a tree. And the Hash Generator covers the adjacent need of producing stable cache-buster query parameters when you absolutely have to force a refresh.