Link Preview Showing the Wrong Image? How to Clear the Cache on Every Platform

You replaced the image. You checked the page source and the new og:image is right there. You paste the link into LinkedIn and up comes the old one — the one you specifically replaced because it was wrong.

This is not the same problem as a preview that does not appear at all. Your tags are working. The platform simply decided, some time ago, what your page looks like, and it has no intention of asking again.

Why platforms cache so aggressively

Every time someone shares a link, the platform has to fetch that page to build a preview. A popular link could be shared thousands of times an hour, and nobody wants thousands of requests hitting one page to produce the same card. So they fetch once, store the result against the URL, and serve the stored copy to everyone else.

That is sensible engineering and genuinely annoying when you are the one who changed the image. The cache is keyed on the URL, not on the content, so nothing about editing the page tells the platform that its copy is stale.

Cache lifetimes vary and none of them are documented as promises. Facebook’s is roughly a month unless you force a refresh. LinkedIn historically held previews for about a week. WhatsApp tends to follow whatever Facebook has. In practice: long enough to ruin a launch post.

Forcing a refresh, platform by platform

Facebook, Instagram and WhatsApp

These share infrastructure, so fixing Facebook usually fixes all three. Open Facebook’s Sharing Debugger, paste your URL, and press Scrape Again. The preview it shows afterwards is what everyone will now see. WhatsApp often trails by a few hours rather than updating instantly, so re-test rather than assuming it failed.

LinkedIn

LinkedIn has a Post Inspector that does the same job. Paste the URL and it re-fetches. LinkedIn is the platform people complain about most, partly because its cache was historically long and partly because it is where a stale preview is most embarrassing.

X (Twitter)

The old Card Validator no longer forces a refresh the way it used to. X generally picks up changes on its own within a day or so. If you need it immediately, the URL change below is the reliable route.

Slack and Discord

Both cache per workspace or server and neither gives you a refresh button. Slack sometimes updates if you unfurl the link again in a new message. For Discord, changing the URL is effectively the only option.

iMessage

Caches locally on the device, which is why a colleague sees the new image and you still see the old one. Nothing you do on the server fixes somebody else’s phone.

The reliable trick: change the URL

When a debugger will not cooperate, or the platform has no debugger at all, give it a URL it has never seen:

https://yoursite.com/page?v=2

The query string changes nothing about the page you serve, but as far as the cache is concerned it is a different address, so it fetches fresh. Share that version.

Two caveats worth knowing. First, keep the parameter simple and bump it (v=2, v=3) rather than inventing something new each time. Second, if your analytics splits traffic by full URL you will see the variants as separate pages. For a one-off launch post that is a fair trade.

The tags a card is actually built from

While you are in there, it is worth confirming the full set rather than only the image. A card is assembled from four tags, and a missing one makes the platform guess — usually badly.

<meta property="og:title" content="…">
<meta property="og:description" content="…">
<meta property="og:image" content="https://…">
<meta property="og:url" content="https://…">

When og:title is absent the platform falls back to your <title> tag, which often ends in a site name and looks clumsy in a card. When og:description is absent it takes your meta description, or the first text it finds on the page — which on a lot of sites is a cookie notice.

og:url is the one people leave out most and it matters more than it looks: it tells the platform which address this page canonically is, so shares of ?utm_source=newsletter versions consolidate onto one card rather than being cached separately. If you have ever refreshed a preview and seen the old one return when someone shared a tracked link, this is why.

X reads Open Graph tags as a fallback, so a correctly tagged page usually works there without Twitter-specific tags. Add <meta name="twitter:card" content="summary_large_image"> if you want the wide card rather than the small thumbnail — that single tag is the difference between the two layouts.

When it is not caching at all

Before you spend an afternoon clearing caches, rule out the possibility that the platform is ignoring your image on purpose. These are the reasons it does that, and the checker will show you each one.

The size one catches people most often. A 1200 × 630 image at a sensible file size works everywhere; square crops get awkward on LinkedIn, and anything much smaller gets demoted to a thumbnail beside the text instead of the full-width card you wanted. If your image is too heavy, the Image Compressor will get it under the limit without a visible quality drop, and the Image Resizer handles the dimensions.

Each platform crops your image differently

Sometimes the image is not wrong, it is just badly cropped — and people read that as the wrong image. One picture has to survive several different frames.

The practical approach is one 1200 × 630 image with the important content in the middle 60%. Anything near the edges — a logo in a corner, text running to the margin — is the first thing a tighter crop removes. If your card looks right on Facebook and wrong on WhatsApp, the image is almost certainly fine and the composition is the problem.

Our guide to social media image sizes covers the full set of dimensions if you are producing images for posts as well as link cards.

When the debugger shows the new image but the feed still shows the old one

This one causes real confusion, because it looks like the refresh silently failed.

It usually has not. A post that was already published keeps the preview it was created with — the card is attached to the post, not re-fetched each time someone scrolls past. Refreshing the cache changes what future shares will show, not what an existing post displays.

So if you have already posted the link, clearing the cache will not retrospectively fix that post. Delete it and post again, or accept it and make sure the next one is right. This is also the strongest argument for checking the preview before publishing rather than after: a stale cache is fixable in thirty seconds, but a live post with the wrong image on it is not.

The other possibility is simpler. Some platforms serve cached cards from regional infrastructure, so an update can appear in one place and not another for a few hours. If the debugger is showing the correct image, the server side of this is done.

Getting it right before you publish

The whole problem is avoidable by checking before the link goes out rather than after. A short habit that works:

1. Set the image before the page goes live, not after you have shared it. The first fetch is the one that sticks.
2. Check the rendered page, not your template. Plenty of CMS themes add their own og:image, so what you wrote and what ships are not always the same thing.
3. Run the URL through a checker to confirm the tags resolve and the image loads.
4. Then share it. If you must change the image afterwards, refresh the cache immediately rather than hoping.

A note on changed titles and descriptions

Everything above applies to og:title and og:description too, and those go stale just as often. A page that has been rewritten can still be shared with its original headline from six months ago, which looks worse than a wrong image because people read it. Same caches, same fixes.

If the preview is not appearing at all rather than showing the wrong thing, that is a different problem with different causes — missing tags, a blocked crawler, or a redirect chain. We covered that in why your WhatsApp link preview is not showing.

Quick checklist

• Does the page actually serve the new og:image? Check the rendered source, not the template.
• Is the image URL absolute, public, and served over HTTPS?
• Is it at least 600 pixels wide, ideally 1200 × 630, and under about 300 KB?
• Is there exactly one og:image tag?
• Have you forced a refresh in each platform’s debugger?
• Still stuck? Share ?v=2 and move on.