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

TL;DR — The social sharing image is the picture in the preview card when you paste a link into Facebook, LinkedIn, Slack, or X. You set it with the og:image tag (and twitter:image for X). Make it a full https:// web address, sized about 1200×630 pixels, and keep the file small. If it’s the wrong size, a broken link, or too big, you don’t get a nice card — you get whatever the platform grabs instead.

What the social image is

When you share a link, most apps show a little preview card: a headline, a bit of text, and a picture. That picture is the social sharing image. You tell each platform which image to use with a tag in your page’s head called og:image. X (Twitter) can use a separate twitter:image tag, but if you don’t set one, X just reuses your og:image.

This page is about the image itself — how big it should be, how small the file should be, and what breaks. The tags that point at the image are covered separately in the Open Graph and Twitter Cards topics; here we care about the picture.

The one size to remember

There’s no single official size that every platform agrees on, but one number is the safe default everywhere: 1200 × 630 pixels, a wide rectangle (about 1.91-to-1). Facebook recommends “at least 1200 x 630 pixels,” and that size looks right on LinkedIn, Slack, and X too. Use it and you’ll be fine on almost everything.

Three rules that trip people up

1. Use a full web address, not a relative path. og:image needs a complete https://www.example.com/image.jpg URL. A shortcut like /image.jpg won’t work — the platforms that read your tag can’t figure out your domain on their own, so they just skip it.
2. Keep the file small. Facebook allows up to 8 MB, but other apps quietly drop images that are too heavy. Aim to keep it well under 1 MB — a few hundred KB is plenty for a preview.
3. A missing or broken image isn’t a blank card. If your image is missing, platforms grab some other picture off your page. If your image link is broken (wrong address, blocked, too big), some apps show no picture at all — which can look worse than never setting one.

Why the image sometimes won’t update

If you fix your image but the old one keeps showing when you share the link, that’s caching — the platform saved the old version. You have to ask it to look again using a tool like Facebook’s Sharing Debugger or LinkedIn’s Post Inspector. Same story as with the other social tags.

Want the exact numbers per platform, the file-size caps, Google’s own image rules, and the difference between “missing” and “broken”? Switch to the Advanced tab.

TL;DR — This is the image spec sheet, not the tag syntax — og:image / twitter:image mechanics live in the Open Graph and Twitter Cards 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 crawlers 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. Caching means a fix doesn’t reach already-shared links until you force a re-scrape.

What this article covers (and what the siblings cover)

