Clear Browser Caches on Mac for QA Testing: A Reset Ladder
Clear Browser Caches on Mac for QA Testing: A Reset Ladder
Quick answer: To clear browser caches for QA on a Mac, climb from the lightest reset to the heaviest: hard reload, DevTools “Disable cache,” clearing site data (cookies, storage, service workers), then a throwaway browser profile. Deleting cache folders on disk only fixes stale files. It does not reset logins or app state.
You file a bug. The developer says “works on my machine.” You re-test, and now it works on yours too. Nothing changed except that your browser quietly served a fresh copy of a file it had been holding onto.
QA work on a Mac has a specific problem with caches: you need to know exactly which layer of stored state you’re testing against. “Clear the cache” is too blunt to say that. This guide breaks the browser’s stored state into layers and gives you the smallest reset that works for each one.
What is actually stuck? Match the symptom to the layer
Browsers hold several different kinds of state, and “the cache” is only one of them.
Symptom Likely layer Lightest fix Old CSS/JS after a deploy HTTP cache Hard reload Changes missing, but only in a normal window HTTP cache or service worker DevTools with cache disabled, then unregister the service worker You’re still logged in as the wrong user Cookies / storage Clear site data for that origin Feature flag or onboarding state won’t reset localStorage / IndexedDB Clear site data App works offline when it shouldn’t Service worker + Cache Storage Unregister the service worker, clear site data Bug can’t be reproduced on a colleague’s machine Accumulated profile state Fresh profile
Start at the top of the ladder and move down only if the problem persists. Every extra rung throws away more of the state you might need for reproduction.
Rung 1: Hard reload (seconds, no data lost)
A hard reload bypasses the cache for the current page load.
Chrome, Edge, Firefox: ??R Safari: ??R (“Reload From Origin”)
This fixes the most common “old build” complaint. It does not touch cookies, storage or service workers, and it only affects that load, so subresources fetched later can still come from cache.
Rung 2: Make DevTools bypass the cache while you test
If you’ll be reloading all afternoon, stop doing it manually.
Chrome/Edge: open DevTools ? Network tab ? tick Disable cache. It only applies while DevTools is open. Firefox: DevTools ? Network ? Disable HTTP Cache (when toolbox is open). Safari: enable the Develop menu first (Safari ? Settings ? Advanced ? “Show features for web developers,” wording varies by version), then use Develop ? Disable Caches.
Chrome also has a useful shortcut: with DevTools open, right-click the reload button and choose Empty Cache and Hard Reload.
One caveat that catches people: “Disable cache” does not unregister service workers. A service worker can still serve its own stored responses, so if rung 2 doesn’t fix it, go to rung 3.
Rung 3: Clear site data for one origin only
Clearing everything is rarely what you want. Scoping the reset to the site under test keeps your other sessions (and your sanity) intact.
Chrome/Edge: DevTools ? Application ? Storage ? Clear site data. Before you click, check what’s ticked: cookies, local and session storage, IndexedDB, Cache Storage, and service workers can each be included or excluded. The Service Workers panel also lets you unregister a worker directly and has an Update on reload option.
Firefox: Settings ? Privacy & Security ? Cookies and Site Data ? Manage Data, then remove the specific site. Alternatively use the Storage tab in DevTools.
Safari: Settings ? Privacy ? Manage Website Data, then search for the domain and remove it.
This is the right reset for “stuck as the wrong user,” stale feature flags and offline-mode bugs. It is also the rung where you should write down what you cleared, because “I cleared site data” and “I cleared only the HTTP cache” can produce different test results.
Rung 4: Use a throwaway profile (the reproducible reset)
When you need to prove a bug is not caused by your own accumulated state, don’t scrub the old profile. Start with a clean one.
Quick options:
A private/incognito window (no persisted state, but extensions are often disabled, which changes the test). A temporary Chrome profile from Terminal: ? bash open -na « Google Chrome » –args –user-data-dir=/tmp/qa-profile-01
Each new path gives you a fresh profile with no cookies, no cache, and no extensions. Delete the folder when you’re done, or keep it as a named baseline for a specific test plan.
This is the cleanest answer to “is it the app or is it my browser?” It’s also the best way to hand someone reproduction steps that start from a known state.
Where the cache lives on disk (and why you might clean it)
All of this works on state the browser manages for you. Separately, cache folders accumulate on disk, which matters if you run several browsers and test builds all day. Typical locations in your user Library folder:
Chrome: ~/Library/Caches/Google/Chrome/ Edge: ~/Library/Caches/Microsoft Edge/ Firefox: ~/Library/Caches/Firefox/Profiles/