What you are actually clearing
Modern browsers mix several stores: HTTP cache (disk/memory keyed by URL + validators), cookies and local/session storage, IndexedDB, service worker caches and scripts, prefetch hints, and sometimes DNS-over-HTTPS inside the browser. “Clear cache” UI options differ by vendor—narrow the scope so you do not wipe passwords or MFA state unnecessarily.
HTTP caching mechanics
Responses honor Cache-Control (max-age, no-store, private), ETag, and Last-Modified. A hard reload asks the browser to revalidate or bypass cache for that navigation, but service workers can still intercept fetch and serve their own cache. Use DevTools Disable cache (while DevTools is open) to reproduce what developers see on first load.
| Goal | Typical approach | Tradeoff |
|---|---|---|
| Force fresh HTML/CSS/JS | Hard reload + DevTools disable cache | Still obeys no-store; SW may override |
| Fix stale SPA after deploy | Unregister SW / clear storage for origin | May log users out if cookies cleared |
| Rule out CDN | curl -I to origin vs edge with Host/SNI | Different from in-browser DoH path |
HSTS and “stuck” HTTPS
If a site sent Strict-Transport-Security with a long max-age, the browser will refuse plain HTTP for that host—clearing cache does not remove HSTS pins quickly. That is separate from asset freshness.
After local clearing
If only one machine shows old assets, browser cache was likely. If every device does, purge CDN or fix origin Cache-Control. OS resolver cache is covered in Flush DNS cache.
Related: Clear Cloudflare cache, X-Forwarded-For explained (edge vs origin debugging), How DNS works.