What Is the Metadata og:image Used For?
The og:image tag supplies the image shown in link previews. Learn how to add it, describe it, debug it, and verify what crawlers can access.
Direct answer: og:image is an Open Graph metadata property that gives social networks and other Open Graph consumers an image URL to use when they represent a web page as a rich link preview. You declare it in the document’s HTML <head>:
<meta property="og:image" content="https://example.com/images/article-preview.jpg">
The image is a candidate, not a guaranteed command. Each consumer can fetch, validate, crop, cache, or replace it. Google also considers og:image among several sources when choosing an image preview, but its selection is automated.
What og:image does
The Open Graph protocol lets a web page become a rich object in a social graph. Its four basic properties are og:title, og:type, og:image, and og:url. og:image identifies the image that represents the page when a URL is shared or otherwise rendered as a rich object. See the Open Graph protocol documentation.
It is metadata, not visible page content. Visitors normally do not see the tag itself. A crawler reads the tag, downloads the referenced image, and uses it according to that service’s preview rules.
Minimal implementation
Put the tag in the page’s <head>, using an absolute URL that crawlers can request:
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Example article</title>
<meta property="og:title" content="Example article">
<meta property="og:type" content="article">
<meta property="og:url" content="https://example.com/articles/example">
<meta property="og:image" content="https://example.com/images/example-preview.jpg">
<meta property="og:image:alt" content="A diagram illustrating the example article">
</head>
<body>...</body>
</html>
Use the canonical URL in og:url, and make the image URL stable. A relative path such as /images/example.jpg is less portable because consumers may resolve it differently or reject it.
Structured image properties
The protocol defines optional properties that add information about the image:
| Property | Purpose | Example |
|---|---|---|
og:image:alt |
Description of what the image shows; it is not a caption. | A diagram of the deployment flow |
og:image:width |
Pixel width. | 1200 |
og:image:height |
Pixel height. | 630 |
og:image:type |
MIME type. | image/jpeg |
og:image:secure_url |
HTTPS alternative URL. | https://example.com/images/example.jpg |
og:image:url |
Alias for og:image. |
https://example.com/images/example.jpg |
The protocol recommends supplying og:image:alt whenever og:image is present. Keep the description factual and specific.
<meta property="og:image" content="https://example.com/images/example.jpg">
<meta property="og:image:alt" content="A product dashboard displayed on a laptop">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:type" content="image/jpeg">
<meta property="og:image:secure_url" content="https://example.com/images/example.jpg">
Multiple og:image tags
You can declare more than one image. When consumers find a conflict, the protocol says the first image, from top to bottom, is preferred. Put each image’s structured fields immediately after its root declaration and before the next root image:
<meta property="og:image" content="https://example.com/images/landscape.jpg">
<meta property="og:image:alt" content="A landscape preview of the article">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image" content="https://example.com/images/square.jpg">
<meta property="og:image:alt" content="A square version of the article preview">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="1200">
Use ordering deliberately. Do not assume a consumer will select the second image because it better fits a particular app.
How to inspect og:image yourself
With cURL
curl -L --max-time 20 https://example.com/article | grep -i 'property="og:image"'
This works only when the metadata is present in the server response. If JavaScript inserts the tag after load, a plain HTTP client will not see it.
With Python
import requests
from bs4 import BeautifulSoup
url = "https://example.com/article"
r = requests.get(url, timeout=20)
r.raise_for_status()
soup = BeautifulSoup(r.text, "html.parser")
for tag in soup.find_all("meta", attrs={"property": "og:image"}):
print(tag.get("content"))
With Node.js
const res = await fetch('https://example.com/article');
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const html = await res.text();
const matches = [...html.matchAll(/<meta[^>]+property=["']og:image["'][^>]+content=["']([^"']+)["'][^>]*>/gi)];
console.log(matches.map((m) => m[1]));
For production parsing, use an HTML parser instead of a regular expression so attribute order, quoting, and escaped values do not cause false negatives.
How Google uses it
Google says image-preview selection is automated and can draw on several sources, including og:image. It recommends a relevant, representative, high-resolution image and advises against a generic site logo or an extreme aspect ratio. These recommendations influence selection; they do not guarantee which image Google displays. Read Google’s Image SEO best practices.
- Choose an image that represents the specific page.
- Keep the subject clear at the likely preview size.
- Provide useful dimensions and alt text.
- Do not rely on a logo as the only page image.
- Expect different consumers to crop or choose differently.
Common errors and fixes
| Symptom | Likely cause | Fix |
|---|---|---|
| No image in a link preview | The tag is missing, malformed, or outside <head>. |
Inspect the raw HTML response and add a valid absolute URL in <head>. |
| The old image still appears | The consumer cached an earlier response or image. | Confirm the current HTML and image URL; allow time for the consumer to recrawl. |
| Wrong image appears | Another og:image appears earlier, or the consumer selected another source. |
Remove unintended duplicates and put the preferred image first. |
| Image works in a browser but not in previews | The image host blocks the crawler, requires authentication, or redirects unexpectedly. | Serve the image at a publicly fetchable HTTPS URL and verify its response headers. |
| Metadata is visible in a browser inspector but not with cURL | JavaScript adds it after page load. | Render the page with a browser, or emit the tags during server-side rendering. |
| Preview is badly cropped | The image has an unsuitable aspect ratio or important content near an edge. | Use a representative composition with safe margins and a practical aspect ratio. |
| Broken image icon | The URL returns an error, an HTML error page, or an incorrect content type. | Request the image directly and check status, redirects, permissions, and MIME type. |
Performance, reliability, and maintenance
- Keep the asset reachable: use a stable HTTPS URL and avoid expiring query-string URLs.
- Keep HTML early and simple: server-render the tags when possible so crawlers do not need to execute JavaScript.
- Use a suitable file: high resolution helps, but very large files increase download time and processing cost.
- Version intentional changes: changing the image URL can help distinguish a new asset, while changing only the bytes at the same URL may remain hidden by caches.
- Validate every template: test article, product, pagination, error, and localized templates separately.
Or skip the browser setup
If you need a dependable rendered image of a page after its metadata, consent UI, and client-side content have loaded, ScreenshotNeo provides a website screenshot API and MCP server. One request returns PNG, JPEG, WebP, or PDF. It can remove cookie banners, newsletter popups, and chat widgets before capture; bot checks, blank pages, timeouts, failed loads, and cache hits are not billed. An MCP server lets AI agents take screenshots, inspect pages, and capture PDFs.
See the ScreenshotNeo API documentation for all options.
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}`);
Free accounts include 1,000 screenshots per month with no card. Paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account.
FAQ
Is og:image required for every page?
No. A page can work without it, but previews may lack a representative image or use an image selected from another source.
Does og:image control Google Images?
No. Google’s image selection is automated and uses multiple signals. og:image is one possible source.
Is og:image:alt the same as a caption?
No. It describes the image for the consumer; it is not visible caption text.
Can I use a data URL?
A publicly fetchable absolute image URL is the most interoperable choice. Consumers may reject data URLs or other nonstandard schemes.
Why do different apps show different images?
Each consumer has its own crawler, cache, validation, cropping, and fallback behavior. The first declared image is the Open Graph preference when declarations conflict, but rendering is still consumer-specific.


