How to test your OG image before you share it

The worst place to discover your share image is broken is in the post itself, after it is live, in front of the audience you wrote it for. By then the card is cached, the link is out, and the fix arrives a day late. Testing an Open Graph image before you share it takes about a minute, and it catches the handful of failures that account for nearly every broken card.

This is a checklist you can run on any URL before it goes out. It covers the free validators each platform publishes, what to look for when a card renders wrong, and the order to check things so you find the cause on the first pass instead of the fifth.

Why previewing in a real post is not testing

Pasting your link into a draft post feels like a test, but it is the one thing you should not do. The moment a platform sees the URL it fetches the card and caches it. If the card was broken at that moment, you have now taught the platform to keep serving the broken version, and clearing that is a separate job. The validators below exist precisely so you can check a card without minting a cache entry you will regret.

The validators, one per platform

Each major platform publishes a free tool that fetches your page, shows the card it built, and lists the tags it read. Run the ones that matter for where your link is going.

• Facebook Sharing Debugger. The most useful of the set, because it shows every tag it parsed and the exact card it will render. It also has a "Scrape Again" button, which is the official way to make Facebook drop its cached copy and read your page fresh.
• X (Twitter) Card Validator. Confirms the card type and image X will use. If the banner is coming out as a small square, this is where you see it before your followers do. The Twitter Card and Open Graph guide covers the one tag that causes that particular bug.
• LinkedIn Post Inspector. LinkedIn caches hard and for a long time, so checking here before you post to a professional audience is worth the extra step.
• A generic Open Graph checker. Handy for Slack, Discord and iMessage, which do not publish their own tools but all read the same og: tags a generic validator reports.

You do not need all four every time. Check the platform you are posting to, plus the Facebook debugger, since its tag dump tells you what every other reader sees.

Read the tags, not just the picture

A validator shows two things: a rendered card, and the list of tags it read. The rendered card tells you something is wrong. The tag list tells you why. Always read the list.

The tag dump is where you catch a og:title that is empty, a description that got truncated, or, most often, an og:image pointing at a path instead of a full address. A card that renders blank almost always has a tag list that explains it in one line.

The five things that are actually broken

Nearly every broken card is one of these, and you can check them in order. The first one that is true is almost always the cause.

1. The image URL is relative. og:image needs a full https:// address. A path like /og.png resolves to nothing for a crawler that is not on your site. This is the single most common failure.
2. twitter:card is missing. On X, without summary_large_image your wide banner renders as a tiny square. It is the one Twitter tag with no Open Graph fallback.
3. The image is behind auth or a redirect. If the crawler cannot fetch the file without a login or a bounce through another URL, it gives up and shows nothing.
4. The tags are injected by client-side JavaScript. Many crawlers read the raw HTML and never run your scripts, so a tag added after load is a tag they never see. The tags must be in the server response.
5. The card is cached from an earlier, broken version. The tags are right now, but the platform is still serving yesterday's copy. This is a cache problem, not a markup one, and the fix is its own topic.

Run down that list and you will find the cause of most cards without guessing.

See the page the way a crawler does

The validators are the easy path, but they hide one thing that matters: whether the tags are in the HTML the server sends, or added later by JavaScript in the browser. A crawler reads the raw response and, for the most part, never runs your scripts. So the truest test is to fetch the page the way a crawler would and read the head yourself.

# Fetch the raw HTML and pull out the og: and twitter: tags
curl -sL https://example.com/page | grep -iE 'og:|twitter:'

If your tags appear in that output, every crawler sees them. If they do not appear here but do show up in your browser's inspector, they are being injected client-side, and that is failure number four from the list above: the tag exists for a human and not for the machine. The fix is to render the tags on the server, in the first response, not after load.

When the tags are right but the card is old

If every tag validates and the card still shows the old picture, you are looking at a cache, not a bug. Each platform holds your card for its own window, and the windows differ enough to be worth knowing before you panic.

The manual re-scrape buttons work per platform, but the fix that beats every cache at once is to change the image URL so there is nothing old left to serve. That method, and the full detail on each window above, is covered in why your OG image is not updating.

A one-minute routine before every share

Put the checks together and the whole thing fits in a minute:

1. Run the page through the Facebook Sharing Debugger and read the tag list, not just the card.
2. Confirm og:image is an absolute https:// URL and the image loads when you open it in a plain browser tab.
3. If the link is going to X, check twitter:card is summary_large_image.
4. Fix anything wrong, then use each tool's re-scrape button so no platform keeps a broken copy.

Do that before the link goes out and the card is right the first time it is seen. For getting the image made in the first place, generating one straight from a URL skips the design tool entirely, and the size guide has the one number the picture needs to be.