Open Graph Tags: The Complete Guide With Copy-Paste Examples

Open Graph tags are the handful of <meta> elements that decide what a link looks like when someone pastes it into Slack, LinkedIn, X, WhatsApp, iMessage or Facebook. Get them right and every share arrives as a large card with your image and headline. Get them wrong and the same link shows up as a grey box with a truncated URL, which people scroll past.

This guide covers the tags that actually matter, the image specifications that work on every platform, a template you can paste into any site, and the testing routine that catches the mistakes before your customers do.

What Open Graph is and who reads it

The Open Graph protocol was published by Facebook in 2010 so that any web page could describe itself as an object in the social graph: a title, a type, an image and a canonical URL. Because it was simple and open, every other platform adopted it. Today LinkedIn, Slack, Discord, WhatsApp, Telegram, iMessage, Pinterest, Reddit, Bluesky and Mastodon all read og: tags. X (Twitter) reads them too, but layers its own twitter: tags on top for card format control.

Google does not use Open Graph for ranking. It can, however, use og:image as a fallback for the thumbnail in Discover and in some mobile results, and Google's own documentation recommends it for that reason. So while OG is primarily a social and messaging concern, it is not irrelevant to search.

The tags that matter, in priority order

You will see lists of twenty-plus Open Graph properties. In practice six of them determine nearly everything a user sees.

Two secondary tags are worth adding once the six above are in place: og:image:alt for accessibility (X, Mastodon and Bluesky read it), and og:locale if you serve multiple languages, because Facebook uses it to pick the right translation of a shared page.

Twitter card tags: the one you cannot skip

X reads the og: tags as fallbacks for title, description and image, so you do not need to duplicate them. What you do need is twitter:card, because it selects the layout and there is no Open Graph equivalent:

• summary_large_image renders the full-width image card. This is what you want for almost every page.
• summary renders a small square thumbnail next to the text. Fine for profile pages, wrong for articles and landing pages.

Without the tag, X falls back to summary or, for some domains, shows no card at all. If you want X-specific copy, twitter:title, twitter:description and twitter:image override the OG values, but most sites never need them.

Image specifications that work everywhere

Almost every broken preview is an image problem. The tag is present, but the file behind it fails one platform's rules.

Dimensions. 1200×630 pixels is the size that renders correctly everywhere. It matches the 1.91:1 ratio Facebook and LinkedIn crop to, X accepts it for summary_large_image, and messaging apps scale it down without cropping anything important. The hard minimum for a large card is 600×315; anything under 200×200 is rejected outright.

File size. Keep it under 300 KB. X and LinkedIn cap at 5 MB, but WhatsApp regularly refuses to show a preview for images above roughly 600 KB, and it fails silently, so nobody tells you. A well-compressed JPEG at 1200×630 is 80–200 KB.

Format. JPEG for photographs, PNG for graphics with text. WebP is supported by Facebook, X and LinkedIn but not reliably by every messaging client, so keep a JPEG or PNG for the share image even if the rest of your site uses WebP.

Protocol and access. The URL must be absolute and served over https. An http:// image is dropped by Facebook and X without an error. The image must also be publicly fetchable: no login, no hotlink protection, no redirect chain, no Cloudflare bot challenge on the image path.

Safe area. Keep text and logos at least 60 px from every edge. Square crops (Slack's small preview, some mobile clients) trim the left and right sides.

A copy-paste template

Put this in the <head> of every page, filling in the values per page. The order does not matter to crawlers but keeping it consistent makes it easy to diff.

<title>Page title | Brand</title>
<meta name="description" content="One or two sentences about this page.">
<link rel="canonical" href="https://example.com/page">

<meta property="og:type" content="website">
<meta property="og:site_name" content="Brand">
<meta property="og:title" content="Page title">
<meta property="og:description" content="One or two sentences about this page.">
<meta property="og:url" content="https://example.com/page">
<meta property="og:image" content="https://example.com/og/page.jpg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="What the image shows">

<meta name="twitter:card" content="summary_large_image">

Note the mix of property= for Open Graph and name= for Twitter. That is not a typo: OG uses RDFa syntax, Twitter uses standard meta names. Some parsers accept either, but Facebook's does not, so keep them as shown.

For blog posts, change og:type to article and add article:published_time, article:modified_time and article:author. LinkedIn shows the publish date on article cards when it is present.

Mistakes we see in almost every audit

1. Relative image paths. og:image="/og.png" is invalid. Crawlers need the full URL.
2. One image for the whole site. Every page shares the homepage image, so a blog post about pricing arrives with a hero shot of the founders. Generate per-page images, even if they are just the title on a branded background.
3. Duplicate tags from two plugins. A theme injects one set, an SEO plugin injects another. Facebook takes the first occurrence, which is usually the wrong one. View source and search for og:image; if it appears twice, remove one.
4. Canonical pointing at staging. Copied from a template and never updated. Every share is then attributed to a URL that does not exist.
5. og:url and canonical disagree.** Trailing slash on one, not the other; www on one, not the other. Share counts split across two URLs.
6. Image behind a redirect. The tag points at /og.png, which 301s to a CDN. Facebook follows one redirect, some clients follow none.
7. noindex left on after launch. Not an Open Graph problem, but you will find it while you are in the <head>, and it is a much bigger problem.

How to test and refresh a cached preview

Platforms cache previews aggressively, usually for about a week, so fixing the tags is not enough. You need to force a re-scrape.

• Facebook and Instagram: paste the URL into the Sharing Debugger and click Scrape again. It also lists warnings about missing tags and image size.
• LinkedIn: the Post Inspector re-fetches on demand and shows exactly which tag it used for each field.
• X: the Card Validator no longer shows a preview, and there is no public cache purge. Appending a harmless query string (?v=2) forces a fresh card immediately.
• Slack and Discord: cache per workspace or server for a few hours. Post the link in a private channel to test.
• WhatsApp and iMessage: cache on the device. Send from a second phone to verify.

Before you touch any of those, run the page through our free Open Graph checker. It fetches the page the way a crawler does, downloads the image and reports its real dimensions and weight, compares og:url with the canonical, renders the Facebook, X and Slack cards, and generates a corrected head block from what the page already has. If the checker passes, the debuggers above will too.

Where this fits in a wider audit

Share tags are the most visible part of a page's metadata, but they sit next to the title tag, meta description, canonical and structured data that search engines read. A page with perfect Open Graph tags and a 160-character title that Google truncates is still leaving clicks on the table. If you have not looked at the whole <head> recently, a free website audit covers all of it in one pass and ranks the fixes by impact, and the SEO audit report page explains what a useful report should contain.