The Open Graph protocol defines dozens of properties. Four of them do almost all the work, another handful are worth setting, and the rest are situational. This reference lists them all with defaults and behaviour, so you can tell at a glance whether a tag is load-bearing or decorative. Every og: tag uses the property attribute; every twitter: tag uses name.
<meta property="og:title" content="..."> <!-- Open Graph: property -->
<meta name="twitter:card" content="..."> <!-- Twitter Cards: name -->Tags at a Glance
| Tag | Controls | Default if omitted | Impact |
|---|---|---|---|
og:title | Card headline | Falls back to <title> | High |
og:description | Summary line | Falls back to meta description, then body text | High |
og:image | Card image | Platform guesses from page images, or none | Highest |
og:url | Canonical address | The shared URL, including UTM parameters | High |
og:type | Object type | website | Low |
og:site_name | Publisher label on the card | Derived from the domain | Low |
og:locale | Content language | en_US | Low |
og:image:width | Declared pixel width | Platform downloads before laying out | Medium |
og:image:height | Declared pixel height | Platform downloads before laying out | Medium |
og:image:alt | Accessible description | No alt text | Low |
twitter:card | X layout | summary — small square thumbnail | High on X |
twitter:site | Publisher @handle | Not shown | Low |
og:title
The headline of the card. Distinct from <title>, which is what search engines display — you often want them to differ, since a page title frequently carries an SEO suffix that wastes space in a card.
<title>How We Cut Build Times by 70% | Example Engineering Blog</title>
<meta property="og:title" content="How We Cut Build Times by 70%">Keep it under about 60 characters. Most platforms truncate somewhere between 60 and 88, and a headline that ends mid-word reads as carelessness. Do not include your site name — that is what og:site_name is for.
og:description
The one or two lines beneath the headline, and the only body copy you control inside the card. Aim for 100–150 characters; past roughly 200 most platforms trim mid-sentence.
When absent, platforms fall back to <meta name="description">, and failing that they scrape body text — which is how cards end up showing a cookie banner or a nav label. Setting it explicitly is the only way to be sure.
og:image and Its Sub-Properties
The highest-impact tag in the protocol. A card with an image occupies several times the visual space of a text-only link. It has a family of related properties:
<meta property="og:image" content="https://example.com/og/article.png">
<meta property="og:image:secure_url" content="https://example.com/og/article.png">
<meta property="og:image:type" content="image/png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="A bar chart showing build time dropping from 14 to 4 minutes">| Property | Purpose | Worth setting? |
|---|---|---|
og:image | Absolute HTTPS URL of the image | Always |
og:image:width | True pixel width | Yes — prevents an imageless first share |
og:image:height | True pixel height | Yes — same reason |
og:image:alt | Description for screen readers | Yes, for accessibility |
og:image:type | MIME type | Optional |
og:image:secure_url | HTTPS variant | Legacy — redundant when og:image is already HTTPS |
og:image declared above them. Putting og:image:width before og:image, or between two different image tags, associates it with the wrong image or none at all. Keep each image and its sub-properties together as a block.For dimensions, cropping and format limits, see the og:image Size Guide.
og:url
The canonical address for the page. Its job is deduplication: without it, the same article shared from ?utm_source=twitter and from a bare link are treated as two different objects, and engagement counts split across both.
<meta property="og:url" content="https://example.com/blog/build-times">It should match your <link rel="canonical"> and must be absolute. A common bug is emitting the current URL including query parameters, which defeats the purpose entirely.
og:type
Declares what kind of object the page represents. website is the default and is correct for most pages; article is worth setting on blog posts and news.
| Value | Use for | Extra properties it enables |
|---|---|---|
website | Anything general (default) | None |
article | Blog posts, news, guides | article:published_time, article:author, article:section, article:tag |
profile | Personal profile pages | profile:first_name, profile:last_name, profile:username |
video.other | Video pages | video:duration, video:release_date |
book | Book pages | book:author, book:isbn |
music.song | Track pages | music:duration, music:album |
<meta property="og:type" content="article">
<meta property="og:image" content="https://example.com/og/article.png">
<meta property="article:published_time" content="2026-07-29T09:00:00Z">
<meta property="article:modified_time" content="2026-07-29T14:30:00Z">
<meta property="article:author" content="https://example.com/authors/jane">
<meta property="article:section" content="Engineering">
<meta property="article:tag" content="CI">These vertical properties have little visible effect on most cards today — they matter mainly to Facebook's object graph. Setting og:type correctly costs nothing; the sub-properties are optional.
og:site_name and og:locale
og:site_name is the publisher label shown alongside or beneath the card. Without it, platforms display the bare domain, which is usually fine but less polished.
<meta property="og:site_name" content="Example">
<meta property="og:locale" content="en_US">
<meta property="og:locale:alternate" content="fr_FR">
<meta property="og:locale:alternate" content="de_DE">og:locale uses the language_TERRITORY format — en_US, not en-US. That underscore trips people up, and the wrong separator means the tag is ignored. og:locale:alternate may be repeated for each translated version.
The twitter: Namespace
X reads twitter: tags first and falls back to og: for anything it does not find. That fallback is good enough that only one tag is genuinely necessary.
| Tag | Purpose | Falls back to |
|---|---|---|
twitter:card | Layout: summary or summary_large_image | Nothing — defaults to the small layout |
twitter:title | Headline on X | og:title |
twitter:description | Summary on X | og:description |
twitter:image | Image on X | og:image |
twitter:image:alt | Alt text on X | og:image:alt |
twitter:site | Publisher @handle | Not shown |
twitter:creator | Author @handle | Not shown |
twitter: tag with no og: fallback. Without summary_large_image, X renders a small square thumbnail beside the text instead of the full-width image card — the same tags, a fraction of the visual impact.Full comparison in Twitter Cards vs Open Graph.
A Complete, Well-Formed Head
<head>
<title>How We Cut Build Times by 70% | Example Engineering</title>
<meta name="description" content="A walkthrough of the caching changes that took our CI from 14 minutes to 4.">
<link rel="canonical" href="https://example.com/blog/build-times">
<meta property="og:title" content="How We Cut Build Times by 70%">
<meta property="og:description" content="A walkthrough of the caching changes that took our CI from 14 minutes to 4.">
<meta property="og:url" content="https://example.com/blog/build-times">
<meta property="og:type" content="article">
<meta property="og:site_name" content="Example">
<meta property="og:locale" content="en_US">
<meta property="og:image" content="https://example.com/og/build-times.png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="A bar chart showing build time dropping from 14 to 4 minutes">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:site" content="@example">
</head>Mistakes That Silently Break Tags
name=instead ofproperty=on anog:tag. Valid HTML, ignored by Facebook.- Relative URLs in
og:imageorog:url. Scrapers do not resolve them against the page — see Fix "og:image relative URL". - Duplicate tags. Two
og:titletags means the chosen one varies by scraper. Usually a CMS plugin competing with a theme. - Tags outside
<head>. Meta tags in<body>are ignored, and an unclosed tag earlier in the head can push later ones out of it. - Client-side injection. Scrapers do not run JavaScript, so tags added after hydration are invisible to them.
en-USinog:localeinstead ofen_US.- Unescaped quotes in a content value, which truncates the attribute silently.
# List every og: and twitter: tag as a scraper sees them
curl -sL -A "facebookexternalhit/1.1" https://example.com/page \
| grep -iE '<meta[^>]+(og:|twitter:)'
# Count duplicates of the tags that matter
for t in og:title og:description og:image og:url; do
printf '%s: ' "$t"
curl -sL https://example.com/page | grep -c "property=\"$t\""
doneFrequently Asked Questions
Which Open Graph tags are required?
The protocol names og:title, og:type, og:image and og:url. Platforms are more forgiving than the spec — most build a card from og:title and og:image alone — but supplying those four plus og:description gives you full control over what renders.
What happens if I omit og:title?
Platforms fall back to your <title> tag. That often works, but page titles usually carry an SEO suffix like | Example Blog that wastes limited card space and may push the real headline into a truncation.
Do I need og:image:secure_url?
No. It dates from when og:image was commonly HTTP and a separate HTTPS variant was needed. If your og:image is already an https:// URL, it is redundant.
Can I use multiple og:image tags?
The protocol allows it, with the first treated as primary, but scrapers disagree about which one to pick. Publish exactly one unless you have a specific reason — accidental duplicates from a plugin and a theme are a common cause of unpredictable previews.
Does og:type change how the card looks?
Barely. It mainly classifies the object for Facebook's graph and unlocks vertical-specific properties. Setting article on blog posts is good practice, but leaving the default website will not visibly change the card.
Do Open Graph tags affect search rankings?
Not directly — Google does not use them as a ranking signal. The indirect effect is real, since links that render as rich cards get shared and clicked more, and that traffic does influence how a page performs.