Open Graph Image Sizes in 2026: One File That Works Everywhere

Every “OG image size” article gives you a different table of per-platform dimensions, as if you’re supposed to export nine files. You’re not. One 1200×630 image covers every major platform, and the rest of the work is about what you put inside it and which meta tags you ship. Here’s the whole thing.

The answer: 1200 × 630

Property	Value
Dimensions	1200 × 630 px
Aspect ratio	1.91 : 1
Format	PNG or JPEG (WebP support is inconsistent — don’t)
File size	Under 1 MB; under 300 KB is better
Safe zone	Center 1080 × 600
URL	Absolute, HTTPS, publicly reachable

That single file renders correctly on Facebook, X, LinkedIn, Slack, Discord, WhatsApp, iMessage, Telegram, Mastodon, Bluesky, Teams, and every RSS reader and link-preview service built in the last decade. Platforms crop from it; they don’t demand their own copy.

Two aspect ratios show up in the wild — 1.91:1 (1200×630) and X’s occasional 2:1 (1200×600) — and the difference is 30 pixels of vertical crop. Design inside the safe zone and it stops mattering.

Where per-platform sizes actually differ

If you want the detail behind “just use 1200×630”:

Platform	Renders at	Notes
Facebook	1200 × 630	The origin of the standard; minimum 200×200
X / Twitter	1200 × 628 (large card)	Crops toward 2:1 in some views
LinkedIn	1200 × 627	Aggressive caching; needs the Post Inspector to bust
Slack / Discord	1200 × 630	Often shown much smaller inline — legibility matters
WhatsApp / iMessage	Square-ish crop	Crops hard from the center
Pinterest	Prefers vertical 2:3	The one genuine exception

The messaging apps are why the safe zone exists. WhatsApp and iMessage will take something close to a center square out of your 1.91:1 image, so anything within ~285px of the left or right edge can vanish. Keep the headline, logo, and any faces inside the middle 1080 × 600, and use the outer band for background only.

The meta tags you actually need

<meta property="og:title" content="Open Graph Image Sizes in 2026" />
<meta property="og:description" content="One file that works everywhere." />
<meta property="og:image" content="https://example.com/og/post-slug.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:alt" content="Article title over a dark gradient" />
<meta property="og:url" content="https://example.com/blog/post-slug" />
<meta property="og:type" content="article" />
<meta property="og:site_name" content="Example" />

<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:title" content="Open Graph Image Sizes in 2026" />
<meta name="twitter:image" content="https://example.com/og/post-slug.png" />

Details that matter more than they look:

• og:image must be an absolute URL. /og/post.png fails everywhere. This is the single most common reason a preview shows no image at all.
• og:image:width and og:image:height let platforms render the card before downloading the image. Without them, the first person to share a link sometimes gets a text-only card while the crawler is still fetching.
• twitter:card must be summary_large_image to get the big image. Omit it and X falls back to a small square thumbnail — or no card. X will fall back to og:image if twitter:image is missing, so you don’t need to duplicate every tag, but you do need the twitter:card line.
• The image must be publicly reachable. Behind auth, behind a staging password, blocked by a firewall rule against unknown user agents, or 404ing after a deploy — all produce the same silent empty card. Crawlers do not run your JavaScript to find it.
• og:image:alt is a real accessibility win and costs one line.

You can assemble and preview all of this in the browser with the free OG / Social Card Preview tool — fill in the fields, see the rendered card, and copy the finished meta tags.

Put the text in the image

X changed its link-preview format to strip the headline and description text, leaving just the image with the domain overlaid. They briefly rolled back parts of it and have shipped variations since, but the direction is clear: on X, the image is the entire message.

The practical consequence is straightforward — burn your headline into the image itself. If your OG image is a photo or an abstract gradient with no text, an X post pointing at it communicates nothing beyond a domain name. If the title is rendered in the image, you keep your headline regardless of what any platform does with the surrounding markup.

Design notes for text-in-image:

• Type large. These cards render at ~500px wide in a feed and smaller in a Slack sidebar. Body-copy sizes turn to mush. If your title is under about 40px at 1200px wide, it’s too small.
• Keep it to roughly 6–10 words. A card is a poster, not a paragraph.
• High contrast, always. Cards get viewed in dark mode, in bright sun, at thumbnail size. Run the pairing through a contrast checker — the WCAG contrast guide explains the ratios.
• Include the wordmark small and consistent, usually a corner. Recognition across a feed comes from consistency, not size.

Generating them without doing it by hand

Three approaches, in ascending order of effort:

1. One static fallback image in your <head> for the whole site. Takes ten minutes, and it’s strictly better than nothing — which is where most sites still are.
2. Per-page templates. A base design plus the page title. Astro, Next.js, and friends all have image-generation integrations that render an HTML template to PNG at build time. This is the sweet spot for a blog.
3. Runtime generation at an edge function. Necessary only if your titles are dynamic and unbounded.

For the static image (and for one-offs), the simplest path is to design directly at 1200×630 in the OG Image Generator — safe-zone guides, headline text, and a correctly-sized PNG out the other end, no resizing step at all.

Otherwise, run the output through the size checks: resize to exactly 1200×630, then compress to get under a few hundred KB. A 3 MB PNG isn’t rejected outright, but slow-fetching images time out on some crawlers and produce an empty card on first share — the moment that matters most. If you need a stand-in while you build the template, the Placeholder Image generator will spit out a correctly-sized file.

PNG or JPEG is the real choice: PNG for flat color, gradients, and text (sharp edges, no ringing artifacts); JPEG for photos. Skip WebP and AVIF here despite their advantages elsewhere — link-preview crawlers are the last place on the web where format support is still patchy. (For everything that isn’t a social card, PNG vs JPG vs WebP vs AVIF makes the opposite case.)

Debugging a preview that won’t update

Every platform caches scraped metadata aggressively, often for days. When you fix an OG tag and the old card keeps appearing, you’re looking at their cache, not your site.

1. Confirm the tags are in the served HTML — curl -s https://example.com/page | grep 'og:'. If your tags are injected client-side, most crawlers will never see them. This is the number-one cause of “my tags are right but nothing shows.”
2. Open the image URL in a private window. It must load with no auth and no redirect chain.
3. Force a re-scrape with the platform’s own debugger: Facebook’s Sharing Debugger, LinkedIn’s Post Inspector, and X’s card validator (now largely folded into posting itself — a fresh URL query string is the reliable workaround there).
4. Bust the cache with a new filename or query string — og-image.png?v=2 — when the debugger won’t cooperate. Ugly, effective, and the fastest fix under deadline.
5. Check your CSP and hotlink protection. A Referrer-Policy or a hotlink rule that blocks unknown referrers will serve crawlers a 403 while looking perfect in your browser. See Content Security Policy explained if you’re locking headers down.

The five-minute version

• Ship one 1200×630 PNG or JPEG, under ~300 KB.
• Keep everything important inside the center 1080×600.
• Put the headline in the image.
• Ship og:title, og:description, og:image (absolute URL), og:image:width/height, og:url, og:type, and twitter:card=summary_large_image.
• Verify with a real fetch of your served HTML, then a platform debugger.

Build and preview the tags in the OG / Social Card Preview tool, generate the rest of your head with the Meta Tag Generator, and check what your live pages currently send with the Meta Tag Analyzer. All three run entirely in your browser.

Posting images directly rather than links? That’s a different set of dimensions entirely — see the social media image size guide for 2026.