Social Media Image Dimensions Cheat Sheet (Every Platform, One Page)

This is a reference, not a narrative — a social media image dimensions cheat sheet you can scan for the exact number you need without reading through an explanation of why each platform picked its own defaults. It covers link preview cards specifically: the image that shows up when a URL is pasted or shared, not native post images or profile assets. If you need the reasoning behind these numbers, that's covered elsewhere; this page is built to be scanned.

Link preview image dimensions by platform

• Facebook: 1200×630px (1.91:1) — minimum acceptable roughly 600×315px before visible upscaling blur
• X (Twitter) summary_large_image: 1200×630px — requires twitter:card meta tag explicitly set, image alone isn't enough
• LinkedIn: 1200×630px — stricter about requiring an absolute, publicly reachable image URL than most other platforms
• Slack: 1200×630px — crops more tightly into a compact card than Facebook, keep text near center
• Discord: 1200×630px — renders slightly larger than Slack's card but follows the same aspect ratio
• iMessage: uses og:image the same as other platforms, generally forgiving on exact dimensions within the standard ratio
• Square fallback (used by some messaging apps and older unfurlers): 1200×1200px, 1:1

File size and format limits

• Most crawlers accept up to 5-8MB, but staying well under that avoids fetch timeouts on slower connections
• PNG: safest default for images with text, logos, or sharp edges — avoids compression artifacts
• JPEG: fine and usually smaller for photographic backgrounds without fine text detail
• WebP: broadly supported by modern crawlers, but not universally — PNG/JPEG remains the safer choice for maximum compatibility

Text length limits for accompanying tags

• og:title: roughly 60 characters before truncation risk on most platforms
• og:description: roughly 110-120 characters for platforms rendering it inline on the card
• Meta description (search snippet, separate from og:description): roughly 150-160 characters before Google truncates

Safe area guidance

Different platforms crop the same source image differently — some show the full 1.91:1 frame, others shave pixels from the edges for card chrome, and mobile rendering can inset further than desktop. Treat the outer 5-8% of the canvas as a margin with nothing critical in it. Headlines, logos, and any small text should sit comfortably inside the center two-thirds of the frame. A logo placed flush in a corner is the most common casualty of aggressive platform cropping.

Common mistakes that break the numbers above

• Using a source image at a different aspect ratio than the target and letting the platform crop it unpredictably rather than exporting at the correct ratio directly
• Uploading an undersized image that gets upscaled and looks soft, even though it's technically 'accepted' by the platform
• Setting twitter:card to summary instead of summary_large_image, which produces a small thumbnail regardless of the image's actual dimensions
• Using a relative image URL instead of an absolute one, which several crawlers (LinkedIn especially) fail to fetch reliably
• Placing a logo or headline near the edge of the canvas where different platforms crop it out inconsistently

Why these numbers differ from native post image sizes

It's worth being explicit that this sheet covers link preview cards specifically — the image a platform pulls from og:image when a URL is shared — and not the dimensions for images uploaded directly as native posts, cover photos, or profile assets. Those are separate specs with their own sizing conventions that vary more frequently and by more platform-specific detail, because native post images are handled by each platform's own upload pipeline rather than a shared open standard. Confusing the two is a common source of wasted effort: resizing a link preview image to match a native post spec (or the reverse) solves a problem that doesn't exist for the tag actually in use. If you're troubleshooting a shared-link preview, the numbers on this page apply; if you're troubleshooting how an image looks when uploaded directly into a platform's own post composer, they don't.

How this cheat sheet relates to meta tag length

Image dimensions and text length limits are governed by different parts of a page's markup — og:image is one tag, og:title and og:description are separate ones, and a meta description tag (used for search snippets) is separate again from og:description, even though platforms sometimes fall back from one to the other when a specific tag is missing. Getting the image dimensions right doesn't automatically mean the accompanying text is within limits, and vice versa — a correctly sized image paired with a 300-character og:description will still render with truncated, awkward-looking text on most platforms. Treat both halves as requiring their own check, not one combined pass.

How to verify the numbers actually apply to your live pages

A cheat sheet tells you the target; it doesn't tell you whether your site currently hits it. The only reliable way to confirm a specific URL's og:image is being served at the right size and rendering correctly on a given platform is to check what that platform's crawler is actually parsing right now, since browser previews and social clients sometimes render from a locally cached version rather than the live tag values. Checking the live crawl output — not just the source file on disk — is the difference between assuming dimensions are correct and confirming they are.

What tends to go stale on this kind of reference page

Any cheat sheet like this one is only as useful as its least outdated line, and the parts most likely to shift over time aren't the pixel dimensions but the surrounding details — file size ceilings that loosen as platforms upgrade their infrastructure, format support (WebP acceptance in particular) that broadens gradually, and individual platform quirks like LinkedIn's strictness about absolute URLs, which is a current-state observation rather than a permanent spec guarantee. Treat the pixel dimensions on this page as the stable core and treat the file-size and format guidance as the part worth periodically re-confirming against a live test, since that's where platforms actually tend to make incremental changes.

Applying one set of dimensions across many pages

The numbers above are simple in isolation but easy to lose track of once a site has more than a handful of pages generating their own images — a blog with dozens of contributors, a product catalog with hundreds of listings, a marketplace with user-generated content. Re-verifying the correct canvas size and safe margins by hand for every new page isn't realistic at that scale, and it's exactly the kind of repetitive, rule-based task that drifts the moment it depends on someone remembering to check a cheat sheet before every export.

How useopengraph applies this cheat sheet automatically

useopengraph bakes the 1200×630px canvas, safe-area margins, and platform-appropriate file compression into the template itself, so every page rendered from that template comes out matching the numbers on this page by default — no one needs to re-check dimensions per export because the dimensions aren't a per-export decision anymore. Renders are served from versioned URLs under /api/render/{templateId}/v{version}/..., so a correction to canvas size or safe margins applied to the template rolls forward to future renders without needing to touch pages that already shipped. And the Cache Debugger lets you confirm, per URL, exactly what a given platform's crawler is currently parsing, closing the gap between what the cheat sheet says should happen and what's actually live.