Paste a link into Slack, X, LinkedIn, Discord, or iMessage. A card appears — image, title, description. The image half of that card is the Open Graph image, declared by one og:image meta tag in the page's <head>, fetched a single time by each platform's crawler, cached, and then shown to everyone who ever sees the link. For most pages it is the most-viewed image they will ever have. It gets decided in one line of HTML.

The protocol behind it dates to Facebook in 2010 and lives at ogp.me. Practically every platform that unfurls a link reads it. X checks its own twitter:* tags first, then falls back to OG for anything missing — which is why the block below carries both.

The tags

Here's the minimum that works everywhere:

<meta property="og:title" content="Your page title" />
<meta property="og:description" content="One or two honest sentences." />
<meta property="og:image" content="https://example.com/og.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:alt" content="What the image shows" />
<meta property="og:url" content="https://example.com/page" />
<meta name="twitter:card" content="summary_large_image" />

A few of these earn their keep in ways that aren't obvious:

  • Absolute HTTPS URLs, always. Crawlers resolve relative paths unreliably, and several ignore plain-http images altogether.
  • og:image:width and og:image:height let a platform lay out the card before the image finishes downloading. First shares render faster instead of falling back to a text-only card while the crawler thinks.
  • og:image:alt — the spec itself says any page with og:image should carry it. Costs nothing. Skip it and screen readers get silence.
  • twitter:card: summary_large_image is what gets the big picture card on X. Unset, you risk the small thumbnail.

One size: 1200×630

The 2026 answer is the same as the 2020 answer: 1200×630 pixels, 1.91:1. Facebook recommends exactly that. LinkedIn asks for 1200×627, which is the same ratio with one pixel of pedantry. Slack, Discord, WhatsApp, Telegram and iMessage all render it cleanly.

One caveat deserves the ink: X's large card displays at 2:1, so a 1200×630 image loses roughly 15 pixels off the top and bottom on its way to 1200×600. You don't fix that with a second image — you fix it with a safe zone. Keep text and faces out of the outermost ~30 vertical pixels and a single render serves every platform there is.

Going smaller buys nothing. Under 600×315, Facebook still accepts the image but renders it small; under 200×200 it rejects it outright. 1200×630 is retina-crisp, universally accepted, and free to standardize on.

Formats and file weight

PNG and JPEG are the safe answers — JPEG compresses photographic backgrounds better, PNG keeps flat design and text crisp.

WebP is where platforms diverge. X and Facebook handle it fine. LinkedIn's crawler, though, is notoriously unreliable with WebP: links that preview everywhere else arrive imageless there. Until that changes, WebP in an og:image tag is a bet against your B2B distribution. Animated GIFs mostly render as stills, and SVG isn't accepted anywhere that matters.

On weight: Facebook's hard ceiling is 8 MB. The practical target is under ~1 MB, because link previews race the scroll, and a slow image is a blank card in the feed.

Why your change isn't showing up

Crawlers cache aggressively. Ship a new image at the same URL and platforms will keep showing the old one for days. The debugging kit is short:

  • Meta Sharing Debugger (developers.facebook.com/tools/debug) shows what Facebook's crawler sees, and its "Scrape Again" button forces a refresh.
  • LinkedIn Post Inspector (linkedin.com/post-inspector) does the same for LinkedIn.
  • X killed its Card Validator preview years ago. The honest test is posting the link — a DM to yourself works — and looking.

The workaround that always works is a versioned URL: serve og.png?v=2, or better, a URL that changes whenever the content does, and crawler caches stop being your problem. That property is also the quiet argument for per-page generated images over one static file.

Static, templated, or automated

A handful of pages — a landing page, a few product pages? Design them by hand in any tool, export at 1200×630, move on. No automation earns its complexity at that scale.

Content at publishing scale is different. Every blog post, every doc page, every listing wants a card, and hand-making them stops happening the week you get busy. Browser-rendered OG templates take title, author and tag as parameters; a signed URL placed directly in the meta tag renders on first crawl and re-renders whenever a parameter changes. Inside a workflow engine it collapses to one n8n node.

Cards built from JSX are a genuine alternative for flex-shaped designs on Vercel — with a specific set of walls we mapped in @vercel/og vs a real browser.

The decision rule is volume. The moment OG images turn from a one-time design task into a per-publish chore, they should come from a template and a URL — not from a designer's Tuesday.

Sizes and platform behavior verified 2026-08-26. Platforms move — we recheck this page yearly, and the date above is honest.