Meta tag reference pages for Open Graph and Twitter Card dimensions tend to either repeat one number without explaining where it comes from, or go stale as platforms shift requirements. Here's what the numbers actually mean, why 1200x630 became the default, and where the edge cases live.
The Practical Standard: 1200x630px
The Open Graph protocol spec itself is dimension-agnostic — ogp.me defines og:image, og:image:width, and og:image:height as optional properties without mandating a size. 1200x630px (a 1.91:1 ratio) became the de facto standard because it's what Facebook's crawler and card renderer were built around, and enough of the ecosystem — including X's large card format — converged on compatible ratios that one asset now covers most platforms.
Two related numbers worth knowing:
- Minimum practical size: platforms generally want at least 600x315px before they'll render the large card layout; below that, some fall back to a smaller thumbnail-style card even if you've explicitly requested the large format.
- Minimum aspect ratio tolerance: staying close to 1.91:1 avoids crop or letterbox behavior; ratios far from that (very tall or very wide images) are the most likely to render unpredictably across platforms.
X (Twitter) Card Requirements
X's summary_large_image card — the large, full-width image format most sites want — has its own historically documented minimums (300x157px) and works well with the same 1200x630 asset used for Open Graph. The card type itself is declared via meta tag, separate from the image dimensions:
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:image" content="https://example.com/share.jpg" />
If you omit twitter:card or twitter:image, X generally falls back to reading the standard og:image tags, so duplicating the image URL isn't strictly required — but declaring both explicitly avoids depending on fallback behavior that could change.
Full Meta Tag Set
<!-- Open Graph -->
<meta property="og:title" content="Your Page Title" />
<meta property="og:description" content="A concise description under 200 characters." />
<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 property="og:type" content="article" />
<meta property="og:url" content="https://example.com/page" />
<!-- Twitter/X -->
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:title" content="Your Page Title" />
<meta name="twitter:description" content="A concise description under 200 characters." />
<meta name="twitter:image" content="https://example.com/share.jpg" />
Always use an absolute URL for image tags, not a relative path — crawlers fetching your page's HTML don't reliably resolve relative paths the same way a browser does, and a broken image reference is one of the most common causes of a share card rendering with no image at all.
File Size and Format: The Less-Discussed Constraints
Pixel dimensions get most of the attention, but two other constraints cause silent failures just as often:
File size. Crawlers generally impose a cap in the low single-digit megabytes on images they'll fetch for unfurling, and an oversized image risks the fetch timing out or the platform giving up and showing no image rather than a scaled-down one. There's no benefit to shipping a multi-megabyte share image — run it through a JPG Compressor or resize it to the target dimensions first with the Image Resizer; a 1200x630 image has no reason to exceed a few hundred kilobytes.
Format support. JPEG and PNG are universally supported for share images. WebP support among social crawlers has improved but isn't universal across every platform's unfurl pipeline, and some older or less-maintained crawlers still fail silently on WebP input. For a share image specifically — as opposed to on-page content images — JPEG remains the safer default given how much is riding on the fetch succeeding.
What Happens When Dimensions Are Wrong
| Problem | Likely result |
| --- | --- |
| Image smaller than ~600x315px | Falls back to small/summary card instead of large card |
| Aspect ratio far from 1.91:1 | Platform crops or letterboxes unpredictably |
| Relative image URL | Crawler may fail to resolve it, showing no image |
| File size too large | Fetch times out, no image shown |
| Missing twitter:card tag | X falls back to Open Graph tags (usually fine, but untested by you) |
| WebP image on an older crawler | Silent failure to no image |
Most of these failures are silent — you won't get an error, the card will just render worse than expected, which is why manual verification matters more here than for most meta tag mistakes.
Article, Website, and Product Types Don't Change the Image Requirements
og:type (website, article, product, profile, and others) changes which secondary meta properties are expected — article:published_time and article:author for article, for instance — but it doesn't change the og:image dimension guidance itself. The 1200x630px sizing applies uniformly regardless of type, since the image rendering logic in the card layout is shared across types on most platforms. Where type does matter is in what else you should declare alongside the image: an article page benefits from also setting og:image:alt for accessibility, something static image galleries and product pages should include too but that gets skipped more often on simple pages.
<meta property="og:image:alt" content="Descriptive text for the share image" />
og:image:alt isn't part of the sizing conversation, but it's frequently missing from the same pages that get the dimensions right, and it costs nothing to add once you're already setting the other image properties.
Keeping Safe Margins for Text Overlays
If your share image includes overlaid text — a headline baked into the image itself rather than relying on og:title — leave real margin around the edges. Different platforms crop or letterbox slightly differently even within the shared 1.91:1 target, and UI chrome (play buttons on video-type cards, rounded corner masking on some platforms) can obscure content placed flush against the edge. A rough rule that holds across most renderers: keep essential text and logos within the center 90% of the canvas, treating the outer margin as a buffer rather than usable space.
Dynamically Generated OG Images
Sites with many pages — blogs, product catalogs, documentation — increasingly generate share images on the fly rather than hand-designing one per page, using an API route that renders a template (title, category, author) into a 1200x630 image at request time and caches the result. This keeps every page's share image consistent and on-brand without manual design work per post, at the cost of needing the generation endpoint to be reliably fast and cacheable, since a slow or failing image endpoint is exactly the kind of fetch timeout that causes crawlers to give up and show no image at all. If you go this route, cache the generated image aggressively behind a CDN and give it a stable, content-addressed URL rather than regenerating it on every crawl.
Verifying Your Actual Output
Spec compliance doesn't guarantee correct rendering, since each platform's crawler and cache behavior is independent of the standard. Check your actual rendered card with the OG Preview tool before publishing, and if a share card looks wrong after you've already shared a link once, remember that most platforms cache the previous unfurl result — you may need that platform's specific cache-refresh tool (Facebook's Sharing Debugger, for example) rather than just fixing the tag and waiting.
Setting This Up Once, Correctly
For a site with many pages, hand-writing these tags per page invites drift — a meta tags generator keeps the required Open Graph and Twitter fields consistent across templates so you're not debugging a missing og:image:width on one page type six months from now.
Next Step
Standardize on a 1200x630px image, absolute URLs, and both Open Graph and Twitter meta tags on every shareable page, then verify the actual rendered card rather than trusting tag correctness alone — the two are not the same guarantee.