The Open Graph Protocol, Explained From the Spec Up

The Open Graph protocol is a set of meta tags, defined originally by Facebook in 2010, that let any web page describe itself as a structured object — a title, a type, an image, a URL — so that when the page gets shared, the platform reading it has consistent data to build a preview card from instead of guessing at the page's content. That's the entire scope of the spec, and it's smaller and more specific than most guides make it sound. Everything beyond that core idea — which platforms honor it, how they cache it, how they handle edge cases — is implementation detail layered on top by individual platforms, not part of the protocol itself.

What are the four required Open Graph properties?

The spec defines four properties as required for a page to be considered a valid Open Graph object: og:title (the title as it should appear in the graph, which may differ from your <title> tag), og:type (what kind of object the page represents — website and article are the most common values for typical sites), og:image (a URL to an image representing the object), and og:url (the canonical URL for the object — important because it tells platforms which URL to treat as the authoritative one if the page is reachable through multiple paths). Technically, a page missing any of these isn't a fully valid Open Graph object per the spec, though in practice most platforms will still attempt to build some kind of preview from whatever's present rather than rejecting the page outright.

• og:title — the object's title as it should appear when shared, not necessarily identical to the page's <title> tag
• og:type — the object type; website and article cover most standard use cases
• og:image — a URL pointing at the representative image
• og:url — the canonical URL, which matters when a page is reachable via more than one path

Which optional properties actually matter in practice?

Beyond the four required properties, the spec defines a longer list of optional ones, and a few of these matter enough in real usage that treating them as optional undersells how much they affect the resulting preview. og:description gives platforms a specific summary to show, rather than falling back to your meta description tag or scraping arbitrary text from the page. og:site_name identifies the overall site the object belongs to, which some platforms display as a small label above the title. og:image:width and og:image:height let a platform know the image's dimensions before fetching it, which affects how fast and how correctly it can lay out the preview card — omitting them doesn't break anything outright, but it can make a platform's crawler less certain how to size the image, especially on a first fetch.

og:image:alt, and why it's easy to forget

og:image:alt provides alt text for the preview image specifically — separate from any alt attribute on an <img> tag elsewhere on the page — and it's the one optional property most commonly skipped, because it's easy to assume the page's regular image alt text covers it. It doesn't; the Open Graph image is a distinct object from any image rendered in the page body, even if it happens to be the same file, and platforms that support accessible previews rely on this specific tag, not your page's other alt attributes.

Where does the spec end and platform behavior begin?

A source of a lot of confusion is that the Open Graph protocol itself says nothing about caching, image size limits, crawler behavior, or how often a platform re-checks a URL — those are all decisions individual platforms make on top of the spec, and they vary. Facebook aggressively caches scraped metadata and requires a manual or API-triggered re-scrape to pick up changes. LinkedIn is notably stricter about minimum image dimensions than the spec requires, and will sometimes decline to render a preview image at all if it's too small, even though the spec itself doesn't set a minimum. Twitter/X layers its own separate twitter: tag namespace on top of (and overlapping with) Open Graph, falling back to og: tags when twitter: ones are absent. None of this is part of the Open Graph protocol — it's platform-specific behavior that a site owner has to account for separately, and conflating the two is where a lot of "why isn't my preview showing up right" confusion comes from.

The XML namespace declaration, and why it usually doesn't matter anymore

Older documentation of the spec, including some of Facebook's original guidance, calls for declaring an XML namespace on the <html> tag (typically xmlns:og="https://ogp.me/ns#") so that RDFa-aware parsers can correctly interpret the og: prefixed properties as part of the Open Graph namespace rather than an arbitrary custom attribute. In practice, essentially every major platform's crawler today parses og: meta tags directly by their property attribute regardless of whether the namespace declaration is present, so omitting it rarely causes a real-world problem. It's included here because it's the kind of detail that shows up in older tutorials and can create the impression that a missing namespace declaration is the cause of a preview not rendering, when the actual cause is almost always something else — a missing tag, a caching issue, or an unreachable image URL.

The og:type property, underused and often wrong

og:type is frequently left at the default website value even on pages that are clearly a different kind of object — a blog post, for instance, is more accurately represented as article, which supports its own sub-properties like article:published_time and article:author that website doesn't. This isn't just a technicality; some platforms and crawlers use the type to decide how to structure the preview or what additional metadata to look for. Getting this right costs nothing beyond picking the correct value for the page you're describing, and it's one of the more commonly overlooked parts of implementing the spec correctly rather than just copying a generic template.

Structured properties: article, product, and beyond website

Beyond the basic website and article types, the broader Open Graph ecosystem defines additional structured object types with their own sub-properties — product pages can use og:price:amount and og:price:currency, for instance, and article pages can use article:published_time, article:modified_time, article:author, and article:section to give crawlers structured publication metadata beyond just a title and image. Not every platform reads every one of these sub-properties, and support varies more here than for the core required tags, but for a site whose content maps naturally onto one of these more specific types, using the matching object type and its sub-properties is a low-cost way to hand crawlers more accurate structured data than the generic website type provides, on the pages where it's genuinely applicable.

How useopengraph handles the full property set

A template built in useopengraph's editor generates the complete relevant set of Open Graph and Twitter card tags together — og:title, og:description, og:image, og:image:width, og:image:height, og:image:alt, og:type, og:url, and the matching twitter:card properties — rather than requiring you to remember and hand-write each one per page. Because render URLs are versioned and immutable, the og:image URL a platform caches never silently points at different content later; a template change creates a new version instead of altering what's already live. And Site Audits check that this full property set is actually present and correctly formed across every page on your site, not just the handful you happened to check by hand — closing the gap between knowing what the spec requires and confirming your site actually implements it everywhere.