Social Sharing Images (og:image and twitter:image): Sizes, Limits, and Fallbacks

The image spec sheet for og:image and twitter:image — the safe 1200×630 (1.91:1) default, per-platform dimensions and file-size caps, the absolute-URL rule, Google's own 2026 thumbnail requirements, and why images fail vs. fall back.

First published: Jul 2, 2026 · Last updated: Jul 18, 2026 · Advanced
demand #11 in Meta Tags#31 in On-Page#168 in Technical SEO#226 on the site
AIAuthored byAI v2

og:image and twitter:image point at the image in your link-preview card — this is the deep dive on the image requirements, not the tag syntax (see the Open Graph and Twitter Cards siblings for that). The safe cross-platform default is an absolute HTTPS URL to a ~1200×630px (1.91:1) image, but that's a community-converged compromise, not a single official spec. Only Meta's numbers are primary-sourced: 200×200 minimum, 600×315 floor, ≥1200×630 recommended, 1.91:1, 8 MB cap. X's ~1200×628/675 and ~5 MB, Slack's ~32 KB early-HTML read, and WhatsApp's silent drop of large images are community consensus, not freshly-verifiable first-party specs — say so. The absolute-URL rule is a real silent failure: social crawlers don't resolve relative paths. A missing tag falls back to a scraped body image; a present-but-broken image (404, oversized, auth-blocked) is less forgiving and often shows no image at all. As of March 2026 Google reads og:image for its own Search and Discover thumbnails (its own docs don't extend this to AI surfaces), but its spec is 16:9 / ≥1200px wide / ≥300K pixels / no logos / no text — a different shape than the 1.91:1 social crop. Caching means fixing an image doesn't fix already-shared links until you force a re-scrape. This is a deep dive under the Meta Tags for SEO hub.

TL;DR — This is the image spec sheet, not the tag syntax — og:image / twitter:image mechanics live in the Open GraphOpen Graph (OG) tags are `<meta>` elements in a page's head, defined by the Open Graph protocol (ogp.me, created by Facebook), that describe a page as a shareable object — its title, description, image, URL, and type. They control how a link preview card looks when the page is shared on Facebook, LinkedIn, Slack, Discord, WhatsApp, and iMessage. They are not a direct Google ranking factor, though Google reads og:title, og:image, and og:site_name as inputs to how a result appears. and Twitter CardsTwitter Card tags (now often called \"X Cards\") are <meta name=\"twitter:...\"> tags in a page's <head> that tell X's link-unfurling system what rich preview to build for a shared URL — image, headline, description, and (for player cards) an embeddable frame. The four card types are summary, summary_large_image, app, and player. Every twitter:* property falls back to its og:* equivalent if missing — except twitter:card itself, which has no fallback and must be set explicitly. They are not a Google or Bing ranking factor. siblings. 1200×630 (1.91:1) is the safe default, not an official universal standard. Only Meta’s numbers are primary-sourced: 200×200 minimum, 600×315 floor, ≥1200×630 recommended, 1.91:1, 8 MB cap. X’s ~1200×628/675 and ~5 MB, Slack’s ~32 KB early-HTML read, and WhatsApp’s ~300 KB silent drop are community consensus, not freshly-verifiable first-party specs — I flag which is which. The absolute-URL rule is a real silent failure: social crawlersA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. don’t resolve relative paths. Missing ≠ broken: an absent tag falls back to a scraped body image; a present but failing image (404, oversized, auth/robots-blocked) often shows nothing. Google now reads og:image for its own Search and Discover thumbnails (March 2026), but its spec is 16:9 / ≥1200px wide / ≥300K pixels / no logo / no text — a different shape than the 1.91:1 social crop. CachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. means a fix doesn’t reach already-shared links until you force a re-scrape.

Evidence for this claim The Open Graph protocol uses og:image to identify an image and defines optional image URL, MIME type, width, height, and alt properties. Scope: Open Graph protocol metadata. Confidence: high · Verified: Open Graph protocol Evidence for this claim X Cards support summary and summary_large_image card types and image metadata, subject to X's crawler and card requirements. Scope: Current X Cards markup documentation. Confidence: high · Verified: X Developer Platform: Cards markup

What this article covers (and what the siblings cover)

The tag mechanics — the four required Open GraphOpen Graph (OG) tags are `<meta>` elements in a page's head, defined by the Open Graph protocol (ogp.me, created by Facebook), that describe a page as a shareable object — its title, description, image, URL, and type. They control how a link preview card looks when the page is shared on Facebook, LinkedIn, Slack, Discord, WhatsApp, and iMessage. They are not a direct Google ranking factor, though Google reads og:title, og:image, and og:site_name as inputs to how a result appears. properties, name= vs. property=, the four Twitter Card types, and the twitter:image → og:image fallback rule — are already handled in Open Graph TagsOpen Graph (OG) tags are `<meta>` elements in a page's head, defined by the Open Graph protocol (ogp.me, created by Facebook), that describe a page as a shareable object — its title, description, image, URL, and type. They control how a link preview card looks when the page is shared on Facebook, LinkedIn, Slack, Discord, WhatsApp, and iMessage. They are not a direct Google ranking factor, though Google reads og:title, og:image, and og:site_name as inputs to how a result appears. and Twitter Card TagsTwitter Card tags (now often called \"X Cards\") are <meta name=\"twitter:...\"> tags in a page's <head> that tell X's link-unfurling system what rich preview to build for a shared URL — image, headline, description, and (for player cards) an embeddable frame. The four card types are summary, summary_large_image, app, and player. Every twitter:* property falls back to its og:* equivalent if missing — except twitter:card itself, which has no fallback and must be set explicitly. They are not a Google or Bing ranking factor.. This piece is the companion spec sheet: dimensions, aspect ratio, file size, format, the absolute-URL requirement, and what actually breaks when any of those is wrong. If you’re here to write the <meta> line, start with those two; if you’re here because your image is the wrong size or won’t show, you’re in the right place.

One quick reuse of the fallback rule, because it decides how many images you need: twitter:image falls back to og:image when it’s absent, so most sites set one image and use it for both — you only diverge if you specifically want a different crop for X.

The safe default: 1200×630 (1.91:1) — and why it’s a compromise

Nearly every guide leads with 1200×630 and stops there. It’s a good default, but it’s worth being honest about where it comes from: it’s not a single cross-platform standard anyone publishes identically. It’s the community-converged size that clears Facebook’s recommendation and renders acceptably on everything else. Some guides say 1200×627, some say 1200×628 for X — those are rounding and legacy variants of the same ~1.91:1 idea, not competing specs. Pick 1200×630, and the only place you might want a second image is X, if you care about a tighter crop there.

TIP Check the actual crop before the platform chooses one for you

A square source can be perfectly valid as an image and still crop poorly in a wide social card. The finding identifies the ratio mismatch; the preview is where you judge whether the subject survives the crop.

Paste the URL into my preview tool to compare the declared image across major card shapes before publishing or forcing a re-scrape. Social Preview Checker Free

  1. Confirm the declared image is an absolute, fetchable HTTPS URL rather than a relative path.
  2. Compare the source dimensions with the wide-card preview and keep the subject inside a crop-safe area.
  3. Publish the replacement, then use the platform re-scrape workflow so its cached card is refreshed.
The ratio warning is a crop-risk signal, not a universal platform specification.

Per-platform dimensions and file size

The single most useful thing this page can do is separate what’s primary-sourced (Meta) from what’s community consensus (everything else). I’ve been explicit about which is which — don’t treat the non-Meta numbers as gospel.

Facebook / Meta (primary-sourced)

From Meta’s own sharing-images documentation:

  • Minimum: “The minimum allowed image dimension is 200 x 200 pixels.”
  • Floor to avoid the small render: “At the minimum, you should use images that are 600 x 315 pixels to display link page posts with larger images.”
  • Recommended: “Use images that are at least 1200 x 630 pixels for the best display on high resolution devices.”
  • Aspect ratio: keep it “as close to 1.91:1 aspect ratio as possible” to avoid cropping in Feed.
  • File-size cap: “The size of the image file must not exceed 8 MB.”

Meta is also the source of the “first-share” caching quirk: the crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. has to see the image at least once before it renders, so “the first person who shares a piece of content won’t see a rendered image.” (LinkedIn behaves similarly — this is the re-scrape story, covered in the Open Graph sibling.)

X / Twitter (community consensus — treat with caution)

X’s numbers are the ones to be careful with. The official Card Validator was deprecated in 2022 with no replacement, and developer.x.com’s Cards documentation is effectively gone: it returned an HTTP 402 Payment Required response in early July 2026, and as of this update the same URL instead redirectsA redirect sends browsers and crawlers from a requested URL to a different one. An HTTP redirect specifically is a 3xx status code paired with a Location header; meta refresh and JavaScript redirects achieve a similar navigation without being a 3xx response themselves. Permanent redirects (301/308) are Google's signal the target should be canonical; temporary ones (302/303/307) aren't. (HTTP 307A 307 (\"Temporary Redirect\") is a temporary redirect that, unlike a 302, is guaranteed by the HTTP spec to preserve the original request method and body — so a POST stays a POST. For SEO, Google treats it as equivalent to a 302. Browsers/tools also sometimes represent an HSTS-driven internal scheme upgrade as a 307, though the server never actually sent it and RFC 6797 doesn't require that specific code.) to docs.x.com’s homepage, where the equivalent Cards-markup path 404s — a dead link either way, so there is no live, freshly-checkable first-party X spec right now. The figures that circulate across guides — roughly 1200×628 or 1200×675 for summary_large_image, a 300×157 minimum, a 4096×4096 maximum, and a ~5 MB file cap, with the small summary card needing a smaller ~144×144-minimum square — are third-party consensus, not a confirmed current official spec. They’re close enough to the 1.91:1 default to be useful, but I wouldn’t present any specific X byte or pixel number as authoritative. (The X documentation and validator situation is covered in full in the Twitter CardsTwitter Card tags (now often called \"X Cards\") are <meta name=\"twitter:...\"> tags in a page's <head> that tell X's link-unfurling system what rich preview to build for a shared URL — image, headline, description, and (for player cards) an embeddable frame. The four card types are summary, summary_large_image, app, and player. Every twitter:* property falls back to its og:* equivalent if missing — except twitter:card itself, which has no fallback and must be set explicitly. They are not a Google or Bing ranking factor. sibling.)

LinkedIn, Slack, WhatsApp, Discord, iMessage

  • LinkedIn is the one non-Meta platform with its own documented numbers: its help page for making a site shareable states a minimum of 1200×627 pixels, a recommended ratio of 1.91:1, and a 5 MB max file size — and separately notes that “images less than 401 pixels wide display as a thumbnail image.” Build to the 1200×630 default and you clear this with margin; don’t confuse it with Facebook’s numbers, they’re LinkedIn’s own. Its Post Inspector is the re-scrape tool.
  • Slack is a placement gotcha more than a size one: it’s widely reported to read only the first ~32 KB of a page’s raw HTML when unfurling. If your head tagsMeta tags are HTML elements in a page's head that pass metadata about the page to search engines and browsers. For SEO only a few matter — the title element, the meta description, and the robots meta tag — while meta keywords and most others are ignored. — and thus your og:image reference — sit below that, Slack may never see them. Slack’s own unfurling docs confirm it reads Open Graph / X Card metadata but don’t publish a byte limit, so treat the 32 KB figure as reported, not officially confirmed.
  • WhatsApp is reported to silently drop the preview image for large files — commonly cited around ~300 KB, even though a higher (~600 KB) “official-sounding” WhatsApp number also floats around. Either way, a heavy image is the failure mode.
  • Discord and iMessage inherit Open Graph with no separately documented image specs — build to the 1200×630 default and they follow.

The honest takeaway: rather than chasing the tightest documented number, target under ~1 MB — ideally 100–300 KB — and you clear every platform’s ceiling with margin.

The absolute-URL rule — a real, silent failure mode

This one is stated as fact everywhere but rarely explained. og:image and twitter:image must be an absolute https://... URL. A relative path like /images/share.jpg isn’t rejected with a visible error — it’s just silently ignored. The reason: a browser resolves a relative path against the page’s own URL because it already knows what page it’s on, but a social crawler fetching your tag has no such base context and won’t reliably reconstruct your domain. So it skips the tag and falls back to whatever else it can scrape. If your image “isn’t showing” and the path in your source starts with a / instead of https://, that’s your bug.

One image, two masters: Google’s 2026 thumbnail spec

Here’s the freshest and least-covered angle. As of March 2, 2026, Google documents og:image as one of two accepted metadata sources (alongside schema.orgSchema markup is code that uses the schema.org vocabulary to label what your content means so search engines can understand it and show rich results. It's most often written in JSON-LD, and it's not a direct ranking factor. primaryImageOfPage) for selecting its own thumbnails in Search and Discover — Google’s own docs describe these two surfaces specifically and don’t extend the claim to AI OverviewsAI Overviews are the AI-generated summary box Google shows above or within its regular search results, written by Gemini models from pages retrieved out of Google's normal Search index. It's a Search feature, not a separate platform or index. or other AI surfaces, so I won’t either. That means the same image file now often has to satisfy both the social platforms and Google’s text-result/Discover thumbnails — and their specs aren’t the same shape.

Google’s image guidance (Discover and Image SEOImage SEO is optimizing the images on your pages so search engines can discover, crawl, index, and rank them — in Google Images and visual search, and as part of standard web results. It spans file format, filenames, alt text, compression, responsive markup, structured data, and image sitemaps. docs):

  • Dimensions: “at least 1200 px wide.”
  • Aspect ratio: a 16:9 ratio — not the social world’s 1.91:1.
  • Resolution: “more than 300,000 total pixels” (a 1280×720 image is 921,600 pixels and clears this comfortably).
  • Content: avoid “a generic image (for example, your site logo) or an image with text,” and avoid “an extreme aspect ratio.”
  • Eligibility prerequisite: to get the large thumbnail treatment in Discover at all you need max-image-preview:large (a robots meta directive) or AMPAMP (Accelerated Mobile Pages) is an open-source web framework Google launched in 2015 to make mobile pages load near-instantly via restricted HTML/CSS/JS and CDN caching. It was never a ranking factor and, since June 2021, is no longer required for Top Stories. — a separate lever from the image file, covered in the robots meta tagThe robots meta tag is an HTML element in a page's head — <meta name=\"robots\" content=\"noindex\"> — that tells search engines how to index and serve that page. It's crawl-then-obey: a page blocked in robots.txt is never fetched, so the tag is never seen. topic.

The nuance to flag rather than hand-wave: a 1200×630 (1.91:1) social image is 630px tall, so it’s 756,000 total pixels — it clears Google’s ≥1200px-wide and ≥300K-pixel bars fine — but 1.91:1 is not 16:9. In practice one well-built image satisfies both, but if you want to optimize each independently you can supply a separate primaryImageOfPage in schema for Google while keeping the 1.91:1 crop for social. Either way, the “no logo, no text-heavy image” advice is good for social CTR too — a logo doesn’t differentiate one shared link from another.

Missing vs. broken — two different failure modes

People conflate these, and they behave differently:

  • The og:image tag is absent. Platforms fall back to a scraped in-body image or a generic default. You get an uncontrolled preview, rarely a truly blank one. (This is the tag-missing case handled in the Open Graph sibling.)
  • The og:image tag is present but the image fails — a 404, an oversized file silently dropped, a wrong MIME type, or a URL blocked by auth or robots.txtA plain-text file at the root of a host that tells crawlers which URLs they may and may not request. It controls crawling, not indexing — a blocked URL can still be indexed if it's linked from elsewhere.. Behavior here is less forgiving: several platforms show no image at all rather than falling back further, because they already “know” you specified one. This is the case unique to this article, so it’s worth stating plainly: a broken image reference can render a worse card than no reference at all.

And the render-vs-crawl gotcha underneath both: most social bots don’t run JavaScript, so if your tag is injected client-side it won’t be seen. As I put it in my Ahrefs JavaScript SEO guide, “Social media bots don’t run JavaScript, so things like OG tags won’t be seen unless you render the content before serving it to them.” Server-render the tag, or the image never had a chance.

Format support

  • JPEG/JPG and PNG are universally supported — safe everywhere.
  • WebP is supported by most modern consumers (Meta lists it explicitly), but I’d keep a JPEG/PNG fallback for anything you can’t test.
  • Animated GIF/WebP are unreliable for a still preview card — most platforms grab a single frame or ignore the animation. Don’t rely on motion in a share image.

Caching — the last mile

Fixing an oversized or broken image doesn’t propagate to links people already shared until you force a re-scrape: the Facebook Sharing Debugger and LinkedIn Post Inspector re-fetch your page and refresh their cached preview. This is the centerpiece of the Open GraphOpen Graph (OG) tags are `<meta>` elements in a page's head, defined by the Open Graph protocol (ogp.me, created by Facebook), that describe a page as a shareable object — its title, description, image, URL, and type. They control how a link preview card looks when the page is shared on Facebook, LinkedIn, Slack, Discord, WhatsApp, and iMessage. They are not a direct Google ranking factor, though Google reads og:title, og:image, and og:site_name as inputs to how a result appears. sibling, so I’ll leave it at one line here: edit the image, then re-scrape, or the old one lingers.

Where this fits

This is a deep dive under the Meta Tags for SEOMeta tags are HTML elements in a page's head that pass metadata about the page to search engines and browsers. For SEO only a few matter — the title element, the meta description, and the robots meta tag — while meta keywords and most others are ignored. hub, sitting right next to the two tag-syntax siblings — Open GraphOpen Graph (OG) tags are `<meta>` elements in a page's head, defined by the Open Graph protocol (ogp.me, created by Facebook), that describe a page as a shareable object — its title, description, image, URL, and type. They control how a link preview card looks when the page is shared on Facebook, LinkedIn, Slack, Discord, WhatsApp, and iMessage. They are not a direct Google ranking factor, though Google reads og:title, og:image, and og:site_name as inputs to how a result appears. and Twitter CardsTwitter Card tags (now often called \"X Cards\") are <meta name=\"twitter:...\"> tags in a page's <head> that tell X's link-unfurling system what rich preview to build for a shared URL — image, headline, description, and (for player cards) an embeddable frame. The four card types are summary, summary_large_image, app, and player. Every twitter:* property falls back to its og:* equivalent if missing — except twitter:card itself, which has no fallback and must be set explicitly. They are not a Google or Bing ranking factor. — that this article extends. It also brushes the separate image SEO cluster (which covers file formats, alt text, and image indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. in general): the difference is that image SEO is about the pictures inside your content, while this is about the one metadata image that represents the whole page in a share card and, now, a Google thumbnail.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.