Open Graph and social cards: making shared links look right

What Open Graph does (and what it does not)

When someone pastes a link into a post or a chat, the platform sends its own crawler to fetch the page. The crawler reads the HTML and builds a link preview, also called a card: an image, the site name, a title and a short description. Open Graph is the vocabulary that tells the crawler which values to use. In the protocol's own words, “The Open Graph protocol enables any web page to become a rich object in a social graph.”

Without these tags the crawler guesses. Meta describes exactly that: “Without these Open Graph tags, the Facebook Crawler uses internal heuristics to make a best guess about the title, description, and preview image for your content.” In practice the guess is often a logo, a cookie-banner sentence or an icon from the footer.

Two limits are worth stating plainly. First, Open Graph does not change your position in Google. Its value is the click-through rate from shares, and that is real traffic. Second, Google does read og:title, but only as one of many inputs for the title link in search results, next to the <title> element, the H1 and anchor text. The lesson Title tags covers how those title links are built.

What the official sources say

Open Graph is an open protocol published at ogp.me. Meta, LinkedIn and X each document how their own crawler reads it. These are the sentences that matter most, quoted word for word.

The four required properties

The protocol is direct about the minimum: “The four required properties for every page are:” og:title, og:type, og:image and og:url. Here is how ogp.me defines each one, and what that means for your pages.

• og:title is “The title of your object as it should appear within the graph”. Meta adds a practical rule: “The title of your article without any branding such as your site name.” The platform already shows the domain or site name, so a | Example Shop suffix only wastes space.
• og:type is the kind of object. “Depending on the type you specify, other properties may also be required.” Use website for the home page and general pages and article for posts and news. Meta treats a missing type as website.
• og:image is “An image URL which should represent your object within the graph.” It has to be a full, publicly reachable URL that starts with https://.
• og:url is “The canonical URL of your object that will be used as its permanent ID in the graph”. Meta is more specific: “This should be the undecorated URL, without session variables, user identifying parameters, or counters.” Shares and likes are counted against this URL.

The syntax uses the property attribute, not name, and every tag belongs in the server-rendered <head>:

<meta property="og:title" content="How to bake sourdough at home">
<meta property="og:type" content="article">
<meta property="og:image" content="https://example.com/og/sourdough.jpg">
<meta property="og:url" content="https://example.com/blog/sourdough/">

LinkedIn's list of what it needs is slightly different. Its help page says “Below are the og: tags that must exist and their correct format” and lists og:title, og:image, og:description and og:url. So in practice treat og:description as required too.

Recommended extras

The protocol calls a second group of properties optional but “generally recommended”. These are the ones worth adding to every template:

• og:description: “A one to two sentence description of your object.” Write it for a person scrolling a feed, not as a keyword list.
• og:site_name: “If your object is part of a larger web site, the name which should be displayed for the overall site.” This is where your brand goes instead of the title.
• og:locale: “The locale these tags are marked up in.” The format is language_TERRITORY, such as en_GB, and the default is en_US. Add og:locale:alternate for each other language version of the page.
• og:image:width and og:image:height: the size in pixels. Meta's reason to add them: “Specify height and width for your image to ensure that the image loads properly the first time it's shared.”
• og:image:alt: “A description of what is in the image (not a caption). If the page specifies an og:image it should specify og:image:alt.”
• og:image:secure_url and og:image:type: an HTTPS address and the MIME type, for example image/jpeg. If og:image is already HTTPS, the secure URL simply repeats it.

Order matters. Image properties describe the image declared just before them: “Put structured properties after you declare their root tag.” If you list several images, the first one is preferred, so the image you want on the card goes first. For articles, you can also add article:published_time and article:author from the article type.

<!-- required -->
<meta property="og:title"
      content="How to bake sourdough at home">
<meta property="og:type" content="article">
<meta property="og:url"
      content="https://example.com/blog/sourdough/">
<meta property="og:image"
      content="https://example.com/og/sourdough.jpg">
<!-- describe the image right after it -->
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt"
      content="Sourdough loaf on a wooden board">
<!-- recommended -->
<meta property="og:description"
      content="Timings, flour ratios and photos.">
<meta property="og:site_name" content="Example Kitchen">
<meta property="og:locale" content="en_GB">

<!-- the only tag X needs on top of OG -->
<meta name="twitter:card"
      content="summary_large_image">

<!-- optional attribution -->
<meta name="twitter:site" content="@example">
<meta name="twitter:creator" content="@author">

<!-- only if X should differ from OG -->
<meta name="twitter:title" content="…">
<meta name="twitter:image" content="…">

X (Twitter) card tags and the fallback to Open Graph

