Open Graph tags: how link previews work and how to get them right

Open Graph tags are a handful of <meta property="og:…"> lines in the <head> of a page that tell Facebook, LinkedIn, WhatsApp, Slack, X and most other apps what to show when someone shares the link: a title, a line of description, an image and the address. Without them the app guesses, and it usually guesses the logo, the cookie notice or nothing. This guide is the map of the topic: what the Open Graph protocol is, every tag and what it does, how each app builds its card, how to check yours, and where to go next for images, X cards, caches and the rest.

Quick answer

The set every page should have:

<meta property="og:title" content="Alpina Pro trekking shoe, waterproof">
<meta property="og:description" content="Vibram sole, sizes 36-47, free delivery over €60.">
<meta property="og:image" content="https://example.com/img/og/alpina-pro-1200x630.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="The Alpina Pro shoe in grey, side view">
<meta property="og:url" content="https://example.com/shoes/alpina-pro/">
<meta property="og:type" content="product">
<meta property="og:site_name" content="Outdoor Shop">
<meta name="twitter:card" content="summary_large_image">

• Put the tags in the server-rendered HTML. The apps' bots do not run JavaScript, so tags added by a script after load are invisible to them.
• Image: 1200 × 630 px, JPEG or PNG, under 1 MB (under about 300 KB if WhatsApp matters), absolute https:// URL, publicly reachable.
• og:url is the same address as the page's canonical URL.
• twitter:card set to summary_large_image is the only X tag most sites need; X reads the og: tags for the rest.
• After changing tags, refresh the platforms' caches (Facebook's Sharing Debugger, LinkedIn's Post Inspector), because they keep the first card they built.
• Check a page with the link preview checker before you share it.

What is Open Graph?

Open Graph is a protocol Facebook published in 2010 so that any web page could describe itself as an object in its "social graph": a title, a type, an image and a permanent address. The specification lives at ogp.me. It borrowed its syntax from RDFa, which is why the tags use a property attribute (property="og:title") instead of the name attribute ordinary meta tags use.

Facebook built it for its own Like button and link cards, but the idea stuck because it solved a problem everyone had: a page had no standard way to say "when you show me as a card, use this". Today LinkedIn, WhatsApp, Slack, Microsoft Teams, Discord, Telegram, iMessage, Pinterest and X all read Open Graph tags, and X has its own twitter: tags that fall back to Open Graph when missing. So "og tags", "Open Graph meta tags" and "og meta tags" all mean the same thing: this block of lines in the head.

The protocol names four properties as required for every page: og:title, og:type, og:image and og:url. In practice apps render a card with fewer, but a page with all four, plus og:description, gets a complete card everywhere.

Open Graph tags vs other meta tags

The <title> and <meta name="description"> are written for search results; the Open Graph tags are written for people scrolling a feed or a chat. They can say the same thing, and many sites let the SEO plugin copy one into the other, but they do not have to. A search title carries the keyword and the brand; a share title can be shorter and more human, because the brand already shows in og:site_name and the domain line. When og:title or og:description is missing, most apps fall back to the <title> and the meta description, so those are your safety net, not your share copy.

Why link previews matter

Many links are never clicked from a search result at all. They are pasted into a WhatsApp group, a Slack channel or a LinkedIn post, and what people see there is the card. A clear image and title get the link opened; a grey box with "example.com" does not. On LinkedIn and Facebook the card is most of the post; in WhatsApp and iMessage it is what makes a link look trustworthy rather than like spam.

The cost is a few lines per template, written once. The return comes every time anyone shares any page, including shares you never see: a customer sending your product to a partner, a journalist dropping your article into a team chat. And because Slack and Teams unfurl links in every message, internal links to your own site benefit too.

Previews also fail quietly. The page works, nobody reports "your WhatsApp card is wrong", and the only symptom is that shared links get fewer clicks than they should. That is why checking one page per template once is worth the ten minutes.

The Open Graph tags, one by one

Two syntax rules catch people out. Open Graph tags use property=, Twitter tags use name=; most parsers accept either, but stick to the documented one. And every URL in them (og:image, og:url) should be absolute, starting with https://, because bots resolve relative paths inconsistently or not at all.

How apps build a link preview

