og:image size guide for 2026: the dimensions that actually work

Q: Is the Twitter/X card image size different from og:image?

Barely. With twitter:card set to summary_large_image, X wants 1200×628, which is close enough to 1200×630 that the same file works. The summary card (no large image) uses a small square crop instead. If you don't set a twitter:image, X falls back to your og:image, so one 1200×630 image covers both.

Q: Why is my og:image not showing?

Usually one of these: the og:image is a relative path instead of a full https:// URL, the image isn't publicly reachable (behind auth or on staging), the file is too heavy and the scraper times out, or the platform is serving a cached preview from before you fixed it. Run the URL through Facebook's Sharing Debugger or LinkedIn's Post Inspector to see what the crawler actually fetched.

"What size should my og:image be?" has a one-line answer, and most of the articles that come up for it bury that line under 1,500 words of history about the Open Graph protocol. So here's the line first, then everything you actually need to get the preview right and the reasons behind it.

The short answer

1200 × 630 pixels. A 1.91:1 aspect ratio.

That's it. Use that and your link preview renders cleanly on Facebook, LinkedIn, WhatsApp, Slack, Discord, and X. It's the safe default because it's the size the largest platforms designed their card layouts around, so nobody has to crop it. Anything else and you're gambling on each platform's cropping logic.

The 1.91:1 ratio comes from Facebook's large share card, and because everyone copied Facebook's card, it became the de facto standard across the web. You don't need a different image per platform. You need one good 1200×630 image and the right tags pointing at it.

If you remember nothing else from this post, remember 1200×630. The rest is detail for when something breaks.

Where platforms actually differ

They mostly don't. But the edges are worth knowing.

Facebook and LinkedIn

Both read the og:image tag and both want 1200×630. LinkedIn is the stricter of the two about reachability and caching (more on that below), but the dimensions are identical. One image, both platforms, done.

X (Twitter)

X reads its own twitter: tags first, and the image size depends on which card type you declare:

summary_large_image is the big edge-to-edge card. It wants 1200×628, which is close enough to 1200×630 that the same file works without anyone noticing the two-pixel difference.
summary is the small card with a square thumbnail on the left. It crops to a square, so a wide 1200×630 image gets center-cropped and usually looks worse.

Pick summary_large_image unless you have a reason not to. And here's the useful part: if you don't set a twitter:image at all, X falls back to your og:image. So a single 1200×630 image plus twitter:card set to summary_large_image covers X completely, no separate Twitter image required.

WhatsApp, Discord, Slack

All three use og:image. They render the preview smaller than Facebook does, but they pull from the same tag, so the same 1200×630 file works. The thing that matters more than size on these is that the image is actually fetchable and not too heavy. WhatsApp in particular will silently drop an image that's slow to load on a mobile connection.

The minimum

Platforms accept down to 200×200, but "accepts" is not "looks good." Below roughly 600px wide the image renders blurry or gets dropped to a tiny thumbnail. There's no upside to going small. 1200×630 is the target, not a ceiling you're trying to stay under.

File format and file size

