Social Media Preview Generator: Getting Every Platform's Card Right

A social media preview generator's real job isn't producing one nice-looking image — it's producing an image and metadata set that survives contact with a dozen different crawlers, each of which reads your tags, crops your image, and lays out its card slightly differently. What looks perfect in a Facebook debugger can crop awkwardly in Slack. What renders as a large image card on X can fall back to a tiny thumbnail if one tag is missing. This post goes platform by platform.

Facebook

Facebook is the platform the og:image standard was effectively built around, and it's the most forgiving of the major crawlers — it reads standard Open Graph tags directly, shows the full 1200×630px card without aggressive cropping, and its Sharing Debugger tool makes it straightforward to see exactly what it parsed. The main way Facebook trips people up isn't the image, it's caching: Facebook caches a URL's metadata the first time anyone shares it, and won't re-fetch on its own just because you changed the page. You have to force a re-scrape through its debugger for updates to show.

X (formerly Twitter)

X requires its own meta tag family layered on top of Open Graph — specifically twitter:card set to summary_large_image if you want the big image treatment. Without that tag explicitly set, X will often fall back to a small square thumbnail pulled from whatever og:image is available, which looks noticeably worse in a feed. X is also stricter about needing twitter:title and twitter:description present even when og:title and og:description already exist; some accounts see inconsistent fallback behavior when only the Open Graph tags are set.

LinkedIn

LinkedIn is one of the pickier crawlers about image reachability. It wants an absolute, publicly accessible URL and tends to fail unfurling entirely — no image, sometimes no card at all — if the image is behind authentication, served with restrictive CORS headers, or referenced by a relative path. LinkedIn also caches aggressively and, unlike Facebook, doesn't offer as reliable a self-serve tool to force a refresh, which means a wrong image on a LinkedIn share can persist for longer before it's fixable.

Slack

Slack unfurls og:image inside a compact card format and tends to crop tighter around the center than Facebook does, so a template designed with generous edge margins for Facebook can lose more of its frame in a Slack message. Slack also unfurls in-house tools and internal links, which matters for teams sharing product URLs internally — a broken preview in Slack is often the first place a metadata bug actually gets noticed, since it's shared constantly during day-to-day work.

Discord

Discord's embed format is close to Slack's in how it reads Open Graph tags, but it typically renders the image slightly larger in the card, and 1200×630px holds up well there without much adjustment. Discord embeds are also more visible per message than most platforms — the card sits directly under the link with no truncation — so text legibility at that size matters more than it might on a platform with a smaller thumbnail.

iMessage and other native previews

iMessage and similar native link previews on mobile operating systems tend to crop toward a square or near-square aspect ratio rather than the wide 1.91:1 that most web platforms use, and they're less forgiving of small text since the whole card renders at a smaller physical size on a phone screen. If your audience shares links via text message significantly, it's worth checking how your standard template looks cropped to something closer to 1:1 rather than assuming the same 1200×630px design translates cleanly.

• Set both Open Graph and Twitter Card tags — don't assume og:* alone covers X
• Design with generous safe margins; Slack and mobile crop tighter than Facebook
• Always use absolute URLs for images — LinkedIn fails silently on relative paths
• Test the same link in Facebook's debugger and at least one other platform before considering it verified

How to actually test across platforms without an account on every one

The obvious way to verify a preview works everywhere is to have accounts on every platform and manually share the link to see what renders. That's slow and doesn't scale past the first couple of checks, especially since some platforms — LinkedIn in particular — don't offer a lightweight self-serve way to inspect an unfurl without actually posting. A faster approach is to rely on debugging tools that show what a crawler would parse without requiring an actual post: Facebook's Sharing Debugger is the most complete of these and is often used as a rough proxy for how other platforms will behave, since a lot of unfurling logic (reading Open Graph tags, respecting declared image dimensions) is broadly similar across crawlers even when the final card layout differs.

That said, treating any single debugger as fully representative is a mistake worth avoiding. Two platforms can read the exact same og:image and og:title and still produce visibly different cards — different crop, different text truncation length, different fallback behavior when a tag is missing. If a specific platform matters a lot to your audience — Slack for an internal tool, LinkedIn for a B2B product, Discord for a community product — it's worth checking that platform specifically at least once per major template change, rather than assuming a Facebook-only check covers it.

Why one template rarely means one identical result

The practical implication of all this is that a single 1200×630px image with the right tags will look correct on most platforms most of the time, but "correct everywhere" requires designing for the tightest crop and the smallest reliable text size, not the most generous one. Treating Facebook's rendering as the baseline and assuming every other platform matches it is the most common mistake — Facebook is usually the most forgiving crawler in the group, not a representative one.

When it's worth designing separate images per platform

For most sites, one well-designed 1200×630px image with generous safe margins is a reasonable compromise across every platform, and building separate variants per platform is more engineering effort than the marginal improvement usually justifies. There's a point where that calculation flips, though: high-volume, high-value content where a few percentage points of click-through translate into real revenue or reach. A media company's flagship articles, or a marketplace's top-converting listing template, can be worth the extra effort of serving a slightly different crop or layout to X versus LinkedIn versus Slack, detected server-side by user agent, rather than relying on one image to serve every crawler adequately. For most other content, that complexity isn't worth carrying.

If you do go down this path, keep the variation limited to crop and layout rather than message — the headline and core visual identity should stay consistent across platforms even if the framing changes, so the content still reads as the same piece regardless of where it's shared from. Wildly different creative per platform tends to create more maintenance burden than it's worth, and makes it harder to reason about which version underperformed when something needs fixing.

How useopengraph handles the platform variance

useopengraph's templates render at 1200×630px with the safe-area conventions that hold up across Facebook, X, LinkedIn, Slack, and Discord's differing crop behavior, and the platform's Cache Debugger lets you check what Facebook, Twitter, LinkedIn, and other crawlers would actually parse right now — bypassing each platform's own cache — before you're relying on a live share to find out. Instead of testing one platform and hoping the rest follow, you can verify the same URL's preview across the platforms your audience actually uses.