When someone pastes a link, the app sends its own bot to fetch the page: facebookexternalhit for Facebook, Instagram and Messenger, LinkedInBot, Slackbot-LinkExpanding, Twitterbot, Discordbot, TelegramBot. WhatsApp and iMessage are different: the sender's phone fetches the page itself while the message is being written, and the finished card travels inside the message.

Every one of these fetchers behaves like a simple, impatient visitor. It reads the raw HTML without running JavaScript, sends no cookies, comes from an address your firewall has not seen before, and gives up after a few seconds. It then downloads the og:image separately. So a single-page app that injects its tags client-side, a bot-blocking rule at the CDN, an image behind hotlink protection or a slow origin all end in the same result: a card with no image, or no card.

Finally, each app caches what it built. Facebook and LinkedIn keep a card for days and give you a tool to refresh it; Slack caches per workspace; WhatsApp and iMessage never change a message already sent. That caching is the reason "I fixed the tags and nothing changed" is the most common question in this topic.

How to check your Open Graph tags

The checker fetches your page from our server, the way the apps' bots do, and reads the Open Graph and Twitter tags as they are in the served HTML. It downloads the og:image and measures the real pixels rather than trusting the declared size, checks that the image answers from an absolute https address, compares og:url with the canonical, and draws the card for Facebook, LinkedIn, X, Slack and WhatsApp. Treat the cards as close likenesses: the apps change their layouts now and then. The same checks run in the social module of every full getReport, with the explanation and fix behind each one on the Open Graph fix page and the Twitter cards fix page.

The checker reads the tags as they are now. If it passes and an app still shows an old card, the problem is that app's cache, not your page.

og:title, og:description and og:type

These three fields decide what the card says. og:title is the headline in bold; keep it under about 60 characters so it survives on a phone. og:description is the grey line under it; 60-120 characters, because most apps cut at two lines and some (WhatsApp, Slack) show only one. og:type is mostly invisible to readers: website for the home page and hubs, article for posts, product for shop pages.

The mistake is treating them as copies of the SEO title and description. The search title carries a keyword and the brand; the share title should read like something a person would say when sending the link. The fallbacks when a field is missing, character limits per app, and a complete head for each page type are in Open Graph title, description and type.

The share image: size, safe area and weight

One size works everywhere: 1200 × 630 pixels, a 1.91:1 ratio. Facebook, LinkedIn, X's large card, Slack and WhatsApp's large preview all render it without cutting off the edges. Some views crop to a square from the centre (WhatsApp's small preview, X's summary card), so keep the subject and any text inside the middle 630 × 630. Anything under 600 × 315 renders as a small thumbnail, and a logo on a white square makes every share look the same.

Weight matters as much as size. Stay under 1 MB for every app; WhatsApp is commonly reported to show its large preview only for images under about 300 KB, which is undocumented but a good rule of thumb. A JPEG at quality 80 usually lands at 100-200 KB. Text on the image should be large, 60 px or more, because the card is shown at a third of its size. The safe area in pixels, export settings and the tags for multiple images are in Open Graph images: size, safe area and weight.

Generating an image for every page

A site with hundreds of posts or products will not get a hand-made image for each one, and a single default image makes every share look identical. The fix is a template: one 1200 × 630 design with the page title, a category label and your brand, rendered per page at build time or on the first request and then cached.

Static site generators and frameworks such as Next.js can render these images from HTML and CSS; WordPress plugins and image CDNs can do it from a URL template. The build-time and on-request approaches, caching, and how to check the output are in generating Open Graph images automatically.

og:url and the canonical URL

og:url is the address the apps file a share under. Facebook counts likes and shares per og:url, and every app caches its card per URL. If a campaign link with ?utm_source=newsletter declares itself as the clean URL, all its shares count toward one page and one card; if og:url points somewhere else, the card can link to the wrong page entirely.

The rule is simple: og:url equals the canonical URL, character for character (scheme, www, trailing slash). What the report compares, and the typical causes of a mismatch (a staging domain baked into a template, a plugin that uses the current request URL), are in og:url and the canonical tag: keeping them in sync. The canonical side is covered in canonical tags explained.

Twitter/X cards

