OG Tags in HTML: Complete Guide to Open Graph Metadata

OG tags are metadata elements in a page’s HTML <head> that describe the page when it is shared. Add the four core properties—og:title, og:type, og:image, and og:url—then add image details and page-specific metadata as needed. Social crawlers read these tags to build a consistent preview.

What OG tags do

The Open Graph protocol lets a web page become a rich object in a social graph. Instead of guessing a title, image, or canonical URL from visible content, a crawler can use the values you provide in the document head.

Tag	Purpose	Typical value
`og:title`	Title shown for the shared object	Product documentation
`og:type`	Object type	`website`
`og:image`	Image representing the page	Absolute HTTPS image URL
`og:url`	Canonical, permanent graph identifier	Canonical page URL

Minimal working implementation

Place this block inside <head>. Use an absolute URL for the image and canonical URL so a crawler can fetch them independently of the page path.

<html prefix="og: https://ogp.me/ns#">
<head>
  <meta charset="utf-8">
  <title>Example page</title>
  <link rel="canonical" href="https://example.com/page">

  <meta property="og:title" content="Example page">
  <meta property="og:type" content="website">
  <meta property="og:url" content="https://example.com/page">
  <meta property="og:image" content="https://example.com/share-image.jpg">
  <meta property="og:image:alt" content="A product dashboard on a laptop">
</head>
</html>

The prefix declaration identifies the Open Graph vocabulary. Many implementations work without it, but keeping the protocol’s documented form makes the intent explicit.

Every useful Open Graph property

Core properties

og:title: Write the title you want displayed. It can differ from the HTML <title>, though keeping them consistent usually avoids confusing previews.
og:type: Use website for a normal page. More specific object types exist; use one only when it accurately describes the content.
og:url: Set the stable canonical URL. Keep it consistent with your canonical link and avoid tracking parameters.
og:image: Point to the image that represents the page. The URL must be fetchable by the crawler and should be absolute.

Image structured properties

The protocol defines optional properties that belong to the og:image they describe:

og:image:secure_url — an HTTPS alternative.
og:image:type — the MIME type, such as image/jpeg or image/png.
og:image:width and og:image:height — intrinsic dimensions.
og:image:alt — a description of the image contents. Supply it whenever you specify og:image; it describes the image rather than acting as a caption.

<meta property="og:image" content="https://example.com/article.jpg">
<meta property="og:image:secure_url" content="https://example.com/article.jpg">
<meta property="og:image:type" content="image/jpeg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="A blue bicycle leaning against a brick wall">

Multiple images and ordering

Repeat a property when you need multiple values. The first occurrence takes preference when values conflict. Keep each image’s structured fields directly after its og:image root, then start the next image group.

<meta property="og:image" content="https://example.com/primary.jpg">
<meta property="og:image:alt" content="Primary article illustration">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">

<meta property="og:image" content="https://example.com/alternate.jpg">
<meta property="og:image:alt" content="Alternate article illustration">

Implementation checklist

Choose the canonical URL for the page.
Write a concise, accurate og:title.
Set og:type to the page’s actual object type.
Create or select a representative image and host it at a stable absolute URL.
Add og:image:alt describing what the image contains.
Add dimensions, MIME type, and secure URL when you know them.
Render the tags in the initial HTML response, not only after client-side JavaScript runs.
Fetch the page as an unauthenticated crawler and verify that the image URL returns the expected bytes and content type.
Share a URL with a cache-busting query only when debugging; keep production og:url canonical.

Framework examples

Plain server-rendered HTML

<head>
  <title>Team documentation</title>
  <meta property="og:title" content="Team documentation">
  <meta property="og:type" content="website">
  <meta property="og:url" content="https://docs.example.com/team">
  <meta property="og:image" content="https://cdn.example.com/team-share.png">
  <meta property="og:image:alt" content="Team documentation cover illustration">
</head>

React or another component renderer

Use the framework’s head-management facility, but ensure the final server response contains the tags. A browser-only effect can be too late for crawlers that do not execute your application JavaScript.

export function ArticleHead() {
  return (
    <>
      <title>Team documentation</title>
      <meta property="og:title" content="Team documentation" />
      <meta property="og:type" content="website" />
      <meta property="og:url" content="https://docs.example.com/team" />
      <meta property="og:image" content="https://cdn.example.com/team-share.png" />
      <meta property="og:image:alt" content="Team documentation cover illustration" />
    </>
  );
}

Template-driven sites

Make title, canonical URL, image URL, and image alt text data fields in your page model. Escape attribute values and provide a fallback image for pages that do not have a custom one.

