Open Graph Images: The Complete Guide
Learn how og:image works, which metadata to add, how to choose image dimensions, and how to debug inconsistent link previews.
An Open Graph image is the image a webpage declares to represent itself when shared. Set its URL in og:image inside the page’s HTML <head>, alongside the basic Open Graph properties og:title, og:type, and og:url. The destination service reads that metadata and decides how to display the preview; the protocol does not guarantee a particular crop or card layout.
For a reliable starting point, publish a publicly reachable image URL, include a concise og:image:alt, keep any declared dimensions accurate, and test the actual page on the services your audience uses. LinkedIn’s sharing module, for example, specifies a minimum image size of 1200 × 627 pixels and a maximum file size of 5 MB. Those are LinkedIn-specific requirements, not universal Open Graph rules. Open Graph protocol · LinkedIn Help: Make your website shareable
1. What an Open Graph image is
The Open Graph protocol defines metadata that describes a webpage or other object to services that consume it. The og:image property contains the URL of an image that represents that object. It points to an image; it is not an image format, a generated preview, or a guarantee that every platform will show the image exactly as intended.
The protocol’s four basic properties are:
og:title: the title to associate with the object.og:type: the object type, such aswebsite.og:image: the representative image URL.og:url: the canonical URL used as the object’s permanent graph identifier.
These tags belong in the document head. Use absolute URLs for both the canonical page and the image so a consumer can resolve them without guessing a base path. The protocol also defines optional properties such as og:description, og:site_name, and og:locale.
2. Add the tags to your page
Here is a complete static HTML example. Replace the sample domain, paths, title, description, and alt text with values for the page you are publishing. The image URL should point directly to the actual image file.
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Product documentation</title>
<meta name="description" content="A practical guide to the product.">
<meta property="og:title" content="Product documentation">
<meta property="og:type" content="website">
<meta property="og:url" content="https://example.com/docs/">
<meta property="og:image" content="https://example.com/images/docs-share.jpg">
<meta property="og:image:alt" content="A person reviewing product documentation on a laptop">
<meta property="og:image:type" content="image/jpeg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="627">
<meta property="og:description" content="A practical guide to the product.">
<meta property="og:site_name" content="Example">
</head>
<body>
<main><h1>Product documentation</h1></main>
</body>
</html>The structured image properties are optional protocol properties, but they help describe the image. og:image:alt is a description of what is shown, not a caption. If you supply MIME type, width, or height, make sure each matches the file actually served. For more detail, see the Open Graph protocol reference.
Server-rendered and JavaScript-rendered pages
For a static page or server-rendered app, emit the tags in the initial HTML response. For a JavaScript app, verify what the server returns before client-side code runs. A browser may display metadata inserted later by JavaScript, while a preview consumer may read a different representation or fail to execute the same client code. View the fetched HTML source and check that the tags are present there.
Use one coherent metadata set per canonical page. If a framework has a head or metadata component, generate the values from the page’s canonical route and content rather than copying one global image tag across every page. Keep og:url aligned with the URL you consider canonical; otherwise, two URLs for the same content can be interpreted as different objects.
3. Choose an image size and format
There is no single image size established by the Open Graph protocol for every social service. The right dimensions depend on the destination’s current guidance and how its card crops or places the image. One verified example is LinkedIn’s sharing module: its help page lists a minimum of 1200 pixels wide by 627 pixels high and a maximum file size of 5 MB. Apply those requirements to that sharing use case; do not assume they establish requirements for every platform.
A 1200 × 627 pixel canvas can be a practical starting asset when LinkedIn is a target, but check each other destination independently. Keep key subjects away from the extreme edges so a tighter crop does not remove them. Export at the intended dimensions, inspect the actual file, and avoid publishing a page whose metadata claims a width or height that differs from the asset.
Choose a format supported by the destinations and your asset pipeline, and ensure the image URL returns the image itself rather than an HTML page, authentication prompt, or redirect loop. The protocol’s og:image:type property can state a MIME type such as image/jpeg; that declaration should reflect the served file. Do not treat the property as a substitute for correct HTTP delivery.
4. Multiple images and structured properties
The protocol allows multiple values for properties that can be arrays. If you publish multiple og:image tags, order them deliberately: the first tag in document order is preferred when values conflict. A consumer may handle alternatives differently, so multiple tags are not a reliable way to force a particular image on every service.
Keep each image’s structured properties grouped with its root tag and before declaring the next image. This makes it clear which width, height, type, or alt description belongs to which image.
<meta property="og:image" content="https://example.com/images/share-wide.jpg">
<meta property="og:image:alt" content="A wide view of the product dashboard on a monitor">
<meta property="og:image:type" content="image/jpeg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="627">
<meta property="og:image" content="https://example.com/images/share-square.jpg">
<meta property="og:image:alt" content="A close-up of the product dashboard">
<meta property="og:image:type" content="image/jpeg">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="1200">If one image is your intended default, make it first. Remove stale duplicate tags inserted by a theme, plugin, or layout as well; a correct-looking second tag may not be the preferred value when an earlier tag conflicts.
5. Validate a preview from source to destination
- Inspect the page response. Fetch or view the page’s HTML source and confirm the intended tags appear in the head. Check for duplicate or conflicting metadata.
- Open the image URL directly. Confirm it loads without a login, broken redirect, or access restriction. Compare the served file’s dimensions and format to the metadata.
- Check canonical identity. Confirm
og:urlis the canonical page URL and that the page is accessible at that address. - Test each destination that matters. Social services differ in what they read and how they render previews. Validate a real URL on each target rather than inferring one service’s behavior from another.
- Separate metadata from presentation. If the tags and image are correct but a card looks different, the service’s crop, cache, and rendering choices may explain the difference. Check that destination’s own current tools and guidance.
A screenshot is useful for checking what a browser renders at a URL, but it does not by itself prove what Open Graph tags a crawler read. Inspect the HTML metadata for that. To visually check the page itself, ScreenshotNeo can capture a URL as an image or PDF; its API supports options such as full-page capture, viewport and device settings, and waiting for page content.
6. Common problems and fixes
| Symptom | Likely cause | What to check or change |
|---|---|---|
| No image appears | The tag is missing from the returned HTML, the image URL is inaccessible, or the URL does not return an image. | Inspect the initial HTML response and open the image URL directly. Correct the URL or server response, then validate again on the destination. |
| The wrong image appears | An earlier og:image tag, duplicate metadata, or an older preview may be involved. |
Search the full HTML for every og:image tag. Put the intended default first and consult the destination’s current cache tools or guidance. |
| The image looks cropped | The platform controls card presentation, and its crop may differ from the source canvas. | Keep important content within a safe central area. Preview the real URL on the target service and adjust the asset for that destination. |
| The preview title or description is stale | The tags may be outdated, duplicated, or cached by the destination. | Check og:title and og:description in the delivered HTML, then use destination-specific cache refresh guidance where available. |
| Declared dimensions do not match the file | Image metadata was copied from a previous asset. | Measure the current asset and update or remove the inaccurate width and height values. |
| Preview works in a browser but not when shared | The browser may see client-rendered tags or an authenticated/local image that the preview consumer cannot access. | Check the raw response, use a public image URL, and emit metadata in the initial HTML when possible. |
| One platform differs from another | Services can use different metadata, cache, and rendering behavior. | Test the destination independently. Do not assume one service’s result proves another will use the same crop or card layout. |
7. Performance, reliability, and maintenance
Open Graph tags add little work to a page, but the image they reference must be available when a service requests it. Host it at a stable, publicly reachable URL and avoid changing the image in place without a plan for how destinations may retain older previews. When the artwork changes, verify the page source and follow the destination’s own cache refresh process if it provides one; the available platform guidance varies.
Keep generated metadata deterministic. Build title, description, canonical URL, and image URL from the page record or route so a deploy does not accidentally expose empty tags or the same generic image everywhere. For localized pages, set locale metadata when appropriate and make sure the visible page, canonical URL, and declared preview content agree.
For operational debugging, record the page URL, the HTML metadata at the time of the check, and the destination where the preview was inspected. This distinguishes a publishing regression from destination-specific rendering or caching behavior. A browser screenshot can help document appearance, while the source HTML remains the evidence for what metadata the page emitted.
8. Or skip the browser setup
If you need a rendered screenshot of the page while checking its real browser output, ScreenshotNeo provides a one-call website screenshot API. It does not replace inspection of Open Graph tags in the HTML, but it can make visual page checks straightforward. See the ScreenshotNeo API documentation.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o shot.webpimport requests
r = requests.get(
"https://api.screenshotneo.com/v1/shot",
params={"access_key": "YOUR_API_KEY", "url": "https://example.com"},
timeout=90,
)
open("shot.webp", "wb").write(r.content)const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const fs = await import('node:fs/promises');
await fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));- Cookie banners, popups, and chat widgets are removed before the shot.
- Bot checks, blank pages, and failed loads are never billed; response headers report the page verdict and billing status.
- An MCP server lets AI agents, including Claude and Cursor, take screenshots.
- 1,000 screenshots a month are free with no card; paid plans start at $5 for 3,000 screenshots.
Sign up for ScreenshotNeo’s free plan: 1,000 screenshots a month, no card required.
9. Frequently asked questions
Is an Open Graph image the same as a featured image?
It can be the same asset, but the terms describe different roles. A CMS featured image is a content field; og:image is metadata that points to the image a page declares for sharing.
Does adding og:image guarantee a preview image?
No. It declares the representative image in the page metadata. A destination controls how it reads, caches, and renders that information.
Should I add og:image:alt?
Yes. The protocol says an image should be accompanied by this property. Describe what the image shows; it is not intended as a caption.
Can I use different images for different social platforms?
The protocol permits multiple image values and gives preference to the first in document order. Platform handling can differ, so test the destination and do not rely on ordering alone to guarantee a platform-specific result.
What image size should I use?
Check the current requirements of each destination. LinkedIn’s cited sharing-module guidance specifies a 1200 × 627 pixel minimum and 5 MB maximum; that does not define a universal size for all services.
Can a screenshot tool tell me which Open Graph tag was read?
A rendered screenshot shows browser appearance, not necessarily crawler metadata. Inspect the page’s delivered HTML to verify its tags, then use a screenshot for visual QA.