X reads its own tags first and falls back to Open Graph for anything missing. The one tag it will not guess is the card type: without twitter:card, X shows the small summary card with a square thumbnail even when your og:image is a perfect 1200 × 630. Set twitter:card to summary_large_image and X uses your og:title, og:description and og:image for the rest.

X removed the preview from its Card Validator in 2022, so there is no official way to see a card before posting; the link preview checker shows the card X would build from your tags. The fallback rules tag by tag, image limits and when summary is the better choice are in Twitter/X cards: summary vs summary_large_image.

WhatsApp, Slack, LinkedIn and iMessage

Every chat and social app reads the same Open Graph tags, then applies its own rules. WhatsApp builds the card on the sender's phone and is strict about image weight and server speed. Slack shows the site name, title, description and a scaled image, and caches per workspace. LinkedIn wants at least 1200 × 627 and keeps a card for about a week. iMessage builds a rich card on the device and prefers a large image.

The practical consequences are the same list: allow each app's bot through your firewall and rate limits, keep the image light, and test in the app that matters most to your audience. The per-app table of what each reads, its bot's user agent and its cache is in what each link preview reads in WhatsApp, Slack, LinkedIn and iMessage.

When the preview shows the old image

You changed the image, the checker shows the new one, and Facebook still shows the old card. That is caching, and each app has its own:

• Facebook, Instagram, Messenger: paste the URL into the Sharing Debugger and click Scrape Again.
• LinkedIn: paste it into the Post Inspector, which fetches the page again.
• X, Slack, Discord: no refresh tool; a query parameter (?v=2) makes a new URL and a fresh fetch.
• WhatsApp and iMessage: messages already sent never change; a new message fetches the page again.

If a refresh does not help, the problem is usually the image rather than the cache: the same file name serving a new image from a CDN that cached the old one, or a bot block. The step-by-step per platform, and the image problems that look like caching, are in debugging a cached link preview.

Do you need fb:app_id?

Facebook's Sharing Debugger shows a warning when fb:app_id is missing, which makes many site owners think something is broken. It is not: previews render without it. The tag links your pages to a Facebook app, which matters only if you use Facebook's sharing insights or its comments plugin tied to that app.

If you do not, ignore the warning. If you do, the ID comes from Meta's developer dashboard and most WordPress SEO plugins have a field for it. The details are in Facebook App ID: do you need it.

Link previews for PDFs and other files

A link that points straight at a PDF, a Word document or a ZIP shares as a bare address, because a file has no <head> and so no Open Graph tags. Apps cannot build a card from nothing.

The fix is a landing page for each document that matters: its own title, description and cover image as og:image, and a download button. Share the landing page, keep the file where it is so old links still work. See link previews for PDF and file links.

Step by step

1. Check one page per template

Home page, a product or service page, an article. The preview panel shows the card per app; the findings list what is missing or wrong. One template fixed fixes every page built from it.

2. Fix the image first

Missing, too small, too heavy or unreachable. Export a 1200 × 630 version under 300 KB, reference it with an absolute https URL, and add og:image:width, og:image:height and og:image:alt.

3. Write the title and description for people

Short, specific, no keyword stuffing. Put the brand in og:site_name, not at the end of every title.

4. Align og:url with the canonical

Same scheme, host and path. Then shares of tracked links count toward one page.

5. Add the Twitter card tag

<meta name="twitter:card" content="summary_large_image">. Nothing else for X unless you want a different image there.

6. Refresh the caches

Scrape Again in Facebook's Sharing Debugger, Post Inspector on LinkedIn, then test by pasting the link into a chat with yourself.

Platform notes

WordPress: WordPress core prints no Open Graph tags. Yoast SEO, Rank Math and similar plugins print the full set from the post's featured image, title and excerpt, and add a Social tab per post to override them. Set a default share image in the plugin settings, so pages without a featured image still get a card, and make sure only one plugin prints the tags; two plugins mean duplicate og:image lines and apps pick whichever comes first.

Shopify: Online Store → Preferences → Social sharing image sets the store-wide default; product pages use the product's featured image; the theme prints the tags. Problems are almost always the image itself, such as a portrait product photo that crops badly.

Static sites and frameworks: a layout partial reads title, description and image from each page's front matter; generate the image at build. In Next.js the Metadata API's openGraph field prints the tags server-side.

