Open Graph and Twitter Card Tags

Open Graph metadata controls how a web page is represented when another service reads its URL. The official Open Graph Protocol defines four required properties in the document head: og:title, og:type, og:image, and og:url. Add those first, then provide image details and any application-specific metadata your publishing system needs.

The smallest useful implementation looks like this:

<head>
  <meta property="og:title" content="Open Graph and Twitter Card Tags">
  <meta property="og:type" content="article">
  <meta property="og:image" content="https://example.com/images/article-cover.jpg">
  <meta property="og:url" content="https://example.com/guides/open-graph-twitter-card-tags">
  <meta property="og:image:alt" content="A diagram showing metadata becoming a social link preview">
</head>

The Open Graph Protocol specification describes Open Graph as a way for any web page to become a rich object in a social graph. Treat og:url as the permanent identifier for the page represented by the metadata, and make it match your canonical URL.

1. The four required Open Graph properties

Property	What it represents	Implementation guidance
`og:title`	The title of the object in the graph	Use the page title readers should recognize. Keep it aligned with the visible heading.
`og:type`	The kind of object	Use the type that describes the page, such as `article` for an article.
`og:image`	A representative image URL	Use a complete, fetchable URL to the image that best represents the page.
`og:url`	The canonical, permanent object identifier	Use one normalized URL for the page, including the preferred protocol and host.

Some object types can require additional properties. Add those only when they describe information your page actually has.

2. Complete image metadata

When you declare og:image, also declare og:image:alt. The alt value should describe what is visible in the image; it should not be used as a caption or a keyword list.

<meta property="og:image" content="https://example.com/images/article-cover.jpg">
<meta property="og:image:secure_url" content="https://example.com/images/article-cover.jpg">
<meta property="og:image:type" content="image/jpeg">
<meta property="og:image:width" content="1600">
<meta property="og:image:height" content="900">
<meta property="og:image:alt" content="A diagram showing metadata becoming a social link preview">

Property	Purpose
`og:image:url`	An alias identical to `og:image`.
`og:image:secure_url`	An HTTPS alternative URL for the same image.
`og:image:type`	The image MIME type, such as `image/jpeg` or `image/png`.
`og:image:width`	The image width in pixels.
`og:image:height`	The image height in pixels.
`og:image:alt`	A text description of the image.

Declare dimensions and MIME type that match the actual asset. A mismatch makes debugging harder and can cause a consumer to reject or misinterpret the image.

3. Multiple images and structured properties

Open Graph properties that allow multiple values can be repeated. When values conflict, the first value has preference. Keep structured properties directly after the root property they describe so the association is unambiguous.

<meta property="og:image" content="https://example.com/images/primary.jpg">
<meta property="og:image:alt" content="The primary illustration for the article">
<meta property="og:image:type" content="image/jpeg">
<meta property="og:image:width" content="1600">
<meta property="og:image:height" content="900">

<meta property="og:image" content="https://example.com/images/alternate.jpg">
<meta property="og:image:alt" content="An alternate illustration for the article">
<meta property="og:image:type" content="image/png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">

Put each image’s alt text, type, and dimensions before declaring the next og:image. Choose the first image carefully because consumers that select only one value will generally use it.

4. A production-ready head example

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Open Graph and Twitter Card Tags</title>
  <link rel="canonical" href="https://example.com/guides/open-graph-twitter-card-tags">

  <meta property="og:title" content="Open Graph and Twitter Card Tags">
  <meta property="og:type" content="article">
  <meta property="og:url" content="https://example.com/guides/open-graph-twitter-card-tags">
  <meta property="og:image" content="https://example.com/images/article-cover.jpg">
  <meta property="og:image:secure_url" content="https://example.com/images/article-cover.jpg">
  <meta property="og:image:type" content="image/jpeg">
  <meta property="og:image:width" content="1600">
  <meta property="og:image:height" content="900">
  <meta property="og:image:alt" content="A diagram showing metadata becoming a social link preview">
</head>
<body>
  ...
</body>
</html>

5. Adding tags in common rendering setups

Static HTML

Place the tags inside <head> in the generated HTML. Ensure the values are present in the initial response if a crawler does not execute your client-side JavaScript.

Server-side templates

