OGKit

One set of OG tags, eight different cards: how Facebook, LinkedIn, X, and peers really render your preview

· 10 min read

  • open-graph
  • social-preview
  • platform-differences
  • truncation

The mockup has one 1200×630 share image, a title, and a description. It looks perfect. Then it ships: the description vanishes on LinkedIn, the image never renders on WhatsApp, the title clamps to two lines with an ellipsis on X, and Slack letterboxes the image you designed to be edge-to-edge.

Your tags are not wrong. The platform draws the card, not you. The same HTML gets scraped by eight platforms that each pick their own fields, truncate at their own limits, and crop by their own rules. This post turns those differences into matrices you can design against.

The boundary first — the same one our own product keeps: every third-party preview (including OGKit) is an approximation; the authority is always each platform's official debugger. So every number below carries a source tier:

  • official — stated in the platform's own docs
  • community — widely reproduced consensus, never confirmed officially
  • measured — community measurement convention, not a guarantee
  • unverified — nobody has checked; do not quote it as fact

The numbers come from OGKit's platform profiles (the PlatformProfile records in core, shared by the rule engine and the preview renderer); appearance details like title line clamps come from the preview layer's per-platform replicas. When a number goes stale, the profile page moves with the data source.

First: these are not even the same kind of "card"

The eight platforms render three structural families. Many "differences" are structural, not parametric:

Family Platforms What it looks like
stacked Facebook, X, LinkedIn, WhatsApp Media on top, text below; the image is usually cropped to fill a banner
attachment Slack, Discord, Telegram Not a card — a message attachment: a rail on the left, text first, image below the text, aspect ratio preserved
search Google No card at all: site name + breadcrumb + blue headline + snippet, with at most a small square thumbnail on the right

Keep this table in mind so the numbers below read correctly: Slack "not cropping" your image is not a bug, and Google's "tiny image" is not one either.

Matrix 1: field priority — who reads your tags, in what order

The fallback chain differs per platform. The big one: X reads twitter:* first, while the Meta family ignores it entirely.

Platform Title field priority Reads twitter:* What the site row shows Source
Facebook og:title → <title> No Hostname (upper-cased) community
X twitter:title → og:title → <title> First Hostname official (field priority)
LinkedIn og:title → <title> No Hostname community
Slack og:title → twitter:title → <title> Fallback og:site_name + favicon community
Discord og:title → twitter:title → <title> Fallback og:site_name (provider slot) community
WhatsApp og:title → <title> No Hostname (small, at the bottom) community
Telegram og:title → twitter:title → <title> Fallback og:site_name (brand blue) community
Google og:title → <title> (plus broader signals) No og:site_name + breadcrumb community

Two actionable conclusions:

  1. og:site_name is not decorative — Slack, Discord, Telegram, and Google put it in the most prominent row of the card, while the Meta family shows only the hostname. Skip it and you lose a row of branding in every chat app.
  2. twitter:* is still worth writing. X prefers it, and Slack / Discord / Telegram fall back to it. With only og:* you give up separate control of title and image on X.

Matrix 2: text truncation — how long your title and description survive

"Characters" are soft-limit estimates from the platform profiles; "lines" are render-layer clamps. Both apply at once — whichever triggers first produces the ellipsis.

Platform Title chars Title lines Description chars Description lines Source
Facebook ≈60 2 ≈200 3 community
X ≈70 2 ≈200 2 community
LinkedIn ≈150 2 not shown — chars: community; dropped: community replica
Slack unverified 3 unverified — —
Discord 256 3 4096 — community (embed limits)
WhatsApp ≈65 2 ≈160 2 community
Telegram unverified 3 unverified — —
Google ≈60 1 ≈160 — community

Ranked by how counterintuitive they are:

  • LinkedIn drops og:description entirely. The feed card shows the title and the domain — nothing else. For a LinkedIn-heavy audience, the title must carry the whole message.
  • Google gives the title a single line. A 20px blue headline, single-line clamp — harsher than any social card.
  • Discord is the most generous with text: 256 / 4096 are embed-protocol limits, and long descriptions really do expand — which makes it the easiest place to proofread your own copy in full.
  • Slack and Telegram publish no character budget (unverified); truncation is purely container-width. Do not quote any "Slack titles cap at 100 characters" claim, including from second-hand blogs.

Practical rule: a title under 60 characters survives Facebook and Google simultaneously; front-load the key words into the first 65 and WhatsApp won't cut to the bone either.

