1200×630 pixels. 1.91:1 ratio. That's the answer. If you set your og:image to those dimensions, every major platform — Facebook, LinkedIn, Slack, Discord, iMessage — will render it without cropping, letterboxing, or any of the other indignities that happen when you guess.
That's the short version. The rest of this is the stuff that trips people up after they get the dimensions right: the safe zone, the file size ceiling, the width/height attributes you should always set, and why thin fonts are a liability after JPEG compression has its way with your carefully designed card.
If you're still fuzzy on what og:image is and where it fits in the broader Open Graph setup, Open Graph tags explained is the right starting point. And for the full meta-tag picture — title, description, canonical, the works — meta tags for SEO and social has you covered.
Why 1.91:1? Where does that come from?
The Open Graph protocol (the spec that Facebook published in 2010 and every major platform now follows) specifies a 1.91:1 aspect ratio as the standard for og:image. Not a suggestion — it's baked into the spec.
1200×630 is the canonical implementation of that ratio. It's high enough resolution to look crisp on retina displays, wide enough to fill the card layout most platforms use, and it's been stable for long enough that it's become the industry default regardless of what any one platform does internally.
Here's the minimum the spec recommends: 600×315 px. You can get away with smaller images, but you'll see degraded quality on larger screens and some platforms will simply refuse to show the image at all. 1200×630 is the safe upper end that covers everything without generating absurdly heavy files.
So: the spec says 1.91:1, 1200×630 is the practical implementation, and you should stop second-guessing it.
The safe zone nobody mentions
This is the part most image-size guides skip, and it's the part that bites you in production.
Most platforms don't display the full 1200×630 image in every context. Mobile devices in particular often crop or apply a slightly tighter frame — especially LinkedIn and Facebook when the card appears in a feed on a small screen. The edges of your image are the danger zone.
The safe zone is roughly 960×504 pixels, centered. That's approximately 120 pixels of breathing room on the left and right, and about 63 pixels top and bottom (~60–80px padding all around). Anything you care about — logo, headline text, the main subject — belongs inside that box.
What happens to content near the edges? On desktop, probably nothing. On mobile, it might get clipped. The result is a card that looks fine when you test it on your laptop and weirdly cropped when your client shares it from their phone.
So design to the safe zone, not the full canvas.
The same rule applies to anything text-based: don't run copy all the way to the edges. Leave room.
File format and the size ceiling
JPEG or PNG. JPEG for photographs and complex images; PNG if you need transparency or sharp text rendering. WebP has decent support now but a non-trivial number of crawlers and older preview scrapers still choke on it, so the safe play is still JPEG/PNG for og:image.
File size ceiling: stay under 300KB, and aim for 100–200KB if you can. This is practical, not theoretical. When a platform's crawler fetches your page to generate a preview, it has a timeout and a size limit. A 2MB PNG might render fine in a browser; a crawler might just… skip it.
LinkedIn and Facebook have both documented limits in the range of 5–8MB technically, but in practice images above 300KB get deprioritized or cause slow preview generation.
The cost of getting this wrong: your link gets shared, the crawler hits the image, decides it's too heavy to bother with right now, and renders a text-only preview instead. All that time spent on the image — wasted.
Compress aggressively. Run it through Squoosh or a similar tool. A 1200×630 JPEG can be well under 150KB at 85% quality and still look sharp. A PNG of the same dimensions will typically be heavier — that's usually fine for logos/typography, but watch the file size.
Always set og:image:width and og:image:height
This is the one most people skip because they think "I set the image, that's enough."
It's not. When you omit og:image:width and og:image:height, crawlers don't know the dimensions until they download the image. Some just won't bother — they'll skip the image entirely rather than wait for the download to detect dimensions they could have read from a meta tag in milliseconds.
Here's what a complete, correct og:image implementation looks like:
<meta property="og:image" content="https://yourdomain.com/images/og/post-name.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="A short description of the image for screen readers">
Four tags. The first is the URL (always absolute — a relative path will break every preview outside your own domain). The next two are the dimensions. The last is the alt text, which both accessibility tools and some platform crawlers use.
og:image:alt is the one almost nobody includes. It's used by screen readers on platforms that support it, and it's just good practice. One more line of HTML — do it.
Readability beats beauty after compression
This is a design note worth making explicit. Share cards go through JPEG compression, they're viewed at small sizes in feeds, and they're often viewed on screens with varying calibration. The image that looks gorgeous in Figma at 100% zoom often does unexpected things when it's a 200px-wide thumbnail in a LinkedIn feed.
Two things that die badly in compressed, small-context images:
Thin fonts. Lightweight typefaces (300–400 weight) get eaten by compression artifacts and fall apart at small sizes. Stick to medium weight or higher for anything text-based. Bold is your friend.
Low contrast. If your text color and background color are close, they'll bleed together after compression. The WCAG AA standard (4.5:1 contrast ratio for normal text) is a reasonable floor for og:image text too — not for legal compliance reasons, just because it's the threshold at which text stays readable in degraded conditions.
If you're putting text on your OG image: high contrast, medium weight or heavier, sized so it's legible at 300px wide. Test it. Shrink it down in your browser and squint at it.
The code block for reference
<!-- og:image — the full set -->
<meta property="og:image" content="https://yourdomain.com/og/page-name.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Descriptive alt text for the image">
If you're on Next.js, the Metadata API handles this via the openGraph.images array — you pass width, height, url, and alt as object properties and it generates all four tags. The framework makes the "forgot the width attribute" mistake structurally harder.
How I build mine (not a pitch, just context)
For my own OG images, I build them as HTML files and render them with headless Chrome — CSS for layout, Google Fonts for typography, exact brand colors. The output is a PNG I know is pixel-perfect and on-brand, generated in seconds, reproducible any time I need a variation.
I went that route because AI image generators consistently mangle code text and can't hit exact hex values. HTML/CSS doesn't have that problem. Worth mentioning because if you're building a lot of these, that workflow might save you some pain.
One more thing: check what platforms are actually seeing
If your preview still looks wrong after fixing the dimensions and format — why your link preview isn't showing covers the cache-busting process and the per-platform debugger links. Platforms cache previews aggressively; updating your image won't change anything until you force a refresh.
And if you want to see exactly what your current og:image tag says without viewing source, paste your URL into the Meta Tag Auditor. It pulls all the Open Graph tags, shows the preview card, and flags missing width/height attributes — the stuff that's easy to miss until someone shares your link and the card looks broken.
For where og:image fits relative to Twitter/X Card images (different tags, slightly different specs): Twitter Cards vs Open Graph has the comparison.
The three-line summary:
- 1200×630 px, 1.91:1 — the universal baseline
- Safe zone is ~960×504 centered — design text and key content inside that box
- Set width and height meta tags — crawlers use them to skip the download
Sources (retrieved 2026-06-03):
- The Open Graph protocol — ogp.me (spec origin, 1.91:1 ratio definition)
- og:image size reference — og-image.org/learn/og-image-size (1200×630 baseline, file-size guidance, width/height attributes)