Social meta tags are how the page introduces itself in a share:
When someone pastes a link into Slack, sends it through iMessage, or shares it on LinkedIn, the rich preview that appears (image, title, and short description) isn’t pulled from the page’s body. It’s pulled from social meta tags in the page’s HTML head. These tags exist for one reason: to control how the page looks the moment it leaves the page.
Most sites rely on automatic fallbacks. The browser title becomes the share title. The first image on the page becomes the share image. The meta description becomes the share description. The result is usually wrong in small ways. The chosen image isn’t the most representative one. The fallback title is too long for the share card. The description doesn’t match what the sharer wants their audience to see.
Social meta tags are the page’s chance to choose. Two standards cover most of the surface: Open Graph and Twitter Cards. The first works almost everywhere. The second adds platform-specific control where Twitter (now X) reads it.
Open Graph: the format everyone reads:
Open Graph was published by Facebook in 2010 as part of building a richer social graph. The format defines a set of meta tags placed in the HTML head, each labeled with a property name prefixed by og:. Almost every modern platform that generates link previews reads these tags.
The four tags that matter most:
<meta property="og:title" content="How social meta tags work">
<meta property="og:description" content="The HTML tags that control how a link looks when shared.">
<meta property="og:image" content="https://example.com/social/og-image.jpg">
<meta property="og:url" content="https://example.com/blog/social-meta-tags">Each tag does one job. The title is what the share card displays as the headline, distinct from the browser title tag. The description is the short blurb under the title, distinct from the SEO meta description. The image is the visual the card uses, which the platform fetches and caches. The URL is the canonical destination, which prevents tracking parameters or shortened links from polluting the preview.
The Open Graph specification also defines og:type (e.g. website for general pages, article for posts, video.movie for media). Modern platforms render previews without it, but Facebook’s own crawler treats it as required and the broader article: namespace (article:published_time, article:author, article:section) gives Facebook additional structured context for blog content. Adding og:type and the article subtags on content pages costs nothing and improves how some platforms (and AI summarizers) classify the page.
A page without Open Graph tags still loads normally; it just hands the platforms permission to guess what the share preview should look like. Sometimes the guess is fine. Often it isn’t.
Open Graph is read by Facebook, LinkedIn, WhatsApp, iMessage, Slack, Discord, Microsoft Teams, Reddit (when previews are enabled), and most major email clients that render link previews. The format functions as the default standard for social previews across the web. Even platforms that have their own card system tend to fall back to Open Graph when their proprietary tags aren’t present.
Twitter Cards: the format X still reads, mostly:
Twitter Cards predate Twitter’s rename to X and operate as an extension of Open Graph. The tags use a twitter: prefix and define a card type plus a few platform-specific properties:
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="How social meta tags work">
<meta name="twitter:description" content="The HTML tags that control how a link looks when shared.">
<meta name="twitter:image" content="https://example.com/social/twitter-image.jpg">
<meta name="twitter:site" content="@example">The twitter:card property names the card layout. Four types exist:
| Card type | What it shows | When to use |
|---|---|---|
| <!–INLINECODE12–> | Small square image left, title and description right | Default for blog posts and articles where the image is secondary |
| <!–INLINECODE13–> | Large image above title and description | Content where the image carries weight: features, photo essays, hero imagery |
| <!–INLINECODE14–> | App icon, description, and direct download links | Promoting mobile apps with platform-specific install paths |
| <!–INLINECODE15–> | Embedded video or audio player | Media content the platform should play inline |
The twitter:site property attributes the share to a specific X account, which sometimes appears in the card footer. Some accounts also include twitter:creator for the individual author.
In practice, X falls back to Open Graph tags when Twitter-specific tags aren’t present. A page with full Open Graph and no Twitter Cards still produces a serviceable card on X, just without the explicit card-type selection. Going the other way produces worse results: Twitter Cards without Open Graph often render nothing at all on platforms outside X. The pragmatic approach is to write Open Graph first and add Twitter Cards only when the page benefits from specific card-type control.
Images carry the click:
The image is the part of the social preview readers see first. Dimensions, format, and content choice carry most of the visual weight of the preview, more than the title and description text do.
The current standards across platforms:
| Property | Specification |
|---|---|
| Recommended dimensions | 1200 × 630 pixels |
| Aspect ratio | 1.91:1 |
| Minimum dimensions | 600 × 315 pixels |
| Maximum file size | 5 MB (varies by platform) |
| Format | JPG or PNG (PNG for graphics with text, JPG for photos) |
The 1200 × 630 standard works for Facebook, LinkedIn, Twitter’s summary_large_image card, Slack, Discord, and most other consumers. Below 600 × 315, platforms downgrade to small-card layouts that bury the image. Above 1200 × 630 isn’t penalized but adds load weight without visible benefit.
Content choice shapes performance. Three patterns work consistently:
The faces pattern. Images with human faces draw more attention than abstract graphics, especially when the face takes up enough of the frame to register at small sizes. Personal stories, interview pieces, and op-eds benefit from a portrait of the subject.
The text-overlay pattern. A short overlay of three to five words can summarize the piece at a glance. Useful for sites where the title alone might not communicate the angle. Keep the text large enough to read at thumbnail size, since most social feeds compress preview images significantly.
The graphical signature pattern. A site that uses a consistent visual treatment (brand color, typography choice, layout grid) creates instant brand recognition in shares. Readers learn to spot the site in their feed before reading the title.
The failure modes are equally consistent. A logo on a flat background as the share image (no information, no draw). A screenshot of the page itself (recursive, low signal). A stock photo loosely related to the topic (signals nothing about what the piece actually is). The image is editorial. Treat it as part of the writing.
Titles and descriptions: the silent rewrite:
Social titles and descriptions need to do a different job than their SEO counterparts. The SEO meta description sits inside a search results page, where the reader is actively comparing options. The social description sits inside a friend’s feed or a colleague’s Slack channel, where the reader’s attention is fragmented and the share is competing with everything else on screen.
Three writing patterns work in practice:
| SEO version | Social version | Why the social version works better |
|---|---|---|
| "Complete guide to writing meta descriptions for higher CTR" | "The lines we rewrote that lifted click-through across our top articles" | Specificity invites curiosity; "the lines we rewrote" implies a story worth opening |
| "Best practices for technical SEO in 2026" | "Most technical SEO advice from earlier years still applies. A few things changed." | The framing assumes the reader knows the topic; the angle is what changed |
| "How to migrate to HTTPS without losing rankings" | "Migration sounds simple. Several sites we know lost real traffic until they fixed the gap." | A concrete narrative hook outperforms a generic how-to promise |
Length conventions differ by platform. Open Graph descriptions display fully up to roughly 200 characters on most platforms. Twitter Cards truncate descriptions after the same threshold on the cards themselves. Slack and Discord show more, up to 300 characters before collapsing. Writing to the shorter limit and letting longer descriptions work where they fit is the safer default.
A practical note: social titles do not need to match SEO titles. A page can have a search-optimized title tag pointing at the primary query, and a separate Open Graph title aimed at the social context. The page hasn’t changed. The framing has, for two audiences who arrive through different doors.
Apps and Slack and Discord, where the standard pays off:
Open Graph and Twitter Cards were designed for social networks, but the formats have become the default for any platform rendering link previews. The reach extends well past the original use cases.
Messaging apps render previews on link paste. Slack, Discord, Microsoft Teams, Telegram, iMessage, WhatsApp, all read Open Graph by default. The same tags that control a Facebook share also control the preview a colleague sees when a link gets dropped into a channel.
Email clients increasingly render link previews. Gmail web, Outlook desktop, Apple Mail, and several mobile clients pull Open Graph data when a sender pastes a URL into a message body. The preview that appears in the recipient’s inbox uses the page’s social meta tags.
AI assistants reference link previews when summarizing shared URLs. When a user pastes a link into ChatGPT, Claude, or a similar system, the model fetches the page’s content (which often includes Open Graph data) as part of building context. The same tags that control a social card can influence how AI systems represent the page.
Browser-based reading apps (Pocket, Instapaper, Notion’s web clipper) use Open Graph to populate saved-link metadata. The image, title, and description in a user’s reading list pull from the source page’s Open Graph tags.
The compounding effect: a single well-written set of social meta tags works across many platforms simultaneously, including platforms that didn’t exist when Open Graph was first published. The investment is small. The reach is broader than the original Facebook use case implied.
Multiple pages, one template, with overrides where they earn the work:
For a site with hundreds or thousands of pages, hand-writing every Open Graph tag set isn’t realistic. Most CMS platforms generate social meta tags automatically from page content. The title pulls from the article headline. The description pulls from the meta description. The image pulls from a featured image field. The URL pulls from the canonical.
The default works for most pages on most sites. Three categories of page benefit from explicit overrides:
Cornerstone content. Pillar articles, hero landing pages, and high-impression evergreen pieces deserve hand-written social titles and a custom social image. The traffic these pages produce justifies the investment of separate copy.
Pages with weak default images. If a CMS pulls the first inline image as the share image, and the first inline image is a decorative icon or an unflattering hero shot, the social preview suffers. Pages without a strong native image benefit from a dedicated social image even if the post body uses different visuals.
Pages where the SEO title and the social hook differ. An article titled “Migration timeline for our database upgrade” makes sense as an SEO title for engineers searching the topic. The same page might share more effectively on social as “We rewrote our database in 47 hours. Most of it was the wrong call.” Both can coexist, with the title tag handling search and the Open Graph title handling shares.
The template-plus-override pattern handles scale without sacrificing control. The CMS generates social meta tags for every page by default. Editors override the title, description, or image on specific pages where the default falls short.
Three validators, one source of truth:
Validation matters because Open Graph and Twitter Card tags fail quietly. A typo in a property name doesn’t break the page, it just makes the preview wrong without warning. Three tools cover most validation work.
Facebook’s Sharing Debugger fetches the page and reports what Open Graph tags it detects, what the rendered card looks like, and any errors or warnings. The tool also lets the operator force Facebook to re-crawl after changes, which helps when an old preview gets cached. Even for sites that don’t actively promote on Facebook, the Sharing Debugger is useful because it represents what most Open Graph consumers see.
X no longer provides an official Card Validator. The cards-dev.twitter.com tool was deprecated in 2022 and was not replaced after the rename to X. Third-party validators (search “Twitter card validator” or “X card validator”) fill the gap, and the in-app Tweet Composer also renders a card preview when a URL is pasted, which functions as the most accurate live check available now.
LinkedIn’s Post Inspector renders the LinkedIn-specific preview, which sometimes differs from Facebook’s even when both read Open Graph. LinkedIn often interprets og:image more strictly than Facebook does, particularly for dimensions and aspect ratio.
For local testing during development, browser extensions like Open Graph Preview and Meta Tag Manager show the parsed tags directly from any URL. For automated checks at scale, headless browser scripts can fetch every page’s HTML, parse the meta tags, and flag pages with missing required tags or with images that fail to load.
Validation isn’t a one-time task. CMS upgrades, theme changes, and plugin updates can quietly drop or rewrite social meta tags. The pages most likely to be checked are the cornerstone pieces, and the pages most likely to be silently broken are the long-tail articles. Periodic audits catch the gradual drift.
Seven social meta anti-patterns:
The failure modes that produce bad share previews are repetitive enough that most sites encountering one are encountering one of these.
- No social tags at all. The page produces unpredictable previews based on platform fallbacks. Fix: add the four core Open Graph tags (
og:title,og:description,og:image,og:url) at minimum on every public page.
- Default image as logo on flat background. Every share looks identical, with no editorial signal about what the specific page covers. Fix: generate or commission page-specific share images. A template that takes the post title and renders it over a brand background works for sites publishing at scale.
- Image too small. Below 600 × 315 pixels, platforms downgrade to small-card layouts. The reader sees a thumbnail instead of a feature image. Fix: standardize on 1200 × 630 as the minimum dimension for social images.
- Description duplicates the title. Reader sees the same words twice in one card. Fix: the social description should extend or contextualize the title, not repeat it.
og:urlmissing or wrong. Tracking parameters get included in the canonical URL, which fragments preview cache across what should be the same page. Fix: setog:urlto the clean canonical URL, the same one declared in<link rel="canonical">.
- Twitter Cards without
twitter:cardtype. The platform defaults to smallsummarycard even when the page would benefit fromsummary_large_image. Fix: explicitly declare the card type withtwitter:card. For visually driven content,summary_large_imageis almost always the right choice.
- No revalidation after publishing. Platforms cache previews aggressively. A page changed after first share keeps the old preview indefinitely until forced to re-fetch. Fix: after meaningful changes, run the page through Facebook’s Sharing Debugger to force a re-crawl, and use the in-app Tweet Composer or a third-party validator to confirm the X-side card preview.
An eighth pattern worth flagging: emoji in social titles. Some platforms render them, others strip them, and the inconsistent display across surfaces undermines a controlled brand presentation. Use sparingly, if at all.
The same page, four different doors:
A page on the web has more entry points than its visitors usually consider. Search results pages bring readers in through the title tag and meta description. Direct links bring them in through the browser tab title. Social shares bring them in through Open Graph and Twitter Cards. AI assistants and reading apps bring them in through whichever metadata signals are clearest.
Each door deserves its own writing.
Underneath the four doors sits a fifth layer: how the page appears when a system aggregates many shares of the same URL. Slack channels with link unfurls, email digests with curated reading, AI summarization of a week’s saved articles. All draw from the same Open Graph data, multiplied across contexts the page author never directly composed for.
Underneath that sits a sixth: machines reading machines reading the page. A future AI system summarizing what a website covers may rely partly on the Open Graph descriptions across its top pages. Those descriptions were written for short-form display and tend to be cleaner than the article bodies. The tags that started as a Facebook convention now serve as a structured executive summary for anything that needs to represent the page concisely.
Each layer compounds. A page that handles all of them (search title, browser title, social title, AI excerpt) gets quoted, shared, and summarized accurately in more contexts. A page that handles only the first layer gets quoted, shared, and summarized however the systems decide. The choice is whether to write each door deliberately or let the defaults answer.