Single-page apps: tags set with JavaScript after load are not seen by any bot. Render them on the server or prerender the pages that get shared.

Verify

• The link preview checker shows every finding passed and the cards render with the intended image.
• curl -s https://example.com/page/ | grep -i 'og:' prints the tags in the raw HTML, not only in the browser's developer tools.
• Paste the link into a WhatsApp chat with yourself and into a Slack DM to yourself: image, title and description all appear.
• After a change, Facebook's Sharing Debugger and LinkedIn's Post Inspector show the new card.

Common mistakes

• A relative image URL (/img/og.jpg). Use the absolute https URL.
• The logo as the share image. A 400 × 400 logo on every page renders as a thumbnail and makes every share look the same.
• Text in the corners of the image. Cropped on square previews.
• Tags added by JavaScript. Bots read the HTML before scripts run.
• Blocking the bots with a WAF or bot-protection rule that also catches facebookexternalhit, LinkedInBot, Twitterbot, Slackbot and WhatsApp. Allow them.
• Two plugins printing tags, with different images.
• Changing the image but not refreshing the caches. Platforms keep the old card for days.
• og:type set to article on every page, including products and the home page.

Questions people ask

What is the difference between Open Graph tags and meta tags?

Open Graph tags are a kind of meta tag with a different job. The <title> and meta description are written for search results, while og:title, og:description and og:image are read by Facebook, LinkedIn, WhatsApp, Slack and X to build the card when someone shares the link. Open Graph tags use a property attribute instead of name. When they are missing, most apps fall back to the title and meta description, but they add no image.

How do I test my Open Graph tags?

Paste the URL into the link preview checker: it reads the Open Graph and Twitter tags from the served HTML, downloads the image to measure its real size, checks that og:url matches the canonical, and draws the card for the common apps. Facebook's Sharing Debugger and LinkedIn's Post Inspector show their own platform's view and refresh its cache, so use them after you change the tags.

What size should an Open Graph image be?

Use 1200 × 630 pixels, a 1.91:1 ratio, as a JPEG or PNG under 1 MB, ideally 100-200 KB. That size renders sharply on Facebook, LinkedIn, X's large card, Slack and WhatsApp. Keep text and the main subject inside the central 630 × 630 area, because some apps crop to a square, and never go below 600 × 315. See Open Graph images: size, safe area and weight.

Why is my link preview showing the wrong image?

Usually because the app cached an old preview, or your page has no og:image and the app picked another image. Check the tags first; if they are right, refresh the cache: Scrape Again in Facebook's Sharing Debugger, Post Inspector on LinkedIn, or add a query parameter such as ?v=2 for X and Slack. WhatsApp builds a new card for each new message. Debugging a cached link preview covers each app.

How do I change the link preview image in WordPress?

Set it in your SEO plugin: in Yoast SEO or Rank Math, open the post, go to the Social tab and choose the image, and set a default image in the plugin settings for pages without one. WordPress itself adds no og:image, so without a plugin each app guesses. Use 1200 × 630 pixels, then ask Facebook and LinkedIn to fetch the URL again so they drop the old card.

Why does my link show no image on WhatsApp?

Usually because og:image is missing, uses a relative URL, points at an image behind a redirect or login, or the file is too heavy: WhatsApp often shows only a small thumbnail, or none, for images much larger than about 300 KB. Use an absolute https URL to a JPEG or PNG of 1200 × 630 pixels under 300 KB, then send the link in a new message, because a message already sent keeps its card.

How do I refresh a LinkedIn link preview?

Paste the URL into LinkedIn's Post Inspector, which fetches the page again and updates the title, description and image LinkedIn has stored. Otherwise LinkedIn keeps a preview for about seven days. If the image still does not change, give the image file a new name so its URL is new, and check that it is at least 1200 × 627 pixels and under 5 MB.

Do I need different share images for Facebook, LinkedIn and X?

No. One 1200 × 630 pixel image in og:image works on Facebook, LinkedIn, X, Slack and WhatsApp, because X falls back to Open Graph when twitter:image is missing. Keep the important part in the centre, since some apps crop to a square, and add twitter:card set to summary_large_image so X shows the large card instead of a small thumbnail.