Open Graph Description Length: The Complete Guide

There is no official character limit for og:description. The Open Graph protocol describes it as an optional, recommended property containing “a one to two sentence description of your object.” That sentence-level guidance is the closest thing to a protocol rule. Facebook, LinkedIn, Slack and other consumers decide how much of the value to display, so a description can be valid even when a particular preview shortens it.

The practical goal is to write a useful, self-contained summary whose most important meaning appears first. Do not treat 155, 160 or 200 characters as an Open Graph limit. Those numbers are editorial heuristics or observations about particular interfaces, not requirements in the specification.

What the Open Graph specification actually says

The Open Graph protocol defines four required basic properties:

og:title
og:type
og:image
og:url

og:description is optional but recommended. The specification’s guidance is “a one to two sentence description of your object.” It does not publish a maximum number of characters, a minimum number of characters, or a truncation algorithm.

A minimal implementation looks like this:

<meta property="og:title" content="Open Graph Description Length" />
<meta property="og:type" content="article" />
<meta property="og:url" content="https://example.com/open-graph-description-length" />
<meta property="og:image" content="https://example.com/images/og-description.png" />
<meta property="og:description" content="Learn how long an Open Graph description should be, how platforms shorten previews, and how to validate your tags." />

Put the tags in the initial HTML document’s <head>. Social crawlers may not execute your client-side JavaScript, so adding the tag only after hydration can produce an empty or stale card.

How long should an `og:description` be?

Use one or two complete sentences. In practice, that often means roughly a short paragraph, but the sentence count and clarity matter more than a hard character target.

The protocol provides the description; each platform decides how much of it to render.

A reliable writing formula

State the page’s value first. Tell the reader what they will learn, do or find.
Add a useful qualifier. Mention the audience, format, scope or outcome when it helps them decide to click.
Stop when the meaning is complete. Do not pad the tag with keywords or repeat the title.

For example:

<meta property="og:description" content="A practical guide to Open Graph description length, platform truncation, and preview debugging. Includes copy-ready HTML and validation steps for Facebook and LinkedIn." />

The first sentence still makes sense if a platform displays only the beginning. The second sentence adds detail for interfaces with more room.

What to avoid

Keyword lists such as SEO, Open Graph, social media, metadata, marketing.
Descriptions that depend on the title to make sense.
Claims that a specific number is an official protocol maximum.
Boilerplate repeated across every page.
Unescaped quotation marks or characters that break the HTML attribute.

Why previews appear to have different limits

The protocol supplies metadata; each consuming service controls its own card layout. A service may show the full description, shorten it with an ellipsis, hide it on some surfaces, or choose a different representation on mobile. The same URL can therefore display different amounts of text without any change to your HTML.

LinkedIn’s official guidance requires og:title, og:image, og:description and og:url for shareable websites. Its preview renderer controls how those fields are presented. Facebook similarly fetches the tags through its crawler and exposes an official debugger. A correct tag can still look wrong when a cached preview has not been refreshed.

Question	Accurate answer
Does Open Graph define a maximum?	No numeric maximum is published.
What does the protocol recommend?	One or two sentences describing the object.
Will every platform show the whole value?	No. The consuming platform controls rendering and truncation.
Is 160 characters required?	No. It is a common heuristic, not an Open Graph rule.
Can a long value be valid?	Yes, but the useful meaning may be hidden when a card is shortened.

Implementing the tag correctly

Static HTML

Place one description tag in the document head. Keep the content attribute HTML-safe and make it specific to the page.

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta property="og:title" content="Open Graph Description Length" />
    <meta property="og:type" content="article" />
    <meta property="og:url" content="https://example.com/open-graph-description-length" />
    <meta property="og:image" content="https://example.com/images/og-description.png" />
    <meta property="og:description" content="Learn how long an Open Graph description should be and how to validate social previews after publishing." />
    <title>Open Graph Description Length</title>
  </head>
  <body>...</body>
</html>

Server-rendered and JavaScript applications

Generate the tag on the server or in a build step so it is present in the first response. For a client-rendered route, verify the raw response with curl; viewing the tag in browser developer tools after JavaScript runs is not enough.

curl -L -s https://example.com/open-graph-description-length \
  | grep -i 'property="og:description"'

For frameworks that provide a metadata API, map the page’s canonical title, URL, image and description to the framework’s Open Graph fields. Avoid emitting multiple competing og:description tags from a layout and a page component.

Checking the raw response with Python

import requests
from bs4 import BeautifulSoup

url = "https://example.com/open-graph-description-length"
r = requests.get(url, timeout=20, headers={"User-Agent": "metadata-check/1.0"})
r.raise_for_status()

soup = BeautifulSoup(r.text, "html.parser")
tag = soup.find("meta", attrs={"property": "og:description"})
print(tag.get("content") if tag else "og:description is missing")

Checking the raw response with Node.js