X has its own tags with the twitter: prefix, but it reads Open Graph when they are missing. Its documentation is explicit that you do not need to duplicate anything: “Twitter's parser will fall back to using property and content, so there is no need to modify existing Open Graph protocol markup if it already exists.”

The card type is the one value with no Open Graph equivalent. twitter:card takes one of four values: summary (small thumbnail next to the text), summary_large_image (full-width image), app and player. “Only one card type per-page is supported.” If you leave it out, X decides for you: “If an og:type, og:title and og:description exist in the markup but twitter:card is absent, then a summary card may be rendered.” That is why so many links on X show a small square instead of the large image you designed.

The other tags are optional: twitter:site and twitter:creator for the account handles, and twitter:title, twitter:description, twitter:image and twitter:image:alt only when the X version should differ from Open Graph. Note the attribute: X tags use name, Open Graph uses property.

Image size and ratio: what each platform documents

The image causes most preview problems, so it helps to know exactly what each platform publishes. The numbers below are each platform's own; nothing is averaged or invented.

Meta: “The minimum allowed image dimension is 200 x 200 pixels.” “The size of the image file must not exceed 8 MB.” “Use images that are at least 1200 x 630 pixels for the best display on high resolution devices.” And on shape: “Try to keep your images as close to 1.91:1 aspect ratio as possible to display the full image in Feed without any cropping.”

X, for the large image card: “Images for this Card support an aspect ratio of 2:1 with minimum dimensions of 300x157 or maximum of 4096x4096 pixels.” Also: “Images must be less than 5MB in size.” JPG, PNG, WEBP and GIF are accepted, “Only the first frame of an animated GIF will be used.” and “SVG is not supported.”

LinkedIn lists a 5 MB maximum, a minimum of 1200 × 627 pixels and a recommended ratio of 1.91:1 for its sharing module.

One image that works everywhere

A 1200 × 630 pixel JPG or PNG meets Meta's recommendation, clears LinkedIn's 1200 × 627 minimum and sits close enough to X's 2:1 that only a thin strip is trimmed. Keep the file well under 1 MB in practice: messengers fetch the image while the user waits, and slow, heavy images are the first thing they skip. Keep the headline and any logo inside a central safe zone, because some surfaces crop to a square thumbnail.

Make the image specific to the page. X says it plainly: “You should not use a generic image such as your website logo, author photo, or other image that spans multiple pages.” A site-wide default image is a fallback, not a strategy. For alt text, formats and compression in general, see the lesson Images: alt, formats, sizes, lazy loading.

Messengers and Slack

Telegram, WhatsApp, Slack, Discord, iMessage and Viber all build their previews from the same Open Graph tags. None of them publishes a full specification, so what follows is practice, not documentation:

• They read the server HTML only. These fetchers do not run JavaScript. Tags added by a client-side framework after load are invisible to them.
• They are impatient. If the page or the image answers slowly, the preview is dropped or shown without an image. WhatsApp is especially sensitive to large images.
• Thumbnails are small. Many chat apps show a square or a narrow strip, so text on the image must be large and centred.
• Slack reads more. It uses oEmbed and twitter: tags as well as Open Graph, and it can show extra labelled fields.
• Who fetches differs. Some apps fetch on the sender's device, others on their servers. Either way, firewalls and bot protection that block unknown user agents break the preview.

Caching and how to refresh a preview

Every platform caches what it fetched, which is why a fixed tag can still show the old preview. Meta explains the first share: “The crawler has to see an image at least once before it can be rendered.” And for images in particular: “Images are cached based on the URL and won't be updated unless the URL changes.” X works the same way: “Content is cached by Twitter for 7 days after a link to a page with card markup has been published in a Tweet.” and “Images referenced in a Card are also cached based on URL.”

Facebook: Sharing Debugger

Paste the URL into the Sharing Debugger at developers.facebook.com/tools/debug/. It shows the tags the crawler read, warnings and the preview. “The debugger also triggers a scrape of your page, so if you do have errors in your HTML you can use the debugger to update your content.” Click Scrape Again after each fix. Posts that already exist do not change: “Note that updating the image for a URL will not automatically update the preview for old shares.”

LinkedIn: Post Inspector

“You can use the Post Inspector as a tool to refresh the URL.” Enter the URL at linkedin.com/post-inspector/ and check the preview. Existing posts keep what they had: “The preview for any existing posts with this URL will remain the same.” LinkedIn also warns: “If you're a developer and have recently updated tags on a site, please wait 48 hours for your changes to take effect.”

X, messengers and Slack

X's old Card Validator no longer shows a preview, so in practice you check the card in the post composer and wait out the cache for links already posted. In Telegram, send the URL to @WebpageBot to refresh the preview. Other chat apps offer no tool; their cache expires on its own schedule.

