Open Graph Tags: The Five You Actually Need

The Open Graph protocol has one job: tell a platform what to show when someone shares your link. Get it right and every paste into Slack, LinkedIn, WhatsApp, Discord, or iMessage produces a clean card with your headline, your summary, and your image. Get it wrong — or leave it out — and the platform guesses, usually by grabbing whatever image appears first in the DOM and an arbitrary chunk of body text.

The specification itself is large. Facebook's documentation lists dozens of properties covering video, audio, music albums, books, and profiles. Almost none of it matters for a normal website. Five tags do essentially all the work, and this post covers exactly those five, what breaks them, and the image spec that trips up the most people. For the wider context of how Open Graph sits alongside title tags, robots directives, and canonicals, see The Complete Guide to Meta Tags.

The five that matter

<meta property="og:title" content="Open Graph Tags: The Five You Actually Need">
<meta property="og:description" content="The five og: tags that produce a correct social preview, and the image spec that avoids a shrunken thumbnail.">
<meta property="og:image" content="https://example.com/images/og-open-graph-guide.jpg">
<meta property="og:url" content="https://example.com/blog/open-graph-tags-guide">
<meta property="og:type" content="article">

That block is complete. Add nothing else and your links will unfurl correctly everywhere.

og:title

The headline on the card. It can — and usually should — differ from your <title> element, because the two appear in different contexts. A <title> typically ends with a brand suffix like | Acme so the SERP listing is attributable. A social card already displays your domain underneath the headline, so the suffix is redundant clutter eating into the visible line.

Practical range is about 60-90 characters before platforms start truncating, though the exact cut varies: LinkedIn is tighter than Facebook, and mobile feeds are tighter than desktop. Write for roughly 60 and you'll never be cut off.

og:description

The subtext under the headline. Two to four lines render reliably; most platforms truncate somewhere near 200 characters and several near 100, so the first sentence has to stand alone.

This is not the same job as a meta description. A meta description competes for a click against nine other blue links from someone actively searching. An og:description interrupts someone scrolling a feed with no intent at all. The register is different — more hook, less summary. Our post on writing meta descriptions that get clicks covers the search-intent side; for social, front-load the surprising part.

If you omit og:description, most platforms fall back to your <meta name="description">, but the fallback is inconsistent enough that it isn't worth relying on.

og:image

The tag that causes the most trouble, and the one with the hardest specs:

• At least 1200 × 630 pixels, at a 1.91:1 aspect ratio. This is the size platforms design their large card layouts around.
• JPG or PNG, under roughly 5 MB. WebP support is patchy across scrapers; don't risk it for a social image.
• Absolute HTTPS URL. A relative path like /images/og.jpg fails silently — the tag parses fine, the scraper resolves nothing, the card ships imageless.
• Above about 600 × 315 to get the large banner at all. Below that, platforms render a small square thumbnail beside the text instead, which looks like a mistake even when everything else is correct.

Two supporting tags are worth adding alongside it. og:image:alt supplies alt text for screen readers on platforms that surface it. og:image:width and og:image:height let a scraper lay out the card before it has finished downloading the image, which reduces the chance of a first-share render with a blank box.

Keep the image's content in mind too: platforms crop the edges at some breakpoints, so centre anything essential and don't put text in the outer 10%.

og:url

The canonical identity of the page as far as social platforms are concerned. This is where share counts, reactions, and engagement history get attached.

It must match your rel="canonical" exactly — same protocol, same host, same trailing-slash convention, no tracking parameters. A page reachable at both https://example.com/post and https://example.com/post?utm_source=newsletter should declare the clean URL in both og:url and the canonical. Otherwise the newsletter shares accumulate against one record and the organic shares against another, and neither shows the real number.

The Canonical URL Generator normalizes a URL and strips the parameters that cause this split, which gives you one string to paste into both tags.

og:type

Declares what kind of thing the page is. In practice you need two values:

• website — homepages, landing pages, product pages, category pages.
• article — blog posts, news, editorial.

Setting article unlocks the article sub-properties, which some platforms surface:

<meta property="article:published_time" content="2026-08-07T09:00:00Z">
<meta property="article:modified_time" content="2026-08-07T09:00:00Z">
<meta property="article:author" content="https://example.com/authors/jane">
<meta property="article:section" content="SEO">

Omit og:type entirely and most scrapers assume website, which is a benign default — but explicit is better.

The four mistakes that cause most broken cards

Using name instead of property. Open Graph is built on RDFa and requires property. <meta name="og:image" content="..."> is invisible to every major scraper. This is by far the most common single cause of a blank preview, and it's invisible in the rendered page.

Relative image URLs. Covered above, but worth repeating because it's the second most common cause and equally silent.

Injecting tags client-side. If your framework adds the <head> after hydration, a scraper that doesn't execute JavaScript sees nothing. Facebook's and LinkedIn's crawlers in particular are conservative here. Server-render your meta tags, then confirm by fetching the live URL with curl and reading the raw HTML — not by opening dev tools, which shows you the post-JavaScript DOM.

Forgetting the cache. Platforms scrape once and cache hard. Change an image the day after publishing and the old card will keep appearing for days. Each platform provides a debugger that forces a re-scrape; run the URL through the relevant one after any change.

Where Twitter/X fits

X reads Open Graph. If you have the five tags above, X already has a title, a description, and an image. The single thing it can't infer is which card layout to use, which is why twitter:card is worth adding:

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

That's a name attribute, not property — Twitter Cards follow the standard HTML convention, unlike Open Graph. Everything else in the twitter:* namespace is an optional override that only earns its place if you genuinely want X to show something different from every other platform. Twitter Cards vs Open Graph works through when that's actually true.

Shipping the block

Build it, don't type it. The Open Graph Generator produces the full five-tag block with the correct property attributes and previews how the card will render before you paste it into your template. Pair it with the Meta Tag Generator for the search-side tags and the Twitter Card Generator for the card type, and you have a complete <head> in a couple of minutes. All three run entirely in your browser, so pre-launch URLs and unpublished headlines never touch a server.

Then verify on the live page. Open Graph fails quietly, and quiet failures are the ones that ship.