How to Test and Preview Your OG Image Before Publishing

#webdev #javascript #seo #html

You added an og:image tag, pushed your changes, shared the link, and the preview is wrong: the old image, a cropped logo, or nothing at all. The fix is to preview the card before you publish, not after. This guide covers the fastest ways to test an OG image, including the case the online tools cannot handle: a page running on localhost.

The short answer

Run your page URL through a free Open Graph checker. The three that fetch your live page and render the card the way each platform would:

opengraph.xyz scans any URL and previews the card across Facebook, X, LinkedIn, and more.
Open Graph Validator (Orca Scan) lists every tag it found and flags what is missing.
DebugBear's OG checker validates the tags and the image dimensions.

Paste your URL, read the rendered card, fix any tag it flags, redeploy. That covers a page that is already live. The harder cases are below.

Use the platform debuggers for the real result

The general checkers above are fast, but the platforms cache what they scrape, and that cache is what users actually see. To test against the real thing and to clear a stale preview, go to the source:

Facebook: Sharing Debugger. Shows exactly what the crawler sees and has a Scrape Again button to force a fresh fetch.
LinkedIn: Post Inspector. Re-fetches on every check, so it doubles as a cache buster.
X (Twitter): X reads og:image, but the large card only renders when twitter:card is set to summary_large_image. The simplest live test is to paste the URL into a draft post and look at the attached card before sending.

If you changed your image and the old one still appears, this is almost always a cache issue. Re-scrape through Facebook's debugger or LinkedIn's inspector and it clears within minutes.

How to test an OG image on localhost

This is the question the online tools cannot answer. A social debugger runs on the platform's servers, so it has no route to http://localhost:3000. You have two options.

Option 1: expose localhost with a tunnel. Run a tunnel like ngrok to get a public URL that points at your local server, then paste that URL into any of the checkers above. This gives you the real unfurl preview while your code is still local.

Option 2: capture the OG template directly. If your OG images are generated from an HTML template (the scalable pattern, where one /og route renders the title and branding), you do not need a social crawler to see the image. You need to see what the template renders at 1200 by 630. Point a screenshot API at the template URL and inspect the returned image:

curl https://api.grabbit.live/v1/grabs \
  -H "Authorization: Bearer sk_test_..." \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://your-tunnel.ngrok.app/og?title=My+Post+Title&category=Guides",
    "width": 1200,
    "height": 630,
    "format": "png"
  }'

The response returns a hosted image_url showing exactly what your template produces at the OG card size. You are checking the rendered pixels (Is the title cut off? Does the logo fit? Is the contrast readable?) rather than the social unfurl. Use a sk_test_ key while you iterate; test grabs return a deterministic placeholder and never cost a credit, so you can capture as often as you like while tuning the template.

A pre-publish checklist

Before you ship a page, confirm:

og:image points to an absolute URL (including https://), not a relative path. Crawlers do not resolve relative paths.
The image is at least 600 by 315, ideally 1200 by 630. Below the minimum, the card collapses to a thumbnail.
og:image:width and og:image:height are set so the platform reserves the right space.
twitter:card is set to summary_large_image if you want the large card on X.
The image URL is publicly reachable, with no auth wall or redirect in front of it. Some crawlers do not follow redirects.
Your meta tags are server-rendered, not injected by client JavaScript. Crawlers run little to no JS.

If all six pass and the debugger still shows the wrong image, force a re-scrape to clear the cache.

Why previewing matters more for dynamic images

A single hand-made OG image is easy to eyeball once. But the moment you generate images dynamically (one per blog post, one per product, one per user) you cannot manually check every output. That is exactly when previewing through a screenshot API pays off: the same call that generates the image is the call that lets you inspect it, so you can catch a clipped title or an overflowing string before any of them go live.

This is the workflow Grabbit's screenshot API is built for. Render your OG template, capture it at 1200 by 630, store the returned image_url, and drop it into your og:image tag. Start with a free test key to dial in the template, then switch to a live key for production captures.

Wrapping up

To preview an OG image before publishing: run the live URL through opengraph.xyz or a platform debugger, force a re-scrape if a stale image is cached, and for localhost either tunnel the page out or capture your OG template directly with a screenshot API. For the tags themselves see what an OG image is and why links break, and for the exact pixel sizes see Open Graph image sizes and dimensions. To automate the generation step, read how to generate dynamic OG images from any URL.

Originally published on the Grabbit blog.