Changing the image

Because images are cached by URL everywhere, never overwrite an image file and hope. Publish the new image under a new URL, such as /og/sourdough-v2.jpg or sourdough.jpg?v=2, update og:image, then rescrape in the Sharing Debugger and Post Inspector.

Dynamic and generated OG images

A site with thousands of articles or products cannot design each card by hand. The standard practice is a generated image per page:

• One template per page type. Articles get the headline and author, products the photo, name and price, categories the category name and a few product shots.
• Generate at build time or on request. Static site generators can render images during the build; frameworks and image services can render them on the first request and cache the result.
• Make the URL unique and stable. Include the page slug and a version in the image URL, so a changed title produces a new image URL and a fresh cache.
• Make it fast. Serve generated images with a long cache lifetime from a CDN. A generator that takes several seconds on a cold start will time out for impatient fetchers.
• Always have a fallback. If generation fails, the tag should point to a default image that exists, never to an error page.

Consistency with title, description and canonical

Social tags should tell the same story as your search tags.

• og:url equals the canonical. Use the same protocol, host and trailing slash as your rel="canonical". The lesson Canonical tags explains how to choose that URL.
• og:title follows the title tag, minus the brand. It can be a little more conversational, but it should promise the same page.
• og:description matches the meta description in substance. See Meta descriptions and snippets for how to write one.
• One set per page. A theme and an SEO plugin often both print Open Graph tags. With duplicates, the first tag wins, which may be the wrong one.
• In the server HTML. Social fetchers generally do not render JavaScript, so tags set by a client-side app on load are often missed.

Open Graph is not structured data in Google's sense. It does not create rich results, and it does not replace Article or Product markup. The lesson Structured data in 2026 covers that side.

Common mistakes

• ✕Relative or protocol-relative image URLs/og/a.jpg or //cdn.example.com/a.jpg instead of a full https:// address.
• ✕Images the crawler cannot fetchBlocked in robots.txt, behind a login, on staging, or stopped by a firewall or hotlink protection. X: “If an image URL is blocked, no thumbnail or photo will be shown.”
• ✕Huge or wrongly shaped filesA 6 MB PNG, a tall portrait photo, an SVG logo.
• ✕Missing tags on templatesArticles have them; categories, tag pages, product listings and the home page do not.
• ✕Two sets of tagsTheme plus plugin, with different titles or images.
• ✕og:url pointing to the home pageEvery share then counts for, and may preview as, the home page.
• ✕Staging or tracking URLs in tagsA staging.example.com image or ?utm_ in og:url, copied over in a migration.
• ✕The same logo everywhereEvery shared page looks identical in the feed.
• ✕No twitter:cardX falls back to the small summary card.
• ✕Tags set by JavaScriptVisible in the browser's inspector, absent from the HTML that fetchers download.

Debugging workflow step by step

1. Look at the HTML the crawler gets. Use View Source or curl, not the browser inspector. Confirm one set of tags in the <head> with absolute URLs.
2. Open the og:image URL on its own. It should return 200 with an image content type, without a login, redirect chain or bot challenge, and should not be disallowed in robots.txt.
3. Run the Sharing Debugger and Post Inspector. They show what each crawler actually read.
4. Read every warning. Missing properties, an image below the minimum size, a URL that redirects or an og:url that differs from the address you entered.
5. Fix the template, not just the page. If the image changed, give it a new URL.
6. Rescrape and test. Click Scrape Again and Inspect, check the X composer, and send the link in Telegram or Slack.
7. Check other templates. Repeat for a category, a product, a tag page and the home page.

Two server issues also show up here. Meta notes: “Our crawler only accepts gzip and deflate encodings, so make sure your server uses the right encoding.” And X documents that “Twitter's crawler respects Google's robots.txt specification when scanning URLs.” A disallow rule for an images folder therefore blocks the card image too.

FAQ

Sources

• The Open Graph protocol
• Meta for Developers — A Guide to Sharing for Webmasters (Internet Archive copy, June 2026)
• Meta for Developers — Images in Link Shares (Internet Archive copy, June 2026)
• X Developer Platform — Getting Started with Cards (Internet Archive copy, February 2026)
• X Developer Platform — Cards markup (Internet Archive copy, February 2026)
• X Developer Platform — Summary Card with Large Image (Internet Archive copy, February 2026)
• X Developer Platform — Troubleshooting Cards (Internet Archive copy, January 2026)
• LinkedIn Help — Make your website shareable on LinkedIn
• LinkedIn Help — Troubleshooting issues sharing URLs
• LinkedIn Help — Use Post Inspector to refresh URL
• Google Search Central — Influencing your title links in search results

Quotes checked against the official pages on 30 October 2026.