Matrix 3: images — cropping, degradation, and byte budgets

The biggest myth of "one image for every platform": only the stacked family crops at all, and their degradation thresholds and byte budgets are completely different.

Platform Slot & crop When the source is small Byte budget Source
Facebook 1.91:1, cover, center-crop <600px wide: degrades to a small square beside the text 8MB official (size/budget); threshold: official
X ≈1.91:1, cover, center-crop <300×157: falls back to the summary square card 5MB community
LinkedIn 1.91:1, cover, center-crop <200px wide: image dropped entirely 5MB community
Slack contain, no crop, max 360px wide scaled down, ratio preserved not published community
Discord contain, no crop, max 400px wide ratio preserved 8MB community
WhatsApp ≈1.91:1, cover, center-crop <300px wide: 60px thumbnail ≈300KB (soft ≈200KB) measured (community consensus, not official)
Telegram contain, no crop, max 320px wide ratio preserved 5MB community
Google 1:1 square, cover, center-crop <1200px wide: no image at all not published community

Three conclusions worth the most:

  1. WhatsApp's byte budget is the binding constraint. ≈300KB is a measured community consensus, not an official promise — but "large PNG silently fails to preview on WhatsApp" is a constantly reproduced phenomenon. A 1200×630 PNG easily exceeds 1MB. For cross-platform stability, use JPEG and keep the file under 300KB: one image then satisfies the strictest platform.
  2. Google's square crop defines the safe zone. It wants a source ≥1200px wide but displays a square center-crop, while Facebook / X / LinkedIn crop to 1.91:1. To survive both, important content must sit in the intersection of the two crops — the center of the frame.
  3. LinkedIn and Google punish small images with deletion, not shrinkage. Below their thresholds there is no thumbnail at all; the card degrades to pure text.

Matrix 4: cache and official tools — where to finalize after previewing

Third-party previews (including our own multi-platform preview) are for day-to-day QA. After changing an image, only the official entry points can clear the platform's own cache.

Platform Official entry Cache refresh Source
Facebook Sharing Debugger "Scrape Again" forces a re-fetch; TTL not publicly documented (unverified) official
LinkedIn Post Inspector Submitting re-fetches; TTL often cited as ≈7 days official (tool) / community (TTL)
X Card Validator (availability varies; check current state) Often cited ≈7 days, not officially fixed community
Slack No public debugger Re-share the link community
Discord No public debugger Change the URL query string to bust cache community
WhatsApp No public debugger Wait, or change the URL community
Telegram No web debugger Message @WebpageBot to force a refresh community (practice)
Google Rich Results Test Search Console → request indexing official

The full per-platform entry list (paste a URL, get pre-built debug links) lives in the rescrape helper. Cache and rescrape strategy is the subject of entry 05 in this series.

Design checklist: one image, eight gates

Combining the matrices above, the constraints for a cross-platform share image fall out like this:

  • 1200×630 (1.91:1) — Meta's official recommendation; X / LinkedIn / WhatsApp share the slot; Google also asks for ≥1200px wide
  • Key text and logo in the central safe zone — the intersection of the 1.91:1 banner crop and the 1:1 square crop; keep only expendable texture near the edges (this is a design constraint derived from matrix 3, not any platform's written rule)
  • Keep text off the edges — X's rounded corners eat the image corners, and WhatsApp insets the media on all four sides
  • Check contrast on white and on black — Discord defaults to dark; dark text on a dark image disappears
  • Prefer JPEG, ≤300KB total — satisfies WhatsApp's measured budget; every other platform is more permissive
  • Image URL absolute HTTPS, plain 200 — authenticated image hosts and multi-hop 302s hand crawlers a 403 (troubleshooting order in entry 04 of this series, planned)
  • Title ≤60 chars, key information first; write the description in full but never depend on it — LinkedIn won't show it at all

Cross-validate instead of cross-quoting rumors

The recommended workflow, from mockup to production:

  1. Drafting: use a multi-platform preview component (@ogkit/preview — also the rendering layer inside the OGKit extension and web scan) to see all eight cards side by side. Every number links back to the profile data source, and the structure replicates the real layout — but remember its role: an approximation for everyday QA.
  2. When a number matters: open the matching platform profile page and check its source tier and verification date. "Official" is safe to rely on, "community" needs context, "unverified" means measure it yourself first.
  3. Finalizing: run the live URL through every official tool in matrix 4. Only what you see there is what the platform's cache actually holds.

Next steps