[{"data":1,"prerenderedAt":11},["ShallowReactive",2],{"guide:en:blog\u002F1200x627-vs-1200x628-link-preview-image":-1,"article-en-1200x627-vs-1200x628-link-preview-image":3},{"slug":4,"title":5,"description":6,"date":7,"keyword":8,"tool":9,"html":10},"1200x627-vs-1200x628-link-preview-image","1200 x 628 vs 1200 x 627: Which Size Is Right?","Facebook says 1200x630, LinkedIn says 1200x627, other guides say 1200x628. Here is what the 1.91:1 ratio means and how to make one image that works everywhere.","2026-10-05","1200 x 628","resize-image","\u003Cp>If you've ever tried to make a link preview image, you've probably hit this: one guide says 1200 x 628, another says 1200 x 627, Facebook's own docs say 1200 x 630, and your design template is set to something else entirely. All four look identical. So which one is actually correct?\u003C\u002Fp>\n\u003Cp>Short answer: all of them are fine. They're all approximations of the same aspect ratio, and the difference between them is three pixels on a 630-pixel-tall image — roughly half of one percent. But it's worth understanding where the numbers come from, because knowing that saves you from re-exporting the same banner five times.\u003C\u002Fp>\n\u003Ch2>They're all trying to hit 1.91:1\u003C\u002Fh2>\n\u003Cp>The Open Graph protocol — the set of meta tags Facebook, LinkedIn, Slack, iMessage and most other platforms read to build a link preview — recommends an image with a \u003Cstrong>1.91:1\u003C\u002Fstrong> aspect ratio. That's it. 1.91 is already a rounded number, so when different companies multiply it out, they land in slightly different places:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>1200 ÷ 1.91 = 628.27 → rounds to \u003Cstrong>1200 x 628\u003C\u002Fstrong>\u003C\u002Fli>\n\u003Cli>1200 x 630 = exactly 1.905:1 → Facebook's documented recommendation\u003C\u002Fli>\n\u003Cli>1200 x 627 = 1.914:1 → LinkedIn's long-standing published size\u003C\u002Fli>\n\u003Cli>1200 x 625 = exactly 1.92:1 → shows up in older templates\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>None of these is "wrong." They're rounding artifacts of the same spec. Crawlers don't reject an image for being three pixels off; they just need the file to be at least 200 x 200 and ideally 1200px wide so it renders sharp on high-density screens.\u003C\u002Fp>\n\u003Ch2>Does the 3-pixel difference ever matter?\u003C\u002Fh2>\n\u003Cp>In practice, only in one situation: tight crops. Platforms don't display your image at its native size — they fit it into whatever card layout they use that month, and the edges get trimmed. If your headline text runs right up to the top of the frame, a 1200 x 628 image cropped to a 1.78:1 card will clip it, and so would 1200 x 630.\u003C\u002Fp>\n\u003Cp>The fix isn't picking the "correct" pixel count. It's leaving a safe margin: keep logos and text inside the middle ~90% of the canvas and nothing important within 60px of any edge. Then it genuinely doesn't matter which of the three sizes you export.\u003C\u002Fp>\n\u003Ch2>How to make one image that works everywhere\u003C\u002Fh2>\n\u003Cp>My recommendation: build at \u003Cstrong>1200 x 630\u003C\u002Fstrong>. It's Facebook's documented size, it's within a hair of 1.91:1, and it's an even number, which avoids odd half-pixel rendering in some editors. Then reuse that same file for LinkedIn, Slack, Discord and Open Graph tags generally.\u003C\u002Fp>\n\u003Cp>If you already have an image at the wrong dimensions, here's the quick way to fix it without installing anything:\u003C\u002Fp>\n\u003Col>\n\u003Cli>Open the \u003Ca href=\"\u002Fcrop-image\">crop tool\u003C\u002Fa> and crop your source photo to roughly a 1.91:1 shape first. This is the step people skip — if you jump straight to resizing, a 4:3 photo gets squashed and faces look subtly wrong.\u003C\u002Fli>\n\u003Cli>Take the cropped file into the \u003Ca href=\"\u002Fresize-image\">resize tool\u003C\u002Fa> and set it to 1200 x 630 (or 628, or 627 — pick one and move on).\u003C\u002Fli>\n\u003Cli>Export as JPG for photos, PNG only if you need crisp text or transparency behind a logo. The \u003Ca href=\"\u002Fconvert-image\">image converter\u003C\u002Fa> handles that switch if your source is a PNG, WebP or HEIC.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Everything happens inside your browser on cutbg — the file never leaves your computer, there's no upload queue and no account. That matters more than people realize for unreleased product shots or client work you haven't announced yet.\u003C\u002Fp>\n\u003Ch2>Watch the file size too\u003C\u002Fh2>\n\u003Cp>Platforms have upload and fetch limits — Facebook caps Open Graph images at 8MB, and some crawlers quietly give up on anything slow to download. A 1200 x 630 JPG should comfortably land between 100KB and 300KB. If your export is a multi-megabyte PNG, run it through the \u003Ca href=\"\u002Fcompress-image\">compressor\u003C\u002Fa> first. Smaller files also mean the preview actually appears instead of showing a blank card while the crawler times out.\u003C\u002Fp>\n\u003Ch2>If the preview still shows the old image\u003C\u002Fh2>\n\u003Cp>This is almost never a sizing problem. Facebook, LinkedIn and Twitter cache scraped previews aggressively. After replacing the file, run the URL through the platform's own debugger (Facebook's Sharing Debugger, LinkedIn's Post Inspector) to force a re-scrape. Changing your image from 1200 x 627 to 1200 x 628 will not fix a cached preview — only clearing the cache will.\u003C\u002Fp>\n\u003Cp>So: stop agonizing over the last pixel. Pick 1200 x 630, keep your text away from the edges, keep the file under a few hundred KB, and you're covered on every platform that reads Open Graph tags.\u003C\u002Fp>\n",1791831495339]