Generate values from the same page record used for the visible title and canonical link. Escape attribute values, and provide a fallback image when an article has no custom cover.

Client-rendered applications

Prefer server-side rendering or prerendering for metadata. If tags are inserted only after hydration, a consumer that reads the initial HTML may see no Open Graph properties.

6. Twitter/X card metadata: what can be stated safely

This research does not establish a current authoritative X Cards markup guide. The available official X Developer result is a Tweet data dictionary, not documentation for page-card metadata. Third-party claims about card variants, crawler behavior, image limits, fallbacks, or validator tools should therefore be checked against current official X documentation before you publish them as requirements.

Open Graph tags are still valuable because they provide the verified metadata for the page itself. If your organization maintains X-specific tags, document the source and review it when X publishes updated guidance. Do not assume an unverified card rule is permanent.

7. How to choose an image

Choose the image that explains the page without relying on surrounding text.
Use a stable HTTPS URL that returns the image directly.
Declare the real MIME type and pixel dimensions.
Write og:image:alt as a concise visual description.
Keep the first image declaration as the preferred option when several images are available.

The protocol material reviewed does not prescribe one universal image size. Your comparison should focus on representation, reachability, correct metadata, and accurate alt text.

8. Troubleshooting checklist

Symptom	Likely cause	Fix
No preview data	The four required properties are missing from the initial HTML.	Render `og:title`, `og:type`, `og:image`, and `og:url` in the document head.
Wrong page appears	`og:url` differs from the intended canonical URL or contains an accidental query string.	Normalize the canonical URL and make `og:url` match it.
Wrong image appears	A different image is declared first, or structured fields are attached to the wrong root.	Move the preferred image first and keep its structured fields immediately below it.
Image is rejected	The URL is inaccessible, the response is not an image, or MIME and dimensions are incorrect.	Request the URL directly, verify the response headers and file, then correct the metadata.
Alt text is missing	`og:image:alt` was omitted.	Add a description whenever `og:image` is present.
Tags appear in browser tools but not to a crawler	Tags are injected after client-side rendering.	Move them into server-rendered HTML or generate a prerendered page.
Old preview persists	A consumer has cached an earlier fetch.	Confirm the current response first, then follow that service’s current refresh process.

9. Reliability, performance, and security

Generate metadata from one canonical page model so the title, URL, and image do not drift.
Keep image assets on a reliable HTTPS origin and avoid URLs that require an authenticated session.
Return the head quickly in server-rendered responses; do not make metadata depend on a slow client request.
Cache generated metadata and images according to your publishing workflow, while changing the URL when you intentionally replace an asset.
Escape user-supplied titles, URLs, and alt text before placing them in HTML attributes.
Do not put secrets, tokens, or private query parameters in public metadata URLs.

10. Generate representative images with ScreenshotNeo

If the page needs a fresh visual for og:image, ScreenshotNeo can capture a URL as PNG, JPEG, WebP, or PDF. It can capture a full page, a CSS-selected element, or a chosen viewport, and supports custom CSS and JavaScript, device presets, dark mode, waiting rules, request blocking, and caching.

cURL

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

Python

import requests

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

Node.js

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com/article'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot failed: ${res.status}`);
require('fs').writeFileSync('article.webp', Buffer.from(await res.arrayBuffer()));

See the ScreenshotNeo documentation for the complete option list and response details.

Or skip the browser setup

One ScreenshotNeo request returns the image you can use as an Open Graph asset:

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

Before capture, cookie and consent banners, newsletter popups, and chat widgets are removed. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and response headers identify the page verdict and billing status. ScreenshotNeo also provides an MCP server for AI agents using Claude, Cursor, or another MCP client. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account.

11. FAQ

Do I need every Open Graph property?

Start with og:title, og:type, og:image, and og:url. Add image structured properties and type-specific fields when they apply.

Is `og:image:url` different from `og:image`?

The protocol lists og:image:url as identical to og:image.

What belongs in `og:image:alt`?

Describe the visible content of the image. Do not use it as a caption, title, or keyword list.

Can I publish exact Twitter/X image requirements from this guide?

No. The available research does not contain a current authoritative X Cards markup specification, so verify any X-specific rule against current official documentation.

Why is the first image important?

Repeated values are allowed, but the first value has preference when values conflict or a consumer selects one image.