const url = 'https://example.com/open-graph-description-length';
const res = await fetch(url, { redirect: 'follow' });
if (!res.ok) throw new Error(`${res.status} ${res.statusText}`);
const html = await res.text();
const match = html.match(/<meta[^>]+property=["']og:description["'][^>]+content=["']([^"']*)["']/i);
console.log(match ? match[1] : 'og:description is missing');

Validation workflow after publishing

Inspect the initial HTML. Confirm the tag exists in the server response, not only after client-side rendering.
Confirm the value is page-specific. Check title, description, URL and image together.
Use Facebook Sharing Debugger. Facebook’s Open Graph project links to its official Object Debugger. Fetch the URL again after changes to request a fresh parse.
Use LinkedIn Post Inspector. LinkedIn provides an inspection workflow for checking the fields used in a share preview.
Check a real share surface. Compare desktop and mobile if the card is important to your launch.
Record the final HTML. Save the exact metadata with your release so later template changes can be diagnosed.

Preview caches are a frequent source of confusion. If the debugger shows the new value but a previously shared post does not, the old card may be cached by the platform or by a messaging client.

Edge cases developers miss

HTML entities and quotation marks

Escape an ampersand as & and use appropriate quoting when a description contains apostrophes or quotation marks. A malformed attribute can truncate the value before a crawler reads it.

Multiple descriptions

Emit one canonical og:description. Duplicate tags can make debugging ambiguous because consumers may select the first, last or otherwise unexpected value.

Internationalization

Generate a localized description for each localized URL. Pair it with the matching og:locale and canonical URL strategy used by your site. Do not mix an English description with a page whose title and content are translated.

Pages behind authentication or bot protection

Social crawlers need to fetch the public HTML. A login wall, robots policy, firewall challenge or rate limit can prevent metadata retrieval even when the tag is correct in your local browser.

Redirects and canonical URLs

Inspect the final URL after redirects. The destination document should contain the tags, and og:url should identify the URL you want shared. A redirecting URL with metadata only on the source response can lead to inconsistent cards.

Or skip the browser setup

If your workflow needs rendered screenshots of pages or social cards, ScreenshotNeo captures the final page with one request. Before capture it accepts cookie and consent banners like a visitor, then removes more than 60 known consent platforms, newsletter popups and chat widgets. You can turn each step off.

Only clean shots are billed. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads and cache hits cost nothing, and each response identifies the result with X-Page-Verdict and X-Billed headers. ScreenshotNeo also provides an MCP server with take_screenshot, get_page_info and capture_pdf for Claude, Cursor and other MCP clients.

See the ScreenshotNeo API documentation for all options. A basic call is:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Features include full-page capture with lazy images loaded, CSS-selector element capture, dark mode, device presets, custom viewport and retina scale, PDF output, custom CSS and JavaScript, click actions, selector or network-idle waits, request blocking, headers, cookies, user agents, authorization, timezone, geolocation, transparent backgrounds, resizing, configurable caching, signed links, asynchronous webhooks, bulk capture for up to 100 URLs per call, usage reporting and an OpenAPI specification. Parameters used by other screenshot APIs also work, which simplifies migration.

The Free plan includes 1,000 screenshots per month with no card. Paid plans start at $5 for 3,000 shots; every feature is included on every plan. Create a free ScreenshotNeo account and start with the monthly free allowance.

Troubleshooting common errors

Symptom	Likely cause	Fix
The debugger reports no description	The tag is absent from the initial HTML or uses `name` instead of `property`.	Render `<meta property="og:description" ...>` server-side and inspect with `curl`.
The old text still appears	Preview cache.	Run the platform’s debugger or inspector again, then allow the consuming service to refresh.
The description is cut mid-word	Platform-specific card width or truncation.	Put the core value in the first sentence; do not depend on a universal character count.
Only the page title appears	Malformed HTML, duplicate tags or a crawler blocked by authentication.	Validate markup, emit one tag and make the page publicly fetchable.
Different URLs show the same description	Template fallback or cached server data.	Log the generated metadata per route and purge application caches.
Works locally but not in production	Production uses client-side rendering, a redirect, firewall rule or different template.	Inspect the production response and final redirected URL from outside your local network.

Performance, reliability and maintenance

Metadata generation is cheap when it happens during server rendering or static builds. The expensive part is usually the crawler’s fetch of the page, especially when the HTML waits on JavaScript. Keep Open Graph tags near the top of the head, return them with the first response, and avoid making their values depend on a slow API call.

For reliable previews, use absolute HTTPS URLs for og:url and og:image, return a successful status code, keep the image publicly fetchable, and avoid frequent changes to the same URL. When descriptions change as part of a release, validate a production URL immediately and repeat the check after the platform cache has refreshed.

There is no protocol cost associated with adding the tag. If you use a screenshot service to archive or review rendered cards, account for capture volume and caching. ScreenshotNeo’s cache hits are not billed, and its usage API and verdict headers can help reconcile automated jobs.

Editorial checklist

Is the description one or two complete sentences?
Does the first sentence explain the page’s value without relying on the title?
Is the tag in the initial HTML response?
Is there exactly one canonical og:description?
Are the title, URL and image consistent with the page?
Have you checked Facebook and LinkedIn after publishing?
Have you treated any character number as a heuristic rather than a protocol limit?

FAQ

Should I count characters at all?

Counting can be useful as an editorial check for consistency, but it is not a conformance test. Read the description at the length a platform is likely to expose and make sure the opening still communicates the point.

Is `og:description` the same as an SEO meta description?

They are separate metadata fields consumed for different purposes. You may reuse wording, but each should be present in the format and location expected by its consumers.

Can I omit the description if the page has a title?

Yes, the field is optional in the protocol, but omitting it gives platforms less useful context and can produce an incomplete share card. Add it for pages that may be shared.

The research sources do not establish a ranking benefit from a particular description length. Write for comprehension and accurate previews.

How do I prove what a crawler received?

Fetch the public URL with curl or a script, inspect the initial HTML, then confirm the same value in Facebook’s debugger and LinkedIn’s inspector. This separates an HTML problem from a preview-cache problem.