Open Graph Image Examples

An Open Graph (OG) image is the image a page declares to represent it in a shared-link preview. The central metadata field is og:image. A practical starting canvas is 1200 × 630 pixels (about 1.91:1), saved as PNG or JPEG and served from an absolute HTTPS URL. Platforms can crop or render the same image differently, so treat examples and dimensions as guidance, then inspect the preview where you plan to share it.

The Open Graph Protocol’s markup example includes og:image and optional image properties for width, height, type, secure URL, and alt text. These tags describe the page’s intended preview; they do not force every platform to show an identical card. Open Graph Protocol documentation.

1. What makes a useful OG image?

A strong OG image gives someone a quick, accurate sense of what the linked page covers, even when displayed small. It should represent that specific page rather than merely repeat a generic site mark. Choose a visual approach that suits the content and is still understandable when reduced.

• Article or guide card: Use a short, legible headline, a small category cue, and restrained branding. Keep the topic recognizable at preview size.
• Product or project card: Show the subject itself and pair it with a concise identifier. Avoid replacing a page-specific visual with an unrelated site logo.
• Minimal brand card: Use a simple graphic, a strong background, and one focal element. For an abstract topic, make sure that focal element still signals the destination.
• Template-driven card: Keep a repeatable layout with a changeable title, subject image, and section label. Check long titles and narrow previews before adopting it across a publishing system.

For example, a developer tutorial could use a small browser-window illustration with a short topic label; a project announcement could show the project’s actual interface or object; and an abstract essay might use a distinct shape or color composition. Those are design patterns, not evidence that any one style improves engagement. Compare options by the target preview context, cropping, legibility, file format and size, and whether you need a one-off graphic or a reusable template.

2. Choose a canvas size and protect the focal content

A broadly useful starting point is 1200 × 630 pixels, approximately a 1.91:1 aspect ratio. OG Image Design recommends this size for cross-platform practicality; it is a specialist recommendation, not a universal platform requirement. The guide also notes that platform ratios differ and that an X large-card view may crop a 1.91:1 source. See the OG Image Design sizing guide.

Keep the most important subject, headline, and any identifying mark away from the edges. OG Image Design suggests a central safe area of roughly 87% of the canvas as a starting point. A safe region cannot guarantee the same crop everywhere, so preview the actual card in the platform you care about.

1. Create the artwork at 1200 × 630 or at the dimensions your publishing pipeline supports.
2. Place essential details with comfortable margins; avoid putting small text or a face right at an edge.
3. Preview the image at reduced size and check that the subject remains obvious.
4. Inspect the rendered link card in the target sharing context, including a narrow or mobile view when relevant.

Prefer PNG or JPEG when compatibility with crawlers is important. The cited sizing guide cautions that SVG may fail with crawlers; use a raster export for a dependable baseline. Platform-specific dimensions and file limits can change, so verify current official platform guidance before treating a limit as fixed.

3. Match the example to the page

The examples below illustrate different communication choices. They are not universal templates: the destination and its audience should determine the image.

Example A: Text-led article card

Use a short version of the article title as the main element, with a modest section label and subtle brand treatment. This works when the page’s argument or subject is easier to identify in words than through a stock image. Keep the wording brief enough to survive a small preview, and avoid shrinking type to fit a long headline.

Example B: Image-led product or project card

Give the actual object or project the most space. Add a concise title to identify it, rather than using a generic company mark as the only visual. This helps the preview point to the specific destination. Keep any interface details simple: a miniature screenshot full of tiny controls may become visual noise at card size.

Example C: Minimal abstract card

Choose one focal graphic, a clear background, and a small amount of text if the topic benefits from it. A simple visual can suit an abstract subject, but it still needs to communicate something about the linked page. Check that it does not become indistinguishable from other cards in a feed.

Example D: Reusable publishing template

Build a consistent composition with a variable title, topic image, and section marker. Test the longest title the system is likely to produce, as well as titles containing punctuation or long words. A template is useful only when its variable content remains readable and the image remains specific to each page.

Across all four patterns, compare text-led and image-led treatments, light and dark backgrounds, and one-off artwork versus a repeatable template. The right choice depends on the destination and the platform’s crop. Do not assume that a design which looks good in an image editor will display unchanged in every preview.

4. Add Open Graph image metadata

Put the tags in the HTML document’s <head>. Use a publicly reachable, fully qualified HTTPS image URL. The example below declares the image URL, its dimensions, and descriptive alt text:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta property="og:title" content="A Practical Guide to Link Previews">
  <meta property="og:type" content="article">
  <meta property="og:url" content="https://example.com/guides/link-previews">
  <meta property="og:image" content="https://example.com/images/link-previews.png">
  <meta property="og:image:width" content="1200">
  <meta property="og:image:height" content="630">
  <meta property="og:image:type" content="image/png">
  <meta property="og:image:alt" content="Illustration of a webpage represented by a shared link preview">
</head>
<body>
  <h1>A Practical Guide to Link Previews</h1>
</body>
</html>

The dimensions, type, and alt properties are optional protocol fields. Include dimensions that match the actual file, and describe what the image depicts in alt text. Alt text should explain the image rather than act as a promotional caption. An absolute HTTPS URL gives crawlers an unambiguous address; a relative path such as /images/share.png is not a suitable replacement for the fully qualified URL in the example.

When a page is rendered by a framework, make sure these tags are present in the HTML response crawlers receive. If metadata is added only after client-side JavaScript runs, a crawler that reads the initial response may not see it. The general check is to inspect the response HTML and confirm that the final page-specific values are present in the document head.

