Why Does Facebook Crop My Open Graph Image?

Facebook may crop your Open Graph image because the image’s aspect ratio does not fit the preview layout. It may also show the wrong image if the page’s og:image points elsewhere, Facebook’s crawler cannot retrieve the intended file, or Facebook is using previously scraped metadata.

A practical starting point is a 1200 × 630 pixel image, approximately 1.91:1, with important content kept away from the edges. That is Facebook-oriented guidance, not a requirement of the Open Graph protocol or a guarantee that every preview placement will use the same crop. [Wix Help Center guidance; Open Graph protocol]

Why the preview is cropped or unexpected

The image shape does not fit the preview

A preview layout can trim the edges of an image that has a different shape. Facebook-attributed guidance reported by Wix recommends an aspect ratio close to 1.91:1 and a 1200 × 630 pixel canvas. The exact appearance can vary by preview context, so treat those numbers as a useful target rather than a universal rendering guarantee. [Wix Help Center]

The page selects a different image

The page’s og:image property identifies the image associated with that page. If it points to a default image, an old file, or a different page asset, Facebook can show that image regardless of which image you intended to share. Open Graph defines the property’s purpose; it does not mandate one pixel size. [Open Graph protocol]

Facebook has not fetched the current page information

After metadata or artwork changes, Facebook may still display information from an earlier scrape. Use Facebook’s Sharing Debugger to submit the shared page URL again and inspect the information it fetches. Wix recommends this refresh step after changing og:image. The available sources do not establish a universal cache duration. [Wix Help Center]

The crawler cannot retrieve the intended asset

If the image URL is inaccessible to the crawler, the preview may not use the intended asset. Check that the URL in the page’s metadata is the actual image, is publicly fetchable, and returns the image file rather than an error or an HTML page. Then inspect the image Facebook reports in the Sharing Debugger.

How to diagnose and fix the crop

1. Check the page metadata. Inspect the HTML Facebook can fetch and confirm that the page’s <head> contains the expected og:image URL. Confirm it is the page’s intended image, not a site-wide default or an outdated filename.
2. Open the image URL directly. Verify that it loads as an image without a login, a redirect to an error page, or a browser-only session requirement.
3. Check dimensions and proportions. Use 1200 × 630 pixels (about 1.91:1) as a practical Facebook-oriented starting point. Wix reports a 200 × 200 pixel minimum, recommends at least 600 × 315 for a larger preview, and reports an 8 MB maximum. These are secondary, Facebook-attributed guidance, not Open Graph protocol requirements. [Wix Help Center; Open Graph protocol]
4. Recompose for edge tolerance. Keep faces, logos, and essential text toward the middle instead of close to the outer edges. A suitable aspect ratio reduces the likelihood of unwanted trimming but cannot guarantee identical rendering in every context.
5. Publish the image and metadata. Make sure the live page serves the updated HTML and image file at the URLs you intend to share.
6. Refresh and inspect the scrape. Submit the shared page URL to the Facebook Sharing Debugger. Check which image and metadata it fetched before making more artwork changes.
7. Test the final shared URL. Preview the same page URL you plan to share. A different URL or page can have different metadata.

Generate and inspect an Open Graph image

You can create an image at the recommended canvas size with a graphics editor, or generate one from HTML and CSS in a browser. The example below uses Playwright with Node.js to render a 1200 × 630 image. It is a local image-generation example; it does not set your site’s metadata or refresh Facebook’s scrape.

npm install playwright
npx playwright install chromium

// og-image.mjs
import { chromium } from 'playwright';

const browser = await chromium.launch({ headless: true });
const page = await browser.newPage({
  viewport: { width: 1200, height: 630 },
  deviceScaleFactor: 1
});

await page.setContent(`
  <!doctype html>
  <html>
    <head>
      <style>
        * { box-sizing: border-box; }
        body {
          margin: 0;
          width: 1200px;
          height: 630px;
          display: grid;
          place-items: center;
          background: #10223a;
          color: white;
          font: 700 64px system-ui, sans-serif;
        }
        main { width: 960px; text-align: center; }
      </style>
    </head>
    <body><main>A clear, centered headline</main></body>
  </html>
`);

await page.screenshot({ path: 'og-image.png' });
await browser.close();

Replace the sample headline and styling, then check the saved file’s dimensions and file size. Keep the design legible with its content safely inside the canvas. Host the final image at a stable, publicly accessible URL and set that exact URL in the page’s og:image metadata.

Check the image and metadata with a browser

