One image size, if you pick it right
For the first year of running this site, my links unfurled on social platforms as a gray rectangle next to a truncated URL. I had spent weeks on the pages themselves and zero minutes on the preview, which is backwards, because the preview is the only part most people ever see. Fixing it turned out to be one image at one size, plus a handful of quirks that each cost me an afternoon to discover.
The good news is that in 2026 the platforms have mostly converged. One well-built 1200x630 image gets you a clean card on Facebook, LinkedIn, Slack, Discord, WhatsApp, and iMessage, and a slightly cropped but acceptable one on X. This post is the exact spec I use, and the traps in delivery order.
The numbers that matter: 1200x630 and 1.91:1
Facebook's own documentation asks for images of at least 1200x630 pixels for the best display on high resolution devices, at an aspect ratio of 1.91:1. The documented minimum for the large-format preview is 600x315. Go below that and your beautiful card collapses into a sad little square thumbnail beside the headline, which reliably looks like an accident.
There is also a file size ceiling of 8MB in the same docs, which sounds generous until you export a full-bleed photo at 1200x630 from a design tool at maximum quality. You will never need anywhere near 8MB, and later in this post I will argue you should stay under a tiny fraction of it.
I generate mine at exactly 1200x630 with the OG image generator, because doing it in a general design tool meant I forgot the dimensions roughly every third time.
Why is there a safe zone, and how big is mine?
Platforms crop. Feed layouts round the corners, some surfaces trim the top and bottom edges, and X in particular can crop a 1.91:1 image toward 2:1 in some placements. Anything critical sitting near an edge will eventually get shaved off on some surface you did not test.
My working rule: keep all text and logos inside a centered box of roughly 1000x524 pixels, which is about 100 pixels of padding on every side of the 1200x630 canvas. That is my convention rather than a published spec, but since adopting it I have not had a single preview ship with a beheaded headline. The background can bleed to the edges. The message cannot.
Text size: design for the phone preview, not your monitor
The mistake I kept making early on was designing the card at full size on a 27-inch monitor, where 30-pixel text looks perfectly readable. Then the card renders 350 to 500 pixels wide inside a chat app on a phone, the whole image shrinks to about a third, and my carefully written subtitle becomes gray noise.
My floor now: the headline sits at 60 to 72 pixels on the 1200x630 canvas, and nothing goes below 40 pixels, ever. One short headline, maybe five to eight words, one small logo, done. If I am tempted to add a second sentence, that sentence belongs in the meta description instead, and I covered how I write those in my meta titles and descriptions post.
Per-platform quirks that each cost me an afternoon
The tags themselves matter as much as the pixels. I set og:image, og:image:width, and og:image:height with the meta tag generator, because declaring the width and height lets Facebook render the card correctly on the very first share instead of showing a blank preview until its crawler catches up. Beyond the tags, here is the field guide I wish someone had handed me.
- X wants 2:1 for the large summary card and may center-crop your 1.91:1 image, so keep the safe zone honest
- LinkedIn caches previews aggressively; when the image will not update, run the URL through LinkedIn's Post Inspector to force a refresh
- WhatsApp shows a small thumbnail and in my testing silently skips images with heavy file sizes, so keep the file light
- Slack, Discord, and iMessage all read the same og tags, which is the argument for getting one image right instead of five
- Facebook's Sharing Debugger shows you exactly what the crawler sees, and it settles arguments faster than guessing
File weight: compress before you ship
The 8MB ceiling is not the target, it is the cliff edge. My personal budget is under 200KB per card, which keeps previews snappy on mobile connections and keeps WhatsApp cooperative. A flat design with text and two or three colors compresses beautifully; a full photo background is where the bytes hide.
My pipeline is short. Export at 1200x630, run it through the image compressor with a target size, and if I need the 2:1 variant for X I cut it with the image resizer rather than letting the platform guess at the crop. PNG for flat graphics with text, JPG for anything photographic. The compressor usually gets my cards to 60 to 120KB without visible damage.
My pre-publish checklist
This whole discipline is now four minutes per page, and it runs before anything ships. The same thinking applies to the other tiny preview surface your site has, the browser tab, and I wrote that one up separately in the favicon size guide.
- Image is exactly 1200x630, text inside the centered 1000x524 zone
- Headline readable when the image is scaled to 350 pixels wide, squint test on my actual phone
- File under 200KB after compression
- og:image is an absolute URL, with og:image:width and og:image:height declared
- Ran once through Facebook's Sharing Debugger and one real share in a private Slack
Questions people ask
1200x630 pixels at a 1.91:1 ratio. Facebook's documentation recommends at least 1200x630 for high resolution displays, and 600x315 is the documented minimum before the preview collapses to a small square thumbnail.
Yes, and I do. One 1200x630 image with text kept away from the edges works everywhere. X may crop toward 2:1 in the large card, which is exactly why the safe zone exists.
Platform caches. Facebook's Sharing Debugger and LinkedIn's Post Inspector both have a re-scrape function. Changing the image filename also works, since a new URL cannot be cached yet.
PNG for flat designs with text and few colors, JPG for photographic backgrounds. Either way compress it: my budget is under 200KB, far below the 8MB cap in Facebook's docs.
They are optional but worth it. Declaring dimensions lets the first share render the full card immediately instead of waiting for the crawler to fetch and measure the image.