5. Generate a preview image from a webpage

If your OG artwork is a rendered page or a page-specific visual, capture the page after it has loaded and save the output at the size and format your publishing system expects. With a local browser setup, keep the capture reproducible: set the viewport, wait for the relevant content, and save the intended page rather than a browser chrome screenshot.

For a first-party workflow, a browser automation tool can navigate to the public page, set a 1200 × 630 viewport, wait for a stable element, and capture the page or a selected element. A full-page capture may have a different aspect ratio than an OG canvas, so use a designed composition or crop/resize the resulting artwork to the intended dimensions. Check the result before publishing.

Once you have an image file, publish it at a stable public HTTPS address, then use that exact address in og:image. Do not point the metadata to a private development host, a temporary file, or a URL that requires a logged-in session.

6. Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server for developers. One GET request can return a screenshot as PNG, JPEG, or WebP, or a PDF. It can capture a page or one element, set a viewport and device preset, use full-page capture with lazy images loaded, apply custom CSS or JavaScript, wait for a selector, delay, or network idle, and resize the output. See the ScreenshotNeo documentation.

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

import requests

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

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com/guides/link-previews',
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const bytes = new Uint8Array(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', bytes));

Cookie banners, newsletter popups, and chat widgets are removed before the shot; each cleanup step can be turned off. Bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and the response identifies the page verdict and billing status in headers. An MCP server provides take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 shots. Every feature is on every plan. Sign up for 1,000 free screenshots a month, no card required.

7. Verify the published card

After deployment, inspect the page source or fetched HTML and check the final metadata values. Then preview the URL in the platform where it will be shared. This verifies two separate things: the page declares the intended image, and the platform’s crawler can fetch and render a card from it.

• Confirm og:image is present once with the intended absolute HTTPS URL.
• Check the image URL directly in a browser without authentication.
• Confirm the file is a supported raster format and that the declared dimensions match it.
• Review the actual card crop and legibility at the target preview size.
• After changing image metadata, inspect the preview again; a correct page tag does not guarantee that a platform will refresh its cached result immediately.

8. Troubleshooting missing or incorrect previews

Symptom	Likely cause	What to check or change
No image appears	The crawler cannot fetch the image, or the metadata is missing from the HTML it reads.	Use a public absolute HTTPS URL; open it without a login; inspect the returned page HTML for og:image.
A stale image appears	The platform may be using a cached page or image result.	Verify the current metadata and image URL, then use the platform’s available preview inspection or refresh workflow.
The crop cuts off the title or subject	The platform uses a different crop or card ratio.	Move essential content inward, use the central safe area as a starting point, and preview the actual card.
The image is broken for crawlers	The URL may be relative, inaccessible, or served in a format the crawler does not handle.	Use an absolute HTTPS URL and a PNG or JPEG baseline; check for redirects, access controls, and a valid image response.
The card shows generic or wrong artwork	The page may point to a site-wide default or the metadata may not be page-specific.	Set a relevant image URL for this page and check for duplicate or conflicting metadata.
The image is correct but text is unreadable	Important copy is too small or too close to the image edge.	Simplify the headline, enlarge the subject, preserve margins, and review the graphic at reduced size.
The page source has no OG tags	The framework may add metadata only after client-side rendering.	Ensure the server-rendered or statically generated HTML includes the tags in its head.

9. Performance, reliability, and cost considerations

For a published page, a stable static image URL makes the metadata easy to inspect and avoids depending on an interactive editor or private session at fetch time. Keep the artwork and its metadata coordinated when titles or page subjects change. A template can reduce repeated design work, but include a check for long titles and unusual content.

For automated page captures, wait for the content that matters rather than capturing too early. A selector wait can be more predictable than an arbitrary short delay when the page has a clear content element; network idle can help for quieter pages but may not be reached on pages with continuous requests. Lazy-loaded images may need scrolling or a full-page capture workflow that loads them. Validate output dimensions and format before publishing.

Browser-based capture has setup and runtime costs that depend on the environment and workload, so measure your own pages if capture volume matters. With a hosted API, review the plan and usage model before scaling. ScreenshotNeo’s stated options are Free at 1,000 shots/month with no card; Starter $5 for 3,000; Growth $15 for 15,000; Pro $39 for 60,000; Scale $99 for 250,000; and Business $249 for 1,000,000. Yearly billing gives two months free. The service says only clean shots are billed and reports the page verdict and billing status in X-Page-Verdict and X-Billed headers. Treat those headers as useful for accounting and diagnosis, and consult the ScreenshotNeo site and docs for current implementation details.

10. Frequently asked questions

Is an OG image the same as a page’s featured image?

It can be the same file, but the terms describe different roles. A featured image is a publishing or page-design concept; og:image is the metadata field that declares the image intended for a shared-link preview.

Does adding og:image guarantee a preview?

No. The tag identifies the intended image, while fetching, caching, and card rendering are handled by the platform. Inspect the preview after publishing.

Should the OG image include the article title?

It can, especially for a text-led card, but keep the wording short and check it at reduced size. An image-led design may identify the page without repeating its full headline.

Can I use one image for every page?

You can, but a page-specific image can communicate the destination more clearly. If you use a shared template, vary its subject and title so each card represents its own page.

Which format should I start with?

PNG or JPEG is a sensible compatibility baseline according to the cited specialist sizing guidance. Verify the target platform’s current recommendations for exact requirements.