When a corrected image looks unchanged in production, check which file the browser received before uploading it again. The editor, CDN, and browser can each show a different stage of an update.
A Three-Step Cache Investigation
Identify the Requested URL
Inspect the network response and the actual image source. Responsive variants may have their own addresses. A new original does not necessarily regenerate every thumbnail or invalidate a cached response.
Separate Content Editing From Delivery
A make background white edit changes the asset’s pixels. It does not tell your delivery system that those pixels have changed. Compare the exported source with the response served to a fresh browser session.
The MDN HTTP caching guide explains validators, cache lifetimes, and versioned resources. Choose a strategy that matches your deployment rather than repeatedly renaming files without a policy.
Test the Next Deployment Too
Content-hashed URLs can make changed assets distinguishable, while stable URLs require a considered revalidation or invalidation approach. Check how your image service transforms and caches each size.
Record the source version and the deployed URL in the release notes. Verify an uncached load, then a repeat visit. If the page still references an old variant, repair that reference rather than treating every stale image as a browser problem.
If a colleague sees a different version, compare the requested URLs and response headers together. Screenshots alone cannot establish which cache supplied the file. Keep the reproduction steps short enough that someone else can repeat the check.
