Why does the old OG image still show after I replaced the file?

Every layer — browser, CDN and platform — caches by URL. Overwriting a file keeps the URL the same, so each cache keeps serving the old bytes. Publish under a new file name and update the tag.

How do I force Facebook to refresh a share image?

Open the URL in the Sharing Debugger and click Scrape Again. Purge your own CDN cache first, or the platform re-reads the old HTML and caches the old card a second time.

Does changing og:image:width and height force a refresh?

Not reliably. Those tags describe the file, and the image is still cached by its URL. Update them when the new image is a different size, but change the URL to actually bust the cache.

Why does the image update in one place and not another?

Each platform keeps its own cache and refreshes on its own schedule. Facebook, LinkedIn, Slack and Discord have to be refreshed separately; there is no global switch.

Should I add a query string to the image URL?

It works, because a different query string is a different URL. A content-hashed file name is cleaner, since it keeps every version at a stable, cacheable path instead of a growing pile of query strings.

Why is my OG image not updating?

You replaced og.png, deployed, shared the page, and the card is still the old image. That is almost never a bug in your tags. It is a cache — and there are several of them between your file and the person looking at the card.

The short checklist

What you changed	Why the card is stale	Fix
Overwrote the same file name	Everything cached by URL	Publish under a new content-hashed name
Changed only the meta tags	The platform cached the earlier scrape	Re-scrape after purging your CDN
Purged the CDN, not the platform	The platform still holds its own copy	Force a refresh in the platform debugger
Changed `og:image:width` / `height`	The image is still cached by URL	Change the URL as well
Deployed but the CDN still has the old PNG	Edge cache keyed by path	Purge the image URL, not just the page

Why overwriting a file does not work

Caches are keyed by URL. https://example.com/og.png is the same address whether the bytes behind it changed or not, so a CDN, a browser and a crawler all keep their copy and see no reason to refetch. A new file at the same path changes the content but not the identity.

The fix is to change the identity:

<!-- 覆盖同名文件：URL 不变，缓存继续命中旧图 -->
<meta property="og:image" content="https://example.com/og/launch.png">

<!-- 内容哈希：内容一变就是新 URL，天然绕过缓存 -->
<meta property="og:image" content="https://example.com/og/launch-a1b2c3d4.png">

A query string such as ?v=2 achieves the same thing. A hashed file name keeps each version at a stable, cacheable path, which is usually the better trade.

Force a refresh, per platform

Platform	Entry point	Note
Facebook / Messenger	Sharing Debugger, then Scrape Again	Also shows the tags it received
LinkedIn	Post Inspector	Re-fetches on demand
X (Twitter)	Card Validator	Intermittent; may require login
Slack	No public debugger	Post the link with a changed query string
Discord	No public debugger	Append a unique query string to bypass the embed cache
iMessage	No debugger	Send to a second device after the URL changes

Each platform owns its cache. Refreshing Facebook does nothing for LinkedIn.

Does changing og:image:width and height help?

Only partly. Those tags tell the crawler what aspect ratio to expect, so they should always match the real file:

<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">

If you swap in a differently sized image and leave the tags at the old values, the platform can render a wrong crop — a wide image squeezed into a square, or the reverse. That looks like “not updating” but is really “updating into the wrong shape”. Changing the numbers alone will not reliably bust the cache, because the image URL is unchanged. Change the URL and the tags together.

The order that works

Export the new image.
Give it a new, content-hashed file name.
Update og:image, og:image:width and og:image:height together.
Deploy.
Purge the CDN cache for both the image and the page.
Force a re-scrape on each platform you care about.

Confirm what the crawler is served before you re-scrape:

curl -sL --compressed -A "facebookexternalhit/1.1" https://example.com/page \
  | grep -iE 'og:image'

If that prints the new URL, the source is right and the remaining hold-out is a platform cache. If it prints the old URL, the problem is closer to home — a CDN or the app itself.

Common mistakes

Overwriting the file and expecting a change. The most common cause. Change the name.

Re-scraping before purging. The platform caches whatever your edge served. Purge first, then re-scrape, or you cache the old card a second time.

Refreshing one platform. Facebook’s cache is not LinkedIn’s cache. Refresh each one you send traffic to.

Changing the image size and not the tags. A mismatched width and height produces a bad crop, which reads as a stale or broken card.

Blaming the tags when the file 404s. A renamed file that the tag does not point at gives a text-only or broken card. Check that the URL returns 200.

Assuming a CDN purge covers everything. Purge the image URL, not just the page URL. They are different cache entries.

Where this tool fits

The OG image generator exports the card and the meta block with a fresh file name you can version however you like, so regenerating always produces a new URL. To see which image a platform is actually holding, run the page through the meta preview debugger.