You set an Open Graph image, it looks perfect in your local preview, and then it shows up cropped weirdly on LinkedIn, stretched on Slack, and fine on X. The problem usually isn't the meta tags — it's that different platforms apply different crop and scale logic to the same source image, and choosing an aspect ratio that survives the worst-case crop across platforms is a design decision, not just a technical one.
There's No Single "Correct" Ratio, Only a Safest One
The Open Graph protocol itself doesn't mandate an aspect ratio — og:image:width and og:image:height are optional hints. In practice, the ecosystem converged on 1.91:1 (1200x630px is the standard implementation) because that's what Facebook's card renderer was built around, and most other platforms followed suit closely enough that 1200x630 has become the safe default rather than a spec requirement.
The reason to still care about the exact ratio, not just the pixel dimensions: platforms that receive an image with a different aspect ratio than they expect will crop or letterbox it using their own logic, which you don't control and can't preview reliably outside their actual renderer.
How Platforms Actually Handle Mismatched Ratios
- Facebook / Open Graph consumers generally: center-crops to fit 1.91:1 if you supply a different ratio, meaning content near the top and bottom edges of a taller image gets cut.
- X (Twitter) summary_large_image cards: more tolerant of squarer ratios, generally displaying close to 2:1 to 1:1 without aggressive cropping, but still crops outside that range.
- LinkedIn: uses its own unfurling pipeline and has historically been pickier about needing an explicit
og:imagewith dimensions matching what it expects — vague or missing dimension hints sometimes trigger a fallback to a lower-quality crawled thumbnail instead of your intended image. - Slack: unfurls via Open Graph tags too, but caches aggressively — a share image change won't show until Slack's cache expires or you force a refresh in some cases.
None of this is exhaustive documentation you can rely on staying accurate — platforms change unfurl behavior without announcement — which is exactly why testing your actual rendered card per platform matters more than trusting the spec compliance of your tags.
Designing for the Crop, Not Just the Canvas
Because the actual displayed region varies by platform, the safest design approach treats the full 1200x630 canvas as a bleed area and keeps critical content — headline text, logos, faces — within a smaller safe zone centered in the frame.
1200x630 canvas
┌────────────────────────────────┐
│ bleed (may be cropped) │
│ ┌──────────────────────────┐ │
│ │ │ │
│ │ safe zone (~1000x500) │ │
│ │ critical content here │ │
│ │ │ │
│ └──────────────────────────┘ │
│ │
└────────────────────────────────┘
Keeping roughly a 100px margin on all sides free of essential text or faces absorbs the range of crop behaviors you'll see across platforms without needing per-platform image variants.
Text on Share Images: A Separate Failure Mode
Aspect ratio problems and legibility problems compound each other. Small text that's readable at full 1200x630 display size becomes illegible once a platform scales the card down for a compact feed view or crops it tighter than expected. Keep headline text large relative to the canvas — as a rough guide, if you wouldn't be comfortable reading it at half the intended display size, it's too small for a share card, where thumbnail-sized rendering is common in feeds.
Setting the Dimensions Correctly in Your Meta Tags
Declaring width and height explicitly helps platforms that use the hint to reserve layout space and avoid a fallback crawl of a different image on the page:
<meta property="og:image" content="https://example.com/share.jpg" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:image" content="https://example.com/share.jpg" />
Generating these consistently across every page is easy to get wrong by hand at scale — a meta tags generator keeps the required Open Graph and Twitter Card fields consistent without hand-editing each page's head block.
Verify Before You Ship, Not After a User Reports It
The only reliable way to know how a share image will actually render is to check it in each platform's real (or platform-provided) preview rather than trusting that spec-correct tags guarantee consistent display. Use the OG Preview tool to check how your image and metadata will render as a card before publishing, and separately test on any platform where your audience actually shares links — if your traffic comes heavily from LinkedIn, don't stop at a generic Open Graph preview that doesn't model LinkedIn's specific crop behavior.
Building the Image Asset Itself
Once you've settled on 1200x630 as your working canvas, generating consistent share images across many pages benefits from a repeatable process rather than manual exports per page — resize your source design assets to the exact target dimensions with the Image Resizer rather than letting each export vary slightly, since inconsistent source dimensions are one of the more common causes of a crop looking fine on one page and wrong on another with supposedly the same template.
Next Step
Pick 1200x630 as your default unless you have a specific reason to deviate, design with a safe zone that tolerates cropping rather than assuming platforms respect your exact frame, and check the actual rendered card on the platforms your audience uses before treating the image as done.