ScreenshotNeo

BlogHow-to

Facebook Open Graph Preview Tool

Find out why a Facebook link preview shows the wrong title, image, or description, and fix it with Facebook’s debugger and a repeatable metadata checklist.

By the ScreenshotNeo team29 September 202610 min read

Facebook Open Graph Preview Tool

A Facebook Open Graph Preview Tool lets you inspect the metadata Facebook reads from a page and see how that information may appear in a link preview. If Facebook shows the wrong image, title, description, or URL, check the page’s Open Graph tags, publish the fix, then submit the page to Facebook’s official parser and debugger and inspect the values it fetched.

The four required Open Graph properties are og:title, og:type, og:image, and og:url. Put them in the document’s <head> and make their URLs absolute and publicly fetchable. The Open Graph Protocol defines these properties; its project identifies Facebook’s Object Debugger as Facebook’s official parser and debugger. See the Open Graph Protocol documentation.

1. What a Facebook Open Graph preview tool checks

A preview inspector reads the Open Graph metadata your page publishes and presents the values available to a social crawler. The preview depends on the page’s source metadata and on what Facebook has fetched and retained. A visual checker can help spot a missing tag or a mismatched image; Facebook’s own debugger is the relevant place to inspect Facebook’s parser and request a refreshed fetch.

Open Graph is a protocol for representing a web page as a rich object in a social graph. The four required fields identify its title, type, representative image, and canonical graph URL. Common optional fields include a description, site name, locale, alternate locales, video, and image metadata such as dimensions, media type, secure URL, and alt text.

2. Required Open Graph tags

Property Purpose Practical guidance
og:title Title associated with the shared object. Use a concise, accurate page title. Avoid relying on a browser title alone.
og:type Identifies the kind of object. Use a suitable type; website is a common general-page value.
og:image Image URL representing the object. Use an absolute URL that Facebook can fetch without a session.
og:url Canonical URL and permanent graph ID. Use the intended canonical page URL, not a temporary or tracking URL.

These are the protocol’s required properties, as documented at ogp.me. If the preview has the wrong image or title, verify the actual HTML head delivered for the exact shared URL rather than assuming the visible page or browser tab determines the card.

Open Graph values in a page’s head supply the fields shown in a social link preview.
Open Graph values in a page’s head supply the fields shown in a social link preview.

3. Useful optional tags and image metadata

Optional tags provide context and more detail. Add only values that accurately describe the page and its assets.

Tag When it helps
og:description A short summary for the preview.
og:site_name The name of the site or publication.
og:locale The primary language and territory, when relevant.
og:locale:alternate Other locales available for the object.
og:video A video associated with the page.
og:image:secure_url A secure URL for the image when a separate one is used.
og:image:type The image media type, such as image/jpeg.
og:image:width and og:image:height Declared dimensions for the image asset.
og:image:alt Text alternative describing the image.

For images, declarations should match the asset actually served. A tag cannot compensate for an image URL that is private, broken, or blocked from fetching.

4. Add the tags to a page

This minimal HTML document shows the placement and syntax. Replace the example domain, copy, and image path with values for your own page. Keep the tags in the server-delivered head so a crawler can find them without depending on client-side rendering.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Example article title</title>
  <link rel="canonical" href="https://example.com/articles/example">

  <meta property="og:title" content="Example article title">
  <meta property="og:type" content="website">
  <meta property="og:url" content="https://example.com/articles/example">
  <meta property="og:image" content="https://example.com/images/example-share.jpg">
  <meta property="og:description" content="A concise summary of this page.">
  <meta property="og:site_name" content="Example Site">
  <meta property="og:image:alt" content="A description of the share image">
</head>
<body>
  <main><h1>Example article title</h1></main>
</body>
</html>

Server-rendered and JavaScript-rendered pages

Many sites assemble pages with a framework or CMS. Confirm that the final response for the public URL contains the intended tags in the head. If the tags appear only after browser JavaScript runs, a crawler that reads an earlier response may not see the final metadata. Prefer server-rendered metadata or the platform’s supported social metadata feature, and inspect the public response after deployment.

  1. Check the exact URL. Identify the URL people share, including its scheme, hostname, path, and any redirect behavior. Confirm the canonical URL you intend to use.
  2. Inspect the page head. Verify all four required tags, their values, and the absolute URLs. Check optional description and image details if you use them.
  3. Confirm public access. Make sure the page and image can be fetched without a login or private session. Check robots rules, firewall restrictions, and other crawl controls that might affect access.
  4. Deploy the correction. Update the source page or CMS fields, publish it, then confirm the changed metadata is served at the public URL.
  5. Submit the URL to Facebook’s official parser/debugger. Review the fetched values and the preview. The debugger is Facebook’s official parser and debugger, according to the Open Graph project’s documentation.
  6. Fix and recheck. If a value remains missing or wrong, correct the source and run the URL through the debugger again when a refreshed fetch is needed.
  7. Check other platforms separately. If you need to compare the same metadata on LinkedIn, X, or other services, use an independent cross-platform preview service. Do not mistake such a service for a Facebook or Meta product.

Facebook link preview refreshes are a fetch-and-cache workflow, so a correct edit in your CMS does not itself prove that the parser has fetched the new version. Use the debugger’s current interface and inspect its results after your update. Tool access requirements and cache timing can change; check the current interface rather than relying on an assumed delay.

