SiteAssets SiteAssets
Blog · Open Graph 7 min read

The OG image size cheat sheet for 2026

One file has to satisfy seven renderers that disagree on dimensions, file size and cropping. These are the numbers each platform actually enforces, and the safe area that survives all of them.

7 min read SiteAssets team

Most size guides repeat a single recommendation and stop there. That is not enough, because the failure mode is rarely “wrong size” — it is “correct size, wrong crop”. A 1200 × 630 image looks perfect on LinkedIn and loses its headline on WhatsApp, which centre-crops to a square thumbnail.

The short answer

Design at 1200 × 630 and keep every critical element inside a centred 1024 × 512 safe area. That one constraint covers Facebook, X, LinkedIn, Slack, Discord and Telegram. It also survives the square crop that WhatsApp and Discord compact mode apply.

Platform by platform

  • Facebook: 1200 × 630 preferred, 1.91:1, hard minimum 200 × 200. Anything smaller is dropped rather than upscaled.
  • X: 1200 × 628 for summary_large_image, minimum 300 × 157. The 1:1 summary card needs at least 144 × 144.
  • LinkedIn: 1200 × 627, 1.91:1, minimum 200 × 200. It renders wider than Facebook and crops the outer edges.
  • Slack: 1.91:1 unfurl, minimum around 400 × 200. It silently drops images served over plain HTTP.
  • Discord: 1200 × 630 embed, minimum 300 × 200. Compact mode overlays a small square thumbnail instead.
  • WhatsApp: a small square thumbnail, so a wide card is centre-cropped. Keep the mark near the centre.
  • iMessage: 1.91:1 card, minimum 400 × 200. It ignores twitter: tags entirely.
  • Telegram: 1.91:1, no documented minimum, but it caches the first render aggressively.

Where 1.91:1 comes from

The ratio is 1.91:1 because 1200 ÷ 630 is 1.9048, rounded up. Facebook popularised the 1200 × 630 canvas in 2013 and most platforms adopted it as the least surprising default. It is not a standard — it is a convention, and conventions are what crawler implementations were tested against.

The practical consequence: an image at exactly 1:1 or 16:9 is never wrong, but it is always cropped or letterboxed by at least one major platform. 1.91:1 is the only ratio that requires no crop anywhere.

The safe area rule

Treat the outer 88 pixels on each side and the outer 59 pixels top and bottom as disposable. On a 1200 × 630 canvas that leaves 1024 × 512 of guaranteed visible space. Logos, headlines and faces go inside; background texture can bleed to the edges.

html
<meta property="og:image" content="https://example.com/og/article.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:alt" content="Article title in plain words" />

Declaring width and height matters more than most guides admit. Without them, the first render is often a square placeholder while the crawler downloads and measures the file, and some clients keep that placeholder if the fetch is slow.

Format and file size

  • JPEG is the safest choice for photographic cards; it decodes everywhere, including old scrapers.
  • PNG is fine for flat designs and text-heavy cards, and it avoids JPEG ringing around small type.
  • WebP works on Facebook, X and Discord, but a few enterprise proxies and older Slack surfaces still fail to decode it.
  • AVIF is the least compatible. Ship it as a progressive enhancement at your own risk.
  • Keep the file under about 1 MB. Several platforms quietly time out on large fetches rather than reporting an error.

Five sizing mistakes that survive review

  1. 01 Designing at 1200 × 1200 because it looks better in the editor. Every wide card then crops the headline in half.
  2. 02 Putting the wordmark in the bottom-right corner, exactly where Slack and LinkedIn overlay their source label.
  3. 03 Using a 32 px favicon as og:image. It is below every minimum and renders as a text-only card.
  4. 04 Relying on og:image alone and forgetting twitter:image. X usually falls back correctly, but not always.
  5. 05 Leaving og:image:alt empty, which removes the only description screen readers get for the card.

Verify on the deployed URL

Localhost previews prove nothing: crawlers cannot reach your machine, and framework dev servers often inject different tags than production. Deploy, then scan the public URL. If the image renders at 1200 × 630 with the headline intact in every preview, the sizing work is done.

Try it on your own site

Fifteen checks, about five seconds.

Paste a deployed URL and read the check table: weight, status and the rule behind every row.