The tag mechanics — the four required Open Graph properties, name= vs. property=, the four Twitter Card types, and the twitter:image → og:image fallback rule — are already handled in Open Graph Tags and Twitter Card Tags. 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.

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 crawler 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 redirects (HTTP 307) 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 Cards 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 tags — 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.org 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 Overviews 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 SEO 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 AMP — a separate lever from the image file, covered in the robots meta tag 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.txt. 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 Graph 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 SEO hub, sitting right next to the two tag-syntax siblings — Open Graph and Twitter Cards — that this article extends. It also brushes the separate image SEO cluster (which covers file formats, alt text, and image indexing 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.

AI summary

A condensed take on the Advanced version:

• Scope: the image requirements for og:image / twitter:image, not the tag syntax (that’s the Open Graph and Twitter Cards siblings). twitter:image falls back to og:image, so most sites use one image for both.
• Safe default: an absolute HTTPS URL to a ~1200×630px (1.91:1) image — a community-converged compromise, not a single official cross-platform 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 — X’s validator is dead and its docs are gone (paywalled, then a dead redirect).
• Absolute-URL rule: relative paths are silently ignored — social crawlers have no base context to resolve them.
• Missing ≠ broken: an absent tag falls back to a scraped body image; a present-but-failing image (404, oversized, auth/robots-blocked) often shows no image at all.
• Google (March 2026) reads og:image for its own Search and Discover thumbnails (its own docs scope this to those two surfaces, not “AI thumbnails” broadly), but its spec is 16:9 / ≥1200px wide / ≥300K pixels / no logo / no text — a different shape than 1.91:1. A 1200×630 image clears Google’s pixel minimums but isn’t 16:9; needs max-image-preview:large for the large Discover thumbnail.
• Formats: JPEG/PNG universal, WebP mostly fine, animated formats unreliable.
• Rendering: social bots don’t run JavaScript — server-render the tag.
• Practical target: under ~1 MB, ideally 100–300 KB, to clear every platform.
• Caching: fixing the image doesn’t fix already-shared links until you force a re-scrape (Facebook Sharing Debugger, LinkedIn Post Inspector).

Official documentation

Primary-source documentation for the image spec.

Meta / Facebook (the most authoritative source for dimensions and file size)

• Sharing — Images — the ≥1200×630 recommendation, 200×200 minimum, 600×315 floor, 1.91:1 ratio, and the 8 MB file-size cap.
• Sharing — Webmasters — how the crawler scrapes, the first-share caching behavior, and the fallback heuristics when markup is absent.

The Open Graph protocol

• ogp.me — the og:image sub-properties: og:image:url, og:image:secure_url, og:image:type, og:image:width, og:image:height, and og:image:alt.

Google

• Specify a preferred image with metadata — og:image and schema.org as thumbnail-selection sources; avoid logos, text-in-image, and extreme aspect ratios (updated March 2, 2026).
• Google Discover — the concrete image numbers: at least 1200px wide, 16:9, more than 300,000 total pixels, plus the max-image-preview:large / AMP eligibility requirement.

LinkedIn

• Make your website shareable on LinkedIn — LinkedIn’s own numbers: 1200×627 minimum, 1.91:1 recommended ratio, 5 MB max file size, and images narrower than 401px render as a thumbnail.

Slack

• Unfurling links in messages — confirms Slack reads Open Graph / X Card metadata; it does not publish a specific byte or image limit in this doc.

X / Twitter (status: largely inaccessible as of 2026)

• The developer.x.com Cards markup docs returned HTTP 402 (paywalled) in early July 2026 research; as of this update the same URL instead redirects (HTTP 307) to docs.x.com’s homepage, where the equivalent Cards-markup path 404s, and the legacy developer.twitter.com Cards path also redirects and 404s. Either way there’s no live first-party spec to check. Treat every X-specific dimension or file-size figure as third-party consensus — see the Twitter Cards sibling for the full picture.

Quotes from the source

On-the-record statements on the image spec. Each link jumps to (or documents) the quoted passage.

Meta / Facebook — the primary-sourced numbers

• “Use images that are at least 1200 x 630 pixels for the best display on high resolution devices.” — Meta for Developers, Sharing Images docs. Source
• “At the minimum, you should use images that are 600 x 315 pixels to display link page posts with larger images.” Source
• “The minimum allowed image dimension is 200 x 200 pixels.” and “The size of the image file must not exceed 8 MB.” Source

LinkedIn — its own documented minimum

• “Minimum image dimensions: 1200 (w) x 627 (h) pixels”, “Recommended ratio: 1.91:1”, “Max file size: 5 MB”, and “Images less than 401 pixels wide display as a thumbnail image.” — LinkedIn Help, “Make your website shareable on LinkedIn.” Source

Google — og:image as a thumbnail source (March 2026)

• Google influences its automated image selection “by providing your preferred image through one of the following metadata sources” — schema.org primaryImageOfPage or the og:image meta tag. Jump to quote
• “Avoid using a generic image (for example, your site logo) or an image with text in the schema.org markup or og:image meta tag.” Jump to quote
• On Discover, Google says to “use either schema.org markup or the og:image meta tag to specify a large image,” at least 1200px wide, 16:9, and more than 300,000 total pixels. Jump to quote

Barry Schwartz, Search Engine Land — coverage of the March 2026 update

• Reported that Google uses both schema.org markup and the og:image meta tag as sources when determining image thumbnails in Google Search and Discover. Read the coverage

Patrick Stox — the rendering gotcha

• “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.” — from my Ahrefs JavaScript SEO guide. Source

”My image isn’t showing” — is it a size, URL, or cache problem?

Work top to bottom; the first “yes” is almost always your fix.

1. Did you just change the image, and the old one is still showing? → It’s a cache problem. Force a re-scrape: Facebook Sharing Debugger, LinkedIn Post Inspector. Nothing else you do matters until the platform re-fetches.

2. Is the og:image value a relative path (starts with / or ./)? → It’s a URL problem. Social crawlers silently ignore relative paths — change it to a full absolute https://... URL and re-scrape.

3. Is the image tag injected by JavaScript / only present after render? → It’s a rendering problem. Social bots don’t run JS — server-render the tag into the initial HTML.

4. Does the image URL load in a fresh incognito browser (no login)? → If no — 404, requires auth, or blocked by robots.txt — it’s a reachability problem. A present-but-broken image often shows no card image at all. Fix the path or unblock it.

5. Is the file bigger than ~1 MB (or the image over Meta’s 8 MB hard cap)? → It’s a file-size problem. Meta rejects over 8 MB outright; WhatsApp and others silently drop large images well below that. Compress to 100–300 KB and re-scrape.

6. Is the image tiny (under 200×200) or an odd shape? → It’s a dimensions problem. Below 600×315 you get the small/cropped render; below 200×200 Meta rejects it. Rebuild at ~1200×630.

7. Still wrong on Slack specifically, fine elsewhere? → Likely a placement problem — Slack reads only the first ~32 KB of HTML. Make sure your head tags appear early in the document.

If none of these apply and the card is fine except Google’s thumbnail, that’s a different question — see the “one image, two masters” section in Advanced.

Social image cheat sheet

Per-platform spec — sourced honestly

Fast facts

• One safe default clears almost everything: absolute HTTPS URL, ~1200×630 (1.91:1), file 100–300 KB.
• Absolute URL only — relative paths are silently ignored, not errored.
• twitter:image falls back to og:image — one image usually serves both.
• Missing ≠ broken: missing tag → scraped fallback image; broken image → often no image at all.
• Google wants 16:9, social wants 1.91:1 — a 1200×630 image (756K pixels) clears Google’s ≥1200px-wide / ≥300K-pixel bars but isn’t 16:9.
• Formats: JPEG/PNG everywhere; WebP mostly; animated formats unreliable.
• Only Meta’s 8 MB is officially documented — every other byte number is community consensus.
• Fixing the image doesn’t fix shared links until you re-scrape.

Social image audit — checklist

A pass to confirm your share image is correct, reachable, and sized right:

• og:image is an absolute https://... URL — no relative paths.
• The image is roughly 1200×630px (1.91:1) — at least 600×315, never under 200×200.
• File size is under ~1 MB, ideally 100–300 KB, to clear every platform’s ceiling (Meta’s hard cap is 8 MB; others drop large files silently).
• Format is JPEG, PNG, or WebP — not an animated GIF/WebP for a still card.
• The image URL loads in a fresh incognito browser — not 404, not auth-gated, not blocked by robots.txt.
• The og:image tag is in the server-rendered HTML, not injected by JavaScript (social bots don’t render JS).
• The tag sits early in the <head> (helps Slack, which reads only the first ~32 KB).
• twitter:image is either omitted (falls back to og:image) or set deliberately for a different X crop.
• The image avoids a bare logo or heavy text — good for CTR and required for Google’s thumbnail eligibility.
• For Google’s large Discover thumbnail, the page has max-image-preview:large (or AMP).
• After any change, you’ve re-scraped with the Facebook Sharing Debugger / LinkedIn Post Inspector so shared links refresh.

Worked examples

Concrete before/after cases for the failure modes this article covers.

Absolute vs. relative URL

<!-- Silently ignored — a social crawler has no base to resolve this against -->
<meta property="og:image" content="/images/share.jpg" />

<!-- Correct — a full absolute HTTPS URL -->
<meta property="og:image" content="https://www.example.com/images/share.jpg" />

One image for both platforms (using the fallback)

<!-- twitter:image is omitted on purpose; X falls back to og:image -->
<meta property="og:image" content="https://www.example.com/share-1200x630.jpg" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta property="og:image:alt" content="Descriptive alt text for the share image" />

A different, tighter crop for X only

<meta property="og:image" content="https://www.example.com/share-1200x630.jpg" />
<!-- Overrides the OG image on X specifically -->
<meta name="twitter:image" content="https://www.example.com/share-x-1200x675.jpg" />

The two failure modes, side by side

• Missing tag: no og:image at all → Facebook/LinkedIn scrape a body image or show a generic default. Uncontrolled, rarely blank.
• Broken image: og:image points at https://www.example.com/old-hero.jpg which now 404s → several platforms show no card image, because they already “know” you specified one. Worse than never setting it.

Sizing math for the “two masters” question

• Social target: 1200×630 = 1.91:1 = 756,000 total pixels.
• Google’s bar: ≥1200px wide and >300,000 total pixels → the 1200×630 image clears both comfortably.
• Google’s preferred shape: 16:9 (e.g. 1280×720 = 921,600 pixels) — the 1200×630 image satisfies Google’s minimums but is not 16:9, so if you want to optimize each independently, supply a separate primaryImageOfPage in schema for Google.

Confirming a social image fix actually took effect

The caching problem this article describes — you fix the image, but shared links keep showing the old one — means “I edited the file” is not proof of anything. These are the checks to run after a change, in order, before you consider the fix done.

Confirm the platform re-scraped the new image

Test to run: Paste the URL into Facebook’s Sharing Debugger (or LinkedIn’s Post Inspector) and click the re-scrape/inspect button, not just view the cached result. Expected result: the debugger’s preview pane shows the new image, and the tool reports a fresh crawl timestamp. Failure interpretation: if the old image still renders after clicking re-scrape, the platform’s cache hasn’t cleared, or the tag still points at the wrong file. Monitoring window: immediate — the debugger result is live, but other platforms without a public debugger (WhatsApp, iMessage) can take up to a few hours to reflect the change. Rollback trigger: if the debugger shows a Facebook-reported fetch error (not just a stale image) after two re-scrape attempts, revert to the previous known-working image URL while you investigate.

Confirm the URL is absolute and reachable

Test to run: Open the exact og:image URL in a fresh incognito browser window (no login, no cache) — or run curl -I against it and check the status line. Expected result: the image loads directly and returns HTTP/1.1 200 OK; the URL in the address bar is the full https://... path, not a relative one. Failure interpretation: a 404, a redirect to a login page, or a non-200 status means the image is unreachable to the social crawler too — this is the “present but broken” failure mode, which is less forgiving than a missing tag. Monitoring window: immediate — this is a point-in-time reachability check, re-run it right after deploying the fix. Rollback trigger: any non-200 response — revert the og:image value to the last URL that returned 200 until the new asset is confirmed reachable.

Confirm the tag is in the server-rendered HTML, not injected by JavaScript

Test to run: View source (Ctrl+U / Cmd+Option+U) or curl the page and search the raw HTML for og:image — do not check the rendered DOM in DevTools, since that can include JS-injected tags social bots never see. Expected result: the <meta property="og:image" content="https://..."> line is present in the raw, unrendered response body. Failure interpretation: if the tag only appears in the browser’s Elements panel but not in view-source/curl, it’s being injected client-side and social bots — which don’t run JavaScript — will never see it. Monitoring window: immediate, and worth re-checking after any deploy that touches the templating or hydration layer. Rollback trigger: the tag missing from raw HTML on two consecutive curl checks — treat the templating change as broken and revert it.

Confirm dimensions and file size clear platform limits

Test to run: Check the deployed image’s actual pixel dimensions and file size (image-inspector tool, browser dev tools’ Network panel, or curl -sI for Content-Length). Expected result: roughly 1200×630px (1.91:1, at least 600×315, never under 200×200) and a file size under ~1 MB — ideally 100–300 KB. Failure interpretation: dimensions under 600×315 trigger the small/cropped render; a file size approaching or over Meta’s 8 MB hard cap gets rejected outright, and other platforms silently drop heavy files well below that. Monitoring window: immediate — this is a static property of the deployed file, not something that changes over time. Rollback trigger: file size over roughly 1 MB or dimensions below the 600×315 floor — swap in a compressed, correctly-sized image before re-scraping.

Resources worth your time

My related writing

• JavaScript SEO Issues & Best Practices — the rendering side: why social bots that don’t run JavaScript never see a client-injected og:image.
• The Beginner’s Guide to Technical SEO — where on-page metadata like share images fits in the bigger picture.

My speaking

• How Search Works (SlideShare) — my walkthrough of crawling, rendering, and indexing, including why the crawl-vs-render distinction decides whether a metadata tag is even seen. (My standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)

Official

• Meta — Sharing Images — the only primary-sourced dimension and file-size spec (≥1200×630, 200×200 min, 600×315 floor, 1.91:1, 8 MB cap).
• The Open Graph protocol — the og:image sub-properties.
• Google — Specify a preferred image with metadata and Google Discover — Google’s own thumbnail image requirements.
• Slack — Unfurling links in messages — confirms Slack reads OG / X Card metadata.

From around the industry

• Google uses both schema.org markup and og:image meta tag for thumbnails in Google Search and Discover (Search Engine Land, Barry Schwartz, March 2, 2026) — same-day coverage of the March 2026 doc update.
• Google Clarifies How It Picks Thumbnails For Search, Discover (Search Engine Journal) — the companion write-up on the same update.
• Open Graph Meta Tags: Everything You Need to Know (Ahrefs, Michal Pecánek) — a solid general Open Graph reference (not my byline).
• r/TechSEO — the community for debugging broken previews and re-scrape issues.

Test yourself: Social Sharing Images

Five quick questions on og:image and twitter:image requirements. Pick an answer for each, then check.

Social sharing image

The social sharing image is the picture that appears in the link-preview card when a URL is shared on Facebook, LinkedIn, Slack, Discord, WhatsApp, iMessage, or X — set by the og:image Open Graph property (read by nearly every platform) and, on X specifically, by twitter:image (which falls back to og:image if omitted). The cross-platform safe spec is an absolute HTTPS URL pointing to an image around 1200×630px (1.91:1), kept well under each platform's file-size ceiling.

Related: Open Graph, Twitter Card tags, Meta Tags

Social sharing image

A social sharing image is the picture that shows up in the link-preview card when someone pastes your URL into Facebook, LinkedIn, Slack, Discord, WhatsApp, iMessage, or X. It’s set by the og:image Open Graph property — read by nearly every consumer platform — and, on X specifically, by twitter:image, which falls back to og:image when it’s absent. (The tag syntax lives in the sibling Open Graph and Twitter Cards topics; this is about the image the tag points at.)

The practical spec that survives across almost every platform: an absolute HTTPS URL pointing to an image around 1200×630px (1.91:1 aspect ratio), kept well under each platform’s byte ceiling. Facebook/Meta documents a recommended size of “at least 1200 x 630 pixels,” a 600×315 floor to avoid the small-image rendering, a 200×200 hard minimum, and an 8 MB file-size cap; other platforms’ numbers (X’s ~5 MB, Slack’s early-HTML read limit, WhatsApp’s silent drop of large images) circulate as community consensus rather than freshly-verifiable first-party specs.

Get the URL, size, or format wrong and you don’t get a blank card — you get whatever a platform’s fallback heuristic scrapes instead (a logo, a random in-body image, or nothing at all), which is why “my image isn’t showing” is almost always a spec or caching problem, not a missing-feature problem. As of March 2026, Google also reads og:image as one accepted source for its own Search and Discover thumbnails (Google’s own docs scope this to those two surfaces, not a broader “AI thumbnails” claim) — so one image now often has to satisfy both social platforms and Google, and LinkedIn documents its own minimum directly (1200×627px, 1.91:1, 5 MB cap) rather than simply inheriting Facebook’s numbers.

Related: Open Graph, Twitter Card tags, Meta Tags

Changelog