Format: JPG or PNG. Use JPG for photos and image-heavy designs (it compresses them much smaller), use PNG for graphics with text, flat colors, or sharp edges (it stays crisp where JPG goes fuzzy). Most OG images are graphics with a logo and a headline, so PNG is the common pick, but a photographic background will be far lighter as a JPG. Skip SVG (unsupported by basically every platform) and GIF (platforms grab the first frame, never the animation, so there's no point).

Size: keep it under about 5 MB. Some platforms officially cap at 8 MB, but the cap isn't the real constraint. The real constraint is the scrape timeout. When a platform crawls your link, it has a few seconds to fetch the image before it gives up and renders no preview at all. A 7 MB PNG over a slow origin is exactly how you get "the preview just doesn't show" with no error anywhere. Smaller image, faster fetch, more reliable preview. Aim for a few hundred KB if you can. There is no prize for shipping a 6 MB OG image.

The tags you actually need

Here's a correct, complete block for the <head>:

<meta property="og:image" content="https://yourdomain.com/og-image.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:alt" content="Plain-language description of the image" />
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:image" content="https://yourdomain.com/og-image.png" />

A few of these get skipped a lot and shouldn't be.

og:image:width and og:image:height matter more than people think. They tell the platform the image's dimensions before it has downloaded the image. That lets it draw the preview box at the correct size up front, which avoids the layout shift you get when an image pops in and shoves everything around. It also reduces failed previews: a crawler that already knows the box is 1200×630 is less likely to bail on a slow image. Set them to the real pixel dimensions, not a guess.

og:image:alt is the alt text for the preview image. Platform support for reading it varies, but it's one line and costs nothing, so include it.

twitter:card is what tells X to use the large image layout instead of the small thumbnail. Leave it off and X defaults to the small card, which gets noticeably less attention in the feed. twitter:image is optional if your og:image is set, since X falls back to it, but including it is harmless and explicit.

The 5 most common og:image mistakes

This is the part that fixes most broken previews.

1. A relative URL instead of an absolute one

The crawler fetches your image from its own servers, not from inside your rendered page. A relative path means nothing to it.

<!-- Wrong: the crawler can't resolve this -->
<meta property="og:image" content="/og-image.png" />

<!-- Right: full absolute URL, with https -->
<meta property="og:image" content="https://yourdomain.com/og-image.png" />

This is the single most common cause of a missing OG image. It looks fine in your browser because the browser resolves the relative path against the current page. The crawler doesn't.

2. Missing width and height tags

Covered above, but it earns a spot on the mistakes list because the symptom is intermittent. Previews work sometimes and fail other times depending on how fast the image loads. Adding og:image:width and og:image:height makes the behavior consistent.

3. The image isn't publicly reachable

If the scraper can't fetch the image, there's no preview. This happens when the image sits behind authentication, on a staging environment with basic-auth, on localhost, or on a server that's blocking the platform's crawler user-agent. The page also needs HTTPS, and so does the image URL. Open the image URL in an incognito window with no cookies. If you can't see it there, neither can the crawler.

4. The image is too large and the scrape times out

A huge image fails quietly. The crawler requests it, waits a few seconds, gives up, and renders nothing. You're left staring at a correct-looking tag wondering why there's no preview. Compress the image, keep it well under 5 MB (ideally under 1 MB), and serve it from somewhere fast. See the file-size section above.

5. Caching: you fixed it but the old image still shows

You found the bug, fixed the tag, redeployed, shared the link again, and the preview hasn't changed. This is almost never your code. Every platform caches the preview from its first crawl and reuses it for days. Your fix is live; the platform just hasn't re-fetched.

How each one behaves and how to force a refresh:

Facebook: run the URL through the Sharing Debugger and click Scrape Again. Immediate re-crawl.
LinkedIn: run it through the Post Inspector. Inspecting re-scrapes on the spot. LinkedIn caches around 7 days otherwise.
X and WhatsApp: no refresh tool. Append a query parameter and share the new URL, e.g. https://yourdomain.com/page?v=2. Both cache by exact URL, so a new parameter looks like a brand-new page and gets crawled fresh.

This whole topic has more depth than fits here, including the WhatsApp quirks and why already-posted links keep the old card forever. If you're fighting a stale or missing preview right now, that's the post to read: Link preview not showing? Fix it on WhatsApp, X & LinkedIn.

How to test before you ship

The trap with OG images is that you only notice the bug after you've shared the link, and by then the broken version is cached for a week. Check before the first share, not after.

The per-platform validators:

Facebook Sharing Debugger (developers.facebook.com/tools/debug): shows every tag it read, plus warnings, and forces a re-scrape. The most useful single tool, partly because WhatsApp shares Meta's crawler, so a Facebook re-scrape sometimes refreshes WhatsApp too.
LinkedIn Post Inspector (linkedin.com/post-inspector): shows the title, description, and image LinkedIn picked up, no login needed.
X: there is no validator. X deprecated its Card Validator in 2022 and never replaced it. The query-parameter trick above is the only lever you have.

You can also just check the preview before any of these. MetaBlast generates the OG tags for a URL (including og:image:width and og:image:height) and renders the Google, X, Facebook, and LinkedIn previews side by side, so a broken or wrong-sized og:image shows up before you ship instead of after someone shares it.

TL;DR

Size: 1200 × 630 px, 1.91:1 ratio. One image covers every platform.
X: use twitter:card = summary_large_image (wants 1200×628, same file). Falls back to og:image if you skip twitter:image.
Format: JPG for photos, PNG for graphics and text. Never SVG or GIF.
File size: under ~5 MB, ideally under 1 MB. A heavy image makes the scraper time out and show nothing.
Tags: og:image (absolute https URL), og:image:width, og:image:height, og:image:alt, twitter:card.
Top mistake: a relative og:image URL. It must be a full https:// link.
Stale preview: that's cache, not your code. Use the Facebook Debugger or LinkedIn Inspector to force a re-scrape, or append ?v=2 for X and WhatsApp.

FAQ

What size should an og:image be?

1200×630 pixels, a 1.91:1 aspect ratio. That's the size Facebook, LinkedIn, WhatsApp, Slack, and Discord all render cleanly, and X reuses it for the large image card. Use it as your default and you don't have to think per-platform.

Is the Twitter/X card image size different from og:image?

Barely. With twitter:card set to summary_large_image, X wants 1200×628, close enough to 1200×630 that the same file works. The summary card (no large image) uses a small square crop instead. If you don't set a twitter:image, X falls back to your og:image, so one 1200×630 image covers both.

Why is my og:image not showing?

Usually one of these: the og:image is a relative path instead of a full https:// URL, the image isn't publicly reachable (behind auth or on staging), the file is too heavy and the scraper times out, or the platform is serving a cached preview from before you fixed it. Run the URL through Facebook's Sharing Debugger or LinkedIn's Post Inspector to see what the crawler actually fetched.

Do og:image:width and og:image:height tags matter?

Yes. They let a platform draw the preview box at the right size before the image finishes downloading, which avoids layout shift and reduces the chance of a failed or cropped preview. They're cheap to add and worth it: set them to the actual pixel dimensions of your image (1200 and 630).