A browser-based screenshot can help you inspect how a page looks when rendered, but it does not tell you by itself which Open Graph metadata Facebook fetched. Inspect the page HTML and use the Sharing Debugger for the scrape result. For a quick visual check, you can capture the live page with Playwright:

npm install playwright
npx playwright install chromium

// inspect-page.mjs
import { chromium } from 'playwright';

const url = process.argv[2];
if (!url) throw new Error('Usage: node inspect-page.mjs https://example.com');

const browser = await chromium.launch({ headless: true });
const page = await browser.newPage({ viewport: { width: 1200, height: 800 } });
await page.goto(url, { waitUntil: 'networkidle', timeout: 60000 });
console.log(await page.locator('meta[property="og:image"]').getAttribute('content'));
await page.screenshot({ path: 'page.png', fullPage: true });
await browser.close();

Run it with node inspect-page.mjs https://your-site.example/page. The script prints the first matching og:image value and saves a full-page screenshot. If the site inserts metadata dynamically or serves different HTML to crawlers, compare the browser result with the live page source and the debugger’s fetched values.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. Make one request to capture a page, then compare the rendered result with the metadata you inspect separately. Its clean-shot flow accepts cookie or consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. AI agents can use its MCP server tools: take_screenshot, get_page_info, and capture_pdf.

cURL:

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

Python:

import requests

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

Node.js:

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

See the ScreenshotNeo API documentation for request options. Cookie banners, popups, and chat widgets are removed before the shot; bot checks, blank pages, and failed loads are never billed; an MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000. Create a free ScreenshotNeo account.

Performance, reliability, and cost considerations

• Keep the image practical to fetch. Wix reports an 8 MB maximum for Facebook-attributed guidance. A smaller image can also reduce transfer time, but do not trade away the dimensions or clarity needed for the preview. [Wix Help Center]
• Use a stable image URL. If you replace the file at a changing or reused URL, make sure the live page and refreshed scrape point to the intended current asset.
• Separate rendering from metadata debugging. Browser screenshots show page appearance; the page’s metadata and Facebook’s debugger show which image is associated with the shared URL.
• Expect context variation. Available research does not establish exact crops across placements or a fixed cache lifetime. Leave edge room and verify the actual preview you care about.
• Choose a workflow that fits volume. Local browser rendering requires maintaining a browser installation and capture script. ScreenshotNeo offers a one-request screenshot API; its published plans include 1,000 free shots monthly with no card, then $5 for 3,000, $15 for 15,000, $39 for 60,000, $99 for 250,000, and $249 for 1,000,000. Yearly billing gives two months free, and every feature is on every plan. [ScreenshotNeo]

Troubleshooting checklist

Symptom	Likely cause	What to check or change
The preview trims the sides or top	The image shape does not fit the preview layout, or important content sits near an edge.	Try a 1200 × 630 canvas and move essential content inward. Treat the ratio as a starting point, not a promise for every placement.
The preview shows a different image	The page’s og:image points to a different or default asset.	Inspect the live page’s head and confirm the exact image URL. Compare it with the debugger’s fetched image.
The old image remains after an update	Facebook may be showing previously scraped metadata.	Resubmit the shared page URL in the Sharing Debugger and inspect what it fetches. No fixed refresh duration is established by the available sources.
No image appears or the image fails to load	The crawler may not be able to retrieve the asset, or the URL may resolve to an error or non-image response.	Open the URL directly, check the served response and access requirements, then inspect the debugger result.
The preview looks small	The image may be below the recommended dimensions.	Use at least 600 × 315 as a practical lower target and prefer 1200 × 630. Wix reports these as guidance, not protocol rules.
A browser screenshot looks right but Facebook does not	A browser render does not establish what metadata Facebook fetched, and preview contexts may differ.	Check the page source and Sharing Debugger’s reported image before changing the design.

Frequently asked questions

Is 1200 × 630 required by Open Graph?

No. It is practical Facebook-oriented guidance reported by Wix. The Open Graph protocol defines og:image as the image associated with a page and does not set one mandatory pixel size. [Open Graph protocol; Wix Help Center]

Will a 1.91:1 image guarantee no cropping?

No. It is a recommended shape to reduce cropping issues. The available sources do not verify identical behavior across all Facebook preview contexts.

How long does Facebook keep an old preview?

The available sources do not establish a universal cache duration. Resubmit the page URL with the Sharing Debugger after publishing changes, then inspect the fetched information.

Does a screenshot prove Facebook can see my image?

No. A screenshot shows a browser render. Check the metadata and image Facebook reports in the Sharing Debugger to diagnose the social preview.