6. Why Facebook is showing the wrong image, title, or description

  • Stale fetched metadata: the page changed after Facebook last fetched it. Submit the exact URL to the official debugger after deploying the change and inspect the fetched values.
  • Wrong URL variant: the shared URL and canonical URL may differ, or redirects may lead to another page. Test the URL people actually share and make og:url match the intended canonical identity.
  • Relative or inaccessible image URL: crawlers need a usable, publicly reachable image URL. Use an absolute URL and verify that the asset is not behind authentication or a restrictive firewall.
  • Metadata missing from the delivered head: the tags may be absent from the HTML response or added too late by client-side code. Inspect the deployed page source or response and render the tags server-side where needed.
  • Conflicting metadata: templates, plugins, or multiple components may output duplicate properties. Remove accidental duplicates and keep one authoritative value for each field.
  • Image asset changed at the same URL: a crawler may still have a prior fetch associated with that URL. After confirming the source points to the intended public asset, use the debugger’s refresh workflow and inspect the result.
  • Crawler access blocked: robots rules, bot protection, firewall policy, or a login wall can prevent a successful fetch. Review those controls and the debugger’s reported fetch details.

7. Choosing a Facebook Open Graph preview tool

Use the tool that matches the question you need to answer:

Need Suitable workflow What to verify
Facebook-specific parsing and refresh Facebook’s official Object Debugger. Fetched values, any parser errors, and the displayed preview.
Cross-platform visual comparison An independent preview service such as OG Preview. Which platforms it supports and whether its preview is only an approximation.
Inspecting a page screenshot for visual QA A browser capture workflow or ScreenshotNeo. A screenshot shows rendered appearance; it does not replace Open Graph parsing.

The Facebook Object Debugger is the official Facebook parser/debugger. OG Preview describes a cross-platform preview use case. OpenGraphPro is an independent service that describes Facebook-specific previews of title, image, and description. Verify login needs, crawl access, cache timing, current availability, and any pricing in a service’s live interface before relying on it. Third-party preview tools are not Meta products.

8. Or skip the browser setup

For rendered visual QA alongside metadata debugging, ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. A screenshot helps inspect the page’s visual rendering; use Facebook’s debugger to inspect Facebook’s fetched Open Graph values. The API accepts one GET request and can return PNG, JPEG, WebP, or PDF. See the ScreenshotNeo API documentation.

A visual screenshot can check rendered page appearance while a debugger checks parsed metadata.
A visual screenshot can check rendered page appearance while a debugger checks parsed metadata.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com/articles/example -o shot.webp
import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://example.com/articles/example"}, timeout=90)
open("shot.webp", "wb").write(r.content)
const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com/articles/example' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each cleanup step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, with the result reported in X-Page-Verdict and X-Billed headers. Its MCP server offers take_screenshot, get_page_info, and capture_pdf for Claude, Cursor, and other MCP clients.

The Free plan includes 1,000 shots per month with no card; paid plans start at $5 for 3,000 shots. Plans also include Growth at $15 for 15,000, Pro at $39 for 60,000, Scale at $99 for 250,000, and Business at $249 for 1,000,000; yearly billing gives two months free. Every feature is on every plan. Sign up for 1,000 free screenshots a month, with no card required.

9. Troubleshooting common errors

Symptom Likely cause Fix
No preview fields or incomplete values Required tags are missing or not present in the delivered head. Inspect the public HTML response, add the required properties, deploy, and run the debugger again.
Wrong image persists after an edit Facebook may still be showing data from an earlier fetch, or the tested URL differs from the edited page. Submit the exact shared URL to the debugger and inspect its fetched image URL; correct the source and request another fetch.
Image does not load URL is relative, private, blocked, or points to an unavailable asset. Use an absolute public URL and check the asset directly without an authenticated browser session.
Preview points to another page Redirects or inconsistent canonical and og:url values. Align the canonical and Open Graph URL with the intended page identity, then test the public URL.
Debugger cannot fetch the page Firewall, bot checks, robots rules, or authentication restrict crawler access. Review access controls and the debugger’s fetch details; allow the intended crawler path where appropriate.
Tags look correct in the browser but not in the debugger Client-side rendering or a cache/CDN serves different HTML to crawlers. Check the raw response and deployed template. Ensure the server or edge response includes the tags consistently.

10. Performance, reliability, and maintenance

Open Graph tags are small, but correctness depends on the whole fetch path: page response, canonical behavior, image availability, and crawler access. Keep metadata in the initial HTML response when possible, serve images from stable public URLs, and include only accurate structured values. If you change a page’s title or share image, verify both the deployed source and the result fetched by Facebook.

For a site with many pages, centralize metadata generation in the CMS or page template and make per-page overrides explicit. Add a publishing checklist that checks the four required tags, absolute URLs, and public image access. Revisit representative pages after template changes. A visual screenshot can catch layout issues such as an obscured or blank hero area, but only the debugger tells you the values Facebook parsed.

11. Frequently asked questions

They overlap. An Open Graph validator checks metadata structure; Facebook’s official debugger is specifically useful for seeing Facebook’s parse and preview behavior.

Does changing the page title update an existing Facebook preview?

Not necessarily immediately. Update the Open Graph source and use the official debugger’s fetch workflow to inspect the current parsed values.

Can I use a screenshot tool to verify Open Graph tags?

A screenshot verifies rendered pixels, not the metadata Facebook parsed. Use a parser/debugger for tag values and a screenshot for visual quality assurance.

Should every page use the same og:image?

Use an image that represents the specific page when one is available. Check each page’s tag and make sure its image URL is publicly fetchable.

12. Pre-publication checklist

  • The page has og:title, og:type, og:image, and og:url in the delivered head.
  • Canonical and image URLs are absolute and publicly accessible.
  • Optional description and image metadata are accurate and match the asset.
  • The exact shared URL has been submitted to Facebook’s official debugger after deployment.
  • Any cross-platform preview is labeled and treated as an independent service, not a Facebook product.