Why an `og:image` preview may be missing

The tag is absent, malformed, or outside <head>.
The URL is relative, redirects unexpectedly, requires authentication, or returns HTML instead of an image.
The image host blocks the crawler, has a TLS problem, or sends an incorrect content type.
The page has multiple images and the preferred one is not first.
A platform has cached an earlier version of the tags.
The tags are inserted only after client-side JavaScript executes.

Inspect the raw HTTP response, open the image URL without cookies, and compare the first og:image group with the image you expect. The protocol documentation identifies Facebook’s Object Debugger as its official parser and debugger; check the current tool and workflow in the platform’s documentation before relying on it.

Automated visual verification

Metadata correctness and the rendered page are separate checks. A screenshot can confirm that the page loads, that a consent banner is not covering content, and that the intended image or component appears at a target viewport. Capture the same canonical URL in CI after publishing, then inspect the response and store the artifact for review.

Or skip the browser setup

ScreenshotNeo provides a one-request website screenshot API. Before capture it accepts cookie or consent banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be disabled. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and the response identifies the result with X-Page-Verdict and X-Billed headers. It also includes an MCP server with take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.

See the ScreenshotNeo API documentation for all options. This basic call captures a page as WebP:

cURL

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

Python

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

Node.js

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

ScreenshotNeo supports full-page captures with lazy images loaded, CSS element capture, dark mode, device presets and custom viewports, retina scale, custom CSS and JavaScript, click and hide selectors, selector or network-idle waits, blocked ads and resource types, custom headers/cookies/user agents, timezone and geolocation, transparent backgrounds, resizing, selectable cache TTLs, signed links, asynchronous jobs with signed webhooks, bulk capture of up to 100 URLs per call, usage reporting, and PDF output.

The Free plan includes 1,000 screenshots per month with no card. Paid plans start at $5 for 3,000 shots; yearly billing gives two months free and every feature is available on every plan. Create a free ScreenshotNeo account.

Troubleshooting guide

Symptom	Cause	Fix
No preview image	Missing or inaccessible `og:image`	Use an absolute public URL and verify its response without cookies.
Wrong title	Another `og:title` appears first or cached metadata is stale	Keep one intended value first and recheck the raw HTML.
Wrong page identity	`og:url` contains tracking parameters or a noncanonical route	Set the stable canonical URL.
Broken image dimensions	Structured fields describe a different image group	Place width, height, type, and alt immediately after their root image.
Tags visible in browser tools but not crawler output	Tags are client-rendered	Emit them during server-side rendering or static generation.
Screenshot shows a popup	Consent, newsletter, or chat UI appears before capture	Dismiss or hide it in your browser automation, or use ScreenshotNeo’s cleanup steps.

Performance, reliability, and cost notes

Keep metadata in the initial response to avoid crawler timing differences.
Host share images on a reliable, cacheable origin and avoid requiring session cookies.
Use one stable image per page unless multiple previews are genuinely useful; repeated properties have ordering semantics.
For screenshot validation, wait for a known selector or network idle when content is asynchronous, and use caching when the page is unchanged.
With ScreenshotNeo, inspect X-Page-Verdict and X-Billed to distinguish clean captures from failed or nonbillable responses.
Batch up to 100 URLs when validating a site release, and use asynchronous jobs with signed webhooks for long-running batches.

FAQ

Are OG tags the same as SEO meta tags?

No. OG tags describe a page for Open Graph consumers and social previews. They complement, rather than replace, your document title, canonical link, and other metadata.

Do I need every image property?

The four core properties are the protocol’s required basics. Image type, dimensions, secure URL, and alt text add useful context; the protocol specifically recommends supplying alt text with an image.

Can I define more than one image?

Yes. Repeat og:image. The first image is preferred when values conflict, and each image’s structured properties must follow its own root.

Why does changing a tag appear to do nothing?

Sharing systems can cache fetched metadata. Verify the current raw HTML and image response first, then use the relevant platform’s current debugger or cache-refresh process.

Can I check OG tags without taking a screenshot?

Yes. Fetch the HTML and parse the meta[property^="og:"] elements. Use a screenshot when you also need to verify visual state, overlays, responsive layout, or lazy-loaded content.

Final checklist

og:title, og:type, og:url, and og:image are present in <head>.
URLs are absolute, canonical, public, and use HTTPS where available.
og:image:alt describes the image contents.
Structured image properties are grouped after their corresponding image.
The server response contains the tags before JavaScript runs.
The image URL returns the expected media type and bytes.
A visual capture confirms that the page is not obscured by banners or widgets.