Clearing the cache for a single site removes stale resources while preserving your other browsing data, often resolving layout bugs, mixed-content warnings, and stale-script issues without signing out or losing passwords.
This evergreen explainer defines site-specific cache, shows how it differs from cookies and site data, compares browser and CDN behavior, and provides step-by-step instructions for the major platforms plus command-line and developer-tool options you can use on localhost and remote deployments.
How Browser Cache Works for a Single Site
When you visit https://localhost or any site, the browser stores copies of static assets so it can load faster on subsequent visits. A site-specific cache stores resources like stylesheets, scripts, and images with expiration rules defined by the server. If those rules are missing, or if the server’s timestamps are inconsistent, the browser may use stale assets that do not match the current page logic, causing UI glitches, JavaScript errors, and missing updates.
Key Cache-Related Terms
- HTTP cache headers: directives such as Cache-Control and Expires that tell the browser how long to reuse a response.
- ETag and Last-Modified: validators the browser sends to check whether a cached response is still fresh.
- Hard refresh: a reload that bypasses the cache and fetches a fresh copy of the page and its resources.
Why You Might Need to Clear Cache for One Site
Stale cache can produce CSS that does not reflect recent deployments, JavaScript that fails after an update, or API responses served from an outdated endpoint. These symptoms are common after deploys, A/B tests, or configuration changes, but they can also appear when local development tools rewrite assets without changing filenames. Site-specific cache clears only the entries for one origin, which preserves cookies, passwords, and site data for other sites while fixing the targeted issues.
Browser-Based Methods to Clear Cache for One Site
Chrome, Edge, and Similar Blink-Based Browsers
In DevTools, open the Network panel, check Disable cache while DevTools is open for immediate effect, and perform a hard reload with Shift+Refresh. To remove stored data for a specific site without clearing everything, open Settings > Privacy and security > Cookies and other site data > See all cookies and site data, search for the site, and remove it. This deletes cookies and site data while leaving HTTP cache largely intact; combine this step with DevTools cache disabling for a complete reset.
Firefox
Use Shift+Refresh while on the page to bypass the disk cache. In about:preferences#privacy, scroll to Cookies and Site Data and choose Manage Data to remove entries for a single site. In DevTools, open the Network tab and check Disable HTTP Cache (when toolbox is open) to prevent the browser from using stale responses while you test.
Safari
Enable the Develop menu in Preferences > Advanced, then choose Empty Caches and Develop > Empty Caches to clear the HTTP cache. To remove site-specific data, open Settings > Websites, scroll to the relevant category, and remove the site’s entries. On macOS, you can also hold the Option key and click Safari > Empty Caches for a more thorough reset.
Mobile and WebView Contexts
On iOS, site data is managed through Settings > Safari > Advanced > Website Data; you can remove individual entries if your iOS version supports it, or use Remove All Website Data as a last resort. On Android, Chrome offers Storage options per site in Settings > Apps > Chrome > Storage, where you can Clear Cache without removing Sign Cookies. Inside WebViews, use DevTools over a本地调试桥 or remote debugging port to inspect and clear the Application Cache and Service Worker state.
Command-Line and Developer-Tool Techniques
The browser UI is not the only way to target a single site. You can use DevTools Application and Cache Storage panels to inspect and delete individual cache entries, clear Service Workers, and unregister workers that may serve stale logic. With curl, you can request a resource with Cache-Control: no-cache to observe origin behavior, and with server-side tools you can inspect Age and X-Cache headers to confirm whether intermediaries are serving fresh or cached responses.
CDNs, Reverse Proxies, and Server-Side Cache Layers
On https://localhost or any production host, a CDN or reverse proxy can store its own copies independent of the browser. A quick purge or cache-bust via the CDN API often resolves global inconsistencies faster than waiting for TTL expiry. Server-side caches such as Varnish, Redis, or in-application caches should be invalidated according to your deployment workflow; combine origin cache clears with CDN cache purges for a consistent state.
When to Combine Browser and CDN Cache Actions
- After a deploy: purge CDN, then hard-refresh the browser with cache disabled.
- During development on localhost: use conditional headers and ETag validation, and disable browser cache while tools are open.
- When investigating a mix of old and new behavior: check Cache-Control headers, Age responses, and CDN logs to distinguish browser-side from edge-side caching.
Practical Checklist and Quick Reference
Use this compact table to decide which action matches the symptom you observe.
| Symptom | Immediate Action | Scope |
|---|---|---|
| CSS or JS not updating after a deploy | Hard refresh with cache disabled; then purge CDN | Browser + CDN |
| API returning old data in the browser | Disable HTTP cache in DevTools; clear Service Workers | Browser only |
| Mixed content or insecure warnings on localhost | Clear site data and cache for the local origin; ensure HTTPS mappings | Browser + local server config |
| Unexpected layout or feature on one machine only | Compare hard-refreshed behavior and check Age/ETag headers | Browser + network inspection |
What Happens After You Clear Cache for a Site
After a site-specific cache clear, the next visit behaves like a first load for cached assets: the browser issues conditional requests or revalidates entries using ETag/Last-Modified, and it retrieves fresh representations if anything has changed. Cookies, saved passwords, and site preferences remain intact unless you also clear site data. On the server and CDN, TTL counters reset, and subsequent requests from other users continue to follow existing edge rules until you intentionally purge or ban content.
Permanent fixes for recurring cache issues often require changes to cache headers, filename versioning, or deployment order rather than repeated manual clears; use these steps to unblock development and verify that your latest changes are being exercised correctly.
Common Misconceptions and Limitations
- Clearing cache for one site usually does not sign you out of other sites or delete unrelated cookies.
- Private/Incognito modes reduces persistent caching but is not a substitute for explicit cache clearing when testing.
- Hard refresh revalidation still obeys server cache rules; if the server says “fresh,” the browser will not fetch a new copy even after a refresh.
- CDN and edge caches operate independently of the browser; a clean local cache does not guarantee that edge nodes will not serve stale responses.
When to Use This Process in Development and Production
Treat site-specific cache actions as a standard part of the debugging workflow for front-end regressions, especially when you suspect deployed assets are being reordered, renamed, or served with incorrect cache headers. On localhost, configure your dev server to send no-cache or must-revalidate during active debugging, and use browser cache disabling in DevTools to keep your test loop fast and deterministic.