Every six months somebody announces that link previews are dead, and every six months link previews quietly drive another wave of traffic to whoever has their dimensions dialed in. In 2026, the platforms that consume your og:image have grown teeth: iOS 19 silently downgrades cards that miss the aspect ratio band, LinkedIn caches a broken render for seven full days, and Slack now scales your card down to a 360-pixel thumbnail that demands its own design rules.
This is the practical reference. One canonical card that survives every platform that still matters, the safe zone every cropper respects, the file-size ceilings nobody publishes, and the new failure modes that did not exist in the old "use 1200×630 and ship it" advice.
Ship one image at 1200×630 px, under 300 KB, with everything important inside a 1080×540 centered safe zone. Reference it absolutely fromog:image, declare width and height tags, settwitter:cardtosummary_large_image, and you survive every cropper in the wild today.
That single card will render correctly in feeds on X, LinkedIn, Facebook, WhatsApp, iMessage, Discord, Slack, Microsoft Teams, Notion, Google Discover, and the Threads embed. The rest of this article is the why, the gotchas that have changed in 2026, and the few cases where you genuinely do need a second image.
Of all the dimensions that have churned in the last five years, 1200×630 has not. It is what Facebook seeded the Open Graph protocol with in 2010, what X switched to when they killed legacy summary cards, and what every modern preview pipeline (LinkedIn Post Inspector, the Slack unfurl service, iMessage Link Preview) measures itself against.
The 1.91:1 aspect ratio is what makes it work. It is wide enough that landscape photography looks intentional and square enough that headlines do not get cropped to nonsense at thumbnail size. It is also the exact ratio Google Discover crops to before serving on mobile, which means Discover thumbnails get to use the full image rather than a center-cropped letterbox.
| Spec | Value | Reason |
|---|---|---|
| Width | 1200 px | Sharp on retina; not so big that file size balloons. |
| Height | 630 px | Locks the 1.91:1 ratio every platform expects. |
| Aspect ratio | 1.91:1 | Inside the iOS 19 acceptable band of 1.5:1 to 2.0:1. |
| File format | PNG or JPG | WebP works on most platforms but still fails in older email clients. |
| File size | < 300 KB target, 1 MB hard cap | Slack and Discord throttle large fetches; iOS 19 drops > 5 MB silently. |
| Color space | sRGB | P3 photos look oversaturated on Android; sRGB renders identically everywhere. |
The thing nobody warns you about is that almost every preview service crops your image at least slightly. The amount differs — LinkedIn is forgiving, Slack is brutal — but if you keep all your important content inside a centered 1080×540 rectangle, you survive every crop in the wild today.
Practical translation: if you are designing in Figma, drop a 1080×540 frame in the center of a 1200×630 frame and treat the gap as a margin you cannot cross. Logos, wordmarks, headlines, and the crucial third of any product screenshot all live inside the safe zone. Decorative gradients, abstract shapes, and patterns can extend to the edges — the cropper takes them away on small platforms but their absence does not break the card.
Two specific rules that catch teams every time:
X requires twitter:card to be explicitly set as of late 2025. Without it, your card renders as the giant gray placeholder, not summary_large_image. The image is fetched at 1200×630 and displayed at 600×314 in the home timeline, with no further crop. Both PNG and JPG work; animated GIFs render as static first-frame thumbnails.
LinkedIn renders the canonical card at 552×289 in feed and uses the full 1200×630 in expanded post view. The big change in 2026 is the seven-day cache: once LinkedIn fetches a broken card, every subsequent share for a week shows the broken render. Run the URL through Post Inspector and click Re-Scrape before you announce, never after. There is no second chance for a launch tweet.
Both run on Meta's shared scraping infrastructure (the facebookexternalhit/1.1 user agent). The Sharing Debugger's "Scrape Again" button refreshes both at once. The most common failure here is a CDN with bot fight mode on, which silently 403s the scraper and produces an "og:image could not be downloaded" error. Allowlist facebookexternalhit at the edge.
Slack scales 1200×630 down to roughly 360×189 in the desktop unfurl, which is where the headline-readability test bites hardest. The unfurl service caches per-channel and respects Cache-Control headers; if you ship a fix, the unfurl in the channel you tested in may take up to 24 hours to refresh. Workspace-level admins have no purge button. The workaround is to test in a private channel, not the announce channel.
iOS 19 introduced silent OG image downgrades. If your card fails any of the following checks, the message renders as a plain blue link bubble with zero error reporting:
The only test for this is a real iMessage send. There is no public validator. Send the URL from your Mac to your phone before any launch.
Discord respects 1200×630 but renders embeds at a fixed 400×210 in most channels. The image is cropped from the center, so off-center compositions get clipped. Discord also fetches once per URL per server and caches for ~24 hours, so test on a personal server before sharing in your community.
Discover crops to 1.91:1 on Android and 1:1 on iOS for the carousel format. The 1080×540 safe zone covers both. To stay eligible for Discover at all, the same image URL must be referenced in your Article JSON-LD's image field. Missing JSON-LD silently disqualifies you from Discover thumbnails even if the OG tags are perfect.
One canonical card covers ~95% of cases. The remaining 5% is worth knowing about so you do not get surprised.
X DMs on mobile use the legacy summary card layout, which is 240×240 square. If a meaningful portion of your traffic comes from people sharing your link in DMs (often the case for B2B SaaS in early traction), specifying a separate twitter:image:src at 1024×1024 with the wordmark dead-center is worth the extra 30 minutes.
Pinterest does not respect the 1.91:1 OG image and instead pulls a 600×900 vertical preview from the page body. If Pinterest is a meaningful traffic channel, embed a 1000×1500 vertical image somewhere in the article body and Pinterest will use that.
Slack and Discord both render APNG and animated WebP. Email clients and X do not. If you ship an animated card, also ship a static fallback as og:image and reference the animated version as a separate og:video tag — that path renders animated where supported and still gives you a clean static preview everywhere else.
Here is the smallest snippet that satisfies every modern preview service. Anything more is decoration; anything less leaves CTR on the table.
<meta property="og:title" content="Your post title in 60 chars or fewer">
<meta property="og:description" content="Your one-line summary in 155 chars or fewer.">
<meta property="og:image" content="https://example.com/post-card.png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="One descriptive sentence about the card.">
<meta property="og:url" content="https://example.com/your-post/">
<meta property="og:type" content="article">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:image" content="https://example.com/post-card.png">The explicit width and height tags are technically optional in the OG protocol. They are functionally required in 2026 because Slack uses them to avoid layout shift on mobile and Google's structured data testing tool flags pages that omit them.
Every preview service has a fetch timeout and a maximum allowed payload. Most documentation hand-waves these; actual measured limits as of 2026:
| Service | Soft limit | Hard limit | Failure mode |
|---|---|---|---|
| iMessage (iOS 19) | 1 MB | 5 MB | Silent downgrade to plain link |
| Slack | 2 MB | 10 MB | Truncated fetch, broken render |
| Discord | 1 MB | 8 MB | Embed without image |
| X | 5 MB | 5 MB | Generic placeholder card |
| 5 MB | 5 MB | Re-scrape required, cached for 7 days | |
| Google Discover | 1 MB | 5 MB | Silent omission from carousel |
The right target is well under 300 KB. A clean 1200×630 PNG with two colors, one logo, and a headline runs about 40–80 KB after Squoosh at quality 75. JPGs of complex photography land at 150–250 KB. If you are over 500 KB you have either an oversize image or a CMS that is not optimizing on save — either is worth fixing today.
Our free OG Image Generator outputs a PNG that hits every spec on this page: 1200×630, sRGB, under 300 KB, with the safe zone respected. No signup, no watermark, no upload to a third-party server.
Try it free →The most expensive bug in OG dimensions is shipping a card that renders perfectly in the one place you tested, breaks silently in three places you did not, and you find out two weeks later when a customer screenshots a broken iMessage to your support inbox. The industry-default validators (Twitter Card Validator, LinkedIn Post Inspector, Facebook Sharing Debugger) cover three of the renderers; they do not cover Slack, iMessage, Discord, or WhatsApp.
The minimum testing matrix in 2026 is five places, in this order, before any launch:
Eight to twelve minutes once you have done it a few times. Cheaper than a broken launch announcement.
While we are talking dimensions, three more pieces of the social-card stack that we get questions about:
If you remember nothing else from this article:
og:image:width, og:image:height, and twitter:card explicitly. Optional in spec, required in practice.Do those five things and you have stopped leaving CTR on the table for the cost of one well-designed image.
The TinyTools OG Image Generator outputs a 1200×630 PNG with the safe zone enforced, file size under 300 KB, and sRGB color. Validator-ready by default.
Generate a card →