Clearing cookies stops part of the tracking aimed at you and leaves the rest untouched. The part it stops is larger than most articles on this question admit, and the part it cannot reach is more specific. Both halves are documented by the browser makers themselves, so neither needs to be guessed at.
The common claim is that clearing cookies is useless because local storage and similar mechanisms survive it. Google's own support documentation says the opposite: clearing cookies and site data in Chrome deletes Web Storage, Web SQL and Indexed Database data too. The storage layer does go. What survives is the material that was never stored in your browser at all.
That distinction decides what a cookie clear is worth to you, and articles on this question routinely get it backwards. This guide sets out what each checkbox removes and what remains afterwards. It also covers why deleted cookies appear to come back, and what a study of more than 150,000 people measured about re-identification after a reset.
Quick Answer: Does Clearing Cookies Stop Tracking?
Correction and Retarget, 28 September 2026
What Clearing Cookies Actually Deletes
Start with the checkbox, because the checkbox is where the confusion begins. In Chrome the control is not called "cookies". It is called "Cookies and other site data", and the second half of that label is carrying most of the weight.
Google's own documentation on deleting browsing data spells out what goes with it. Clearing that item deletes, in its words, "HTML5-enabled storage types including application caches, Web Storage data, Web SQL Database data, and Indexed Database data". Web Storage is the specification that provides localStorage. Indexed Database is IndexedDB.
This matters because it contradicts the most repeated claim on this topic. Articles ranking for this question state that localStorage and IndexedDB are not affected by clearing cookies, and then build their case for futility on top of that. The browser vendor's own documentation says those stores are deleted along with the cookies.
The practical consequence is that the tidy mental model of "cookies are shallow, real tracking hides deeper in storage" is out of date for anyone using the standard control. A tracker that moved its identifier from a cookie into localStorage to survive cookie deletion did not survive it. Both live in the same deletion scope.
Two phrases get used as synonyms here and the browsers do not treat them as one. Deleting cookies removes identifiers already sitting on your machine. Blocking third-party cookies stops a whole class of them arriving, and in Chrome that is a different screen under Privacy and security. The first is cleanup and the second is prevention, which is why doing only the first leaves you repeating it every week.
What that clear does to you is also documented, and it is the reason people hesitate. Chrome's page puts it directly: "If you delete cookies, you may get signed out of sites that remember you. Your saved preferences can also be deleted." That is the cost, and it is the whole cost.
Saved passwords are a separate checkbox and are not touched by clearing cookies. Neither is browsing history, which is its own item. The three are routinely confused because the dialog presents them together, and that confusion is why the second most common version of this question is whether clearing cookies deletes passwords. It does not.
What Survives It, and Why
If the storage layer goes, what is left? Four things, and they share one property: none of them is a file sitting in your browser waiting to be deleted. That is the boundary, and it explains every case of being recognized after a clear.
The first is your device fingerprint. Your GPU's rendering of a canvas, your installed fonts, screen dimensions, CPU core count and reported memory are values your browser calculates or reports on request. They are not stored, so there is nothing to erase, which is why the CPU, memory and graphics values your browser hands out read identically before and after.
The name for that category is your browser fingerprint, and it defeats deletion for a structural reason rather than a clever one. A fingerprint is not a file a site wrote to your disk. It is a description of your machine that your machine recomposes every time it is asked, so deleting is simply the wrong verb for it.
The second is your IP address. That comes from your network, not your browser, and no browser setting changes it. The third is your account: the moment you log back in, you have volunteered a permanent identifier that no amount of local deletion affects.
The fourth is everything already sitting on someone else's servers. A profile built against an identifier does not vanish because your copy of that identifier did, and if the company can tie your new session to the old profile by any route, the history is still attached. This is the half that sits outside your reach entirely, and the same limit applies to the leak that reveals your real address from inside the browser regardless of what you have cleared.
Of the four, the account deserves singling out, because it is the one readers discount. A logged-in identity is a permanent identifier you re-supply voluntarily, and it overrides every technical measure on this page. Clearing cookies and then signing straight back in is a complete round trip to where you started.
The address itself is worth understanding separately, since it travels with every request whatever your browser has deleted. What a site can determine from it alone is a longer subject, covered in how much a website reads from the connection itself.
| Identifier | Deleted by a cookies and site data clear? | Why |
|---|---|---|
| First-party and third-party cookies | Yes | Stored files in the browser profile, removed directly |
| localStorage and sessionStorage | Yes | Chrome names Web Storage data in the deletion scope for this item |
| IndexedDB and Web SQL | Yes | Named in the same Chrome documentation, contrary to most guides |
| HTTP cache, including ETag identifiers | Only if you also tick cached files | A separate checkbox from cookies and site data |
| Canvas, WebGL, font and hardware fingerprint | No | Calculated on request, never stored, so nothing exists to delete |
| IP address | No | Assigned by your network, outside the browser entirely |
| Your logged-in account | No | You supply it again at the next sign-in |
| Server-side profile already built about you | No | Held on someone else's systems, unaffected by local deletion |
Read down the "No" rows and you have the honest answer to the question. Everything a cookie clear cannot touch is either a property of your machine, a property of your network, or a record you do not hold.
The Measured Answer to "Why Do They Still Know Me?"
Every article on this subject asserts that you remain identifiable after a reset. Of the six pages ranking for this question that I could read in full, not one cites a peer-reviewed measurement of how identifiable. There is one, and it fits this question unusually well.
Kristin Crichton, Lorrie Cranor and Nicolas Christin published a study of behavior-based tracking at scale in Proceedings on Privacy Enhancing Technologies, volume 2025, issue 4. Its dataset covers, in the paper's words, "over 150,000 users across two years". That scale is what makes the next sentence worth quoting.
The paper's finding on resets reads: "An adversary can eliminate 84-95% of a user's anonymity having observed just a single session pre- and post-discontinuity." A discontinuity is the reset. One session either side of it is enough to reconnect most of what the reset was supposed to break.
The signal doing that work is worth stating precisely, because it is not what readers expect. The behavioral fingerprint in this study is which sites a person visits, not typing rhythm or mouse movement. The paper describes these patterns as "consistent, evolving slowly over the course of months to years", which is why a fresh profile looks like the same person within minutes.
Two limits on that figure deserve stating, because the paper states them. It measures anonymity within its own dataset rather than identification by name. And the sites-visited signal it relies on is available to a party observing browsing across many sites, not to a single shop watching its own visitors.
So read the number as a description of what a broad observer can do after your reset, which is the situation advertising networks and analytics platforms are actually in. One website recognizing you when you return is a much easier problem than that, and usually needs nothing more than your login.
This is the correction referred to in the notice above. An earlier version of this page attached a re-identification accuracy range to models trained on typing and mouse behavior across devices. The published work I could verify measures keystroke identification among 148 people in a laboratory, which is a different and much narrower claim, so the broader one has been removed.
Why Deleted Cookies Come Back
Search the support forums and one complaint outnumbers every other on this subject: the cookies were deleted and they returned. Mozilla's forum, Microsoft's Q&A and Apple's community all carry years of these threads, and they are mostly answered with speculation about malware. There are four mundane explanations, and between them they cover almost every case.
The first is that the site is still open. A tab left loaded re-sets its cookies the instant it makes another request, which can be seconds after the deletion. Nothing has respawned; the page simply did again what it did the first time.
The second is browser sync, and Microsoft documents this behavior in reverse. Its Edge guidance notes that "Remember that clearing data in Microsoft Edge deletes it on any of your synced devices", which is the same channel by which a signed-in profile can reintroduce state you cleared on one machine.
The third is that a cookie you deleted individually is simply reissued on your next visit, since deletion is not a refusal. The fourth is the genuinely adversarial case, where an identifier was copied into another store and written back afterwards. That last one is the technique everybody reaches for first, and it is the least common of the four.
A related complaint belongs here because it has the same shape. People open an incognito or private window expecting a clean identity and find the site recognizing them anyway. Private browsing does discard cookies and site data when the last private tab closes, which is real, but it changes none of the four survivors listed above.
The useful consequence is that "they came back" is rarely evidence of anything sophisticated. Close the tabs, clear, then check before browsing again, and the mystery usually resolves itself.
The Cache Is the Box Most People Never Tick
There is one real gap in a cookies-only clear, and it sits in a separate checkbox. The browser cache can carry an identifier, because a server may hand each visitor a distinct validator for a cached file and read it back on the next request. The technique is old and has an accurate nickname: cookieless cookies.
One forum exchange from 2013 illustrates the experience of it better than any explanation. A poster testing a demonstration of the method wrote, of a site that kept recognizing him, "if I clear my cookies, it still recognizes me". Another reported having cookies and cache cleared on browser exit and finding his stored text intact regardless.
The modern picture is better than that thread suggests, and the improvement is documented. Google's Privacy Sandbox status page lists Storage and Network State Partitioning under "Continue to support", meaning cached resources are keyed by the top-level site rather than shared across every site that loads them. Partitioning does not delete the identifier, it stops one site reading another's.
The practical instruction is short. Tick cached images and files alongside cookies and site data, because the two together cover the browser-held layer and cookies alone do not.
This also answers the neighboring question of whether clearing the cache deletes your cookies. It does not, and the reverse holds equally: they are separate checkboxes over separate stores. Microsoft states the distinction plainly in its Edge guidance, that cookies save your preferences and behaviors while the cache saves information about the web pages themselves.
Which means the advice to "clear cache and cookies", the phrase support desks actually use, happens to be better advice than clearing cookies alone. It covers both stores. The people repeating it for unrelated reasons have been giving the more complete instruction by accident.
The Exact Steps, By Browser
None of the six ranking pages I could read in full gives a click path. That is a strange omission for a question about whether an action works, so here are the paths, each taken from that vendor's own current documentation.
| Browser | Path | Worth knowing |
|---|---|---|
| Chrome, desktop | More, then Delete browsing data. Choose a time range, select Cookies and other site data, then Delete data | Also tick cached images and files. Block third-party cookies separately under Privacy and security |
| Firefox | Clear browsing data and cookies, with both cookies and site data and temporary cached files selected | Manage Cookies and Site Data lets you remove single sites and keep the rest signed in |
| Safari on iPhone | Settings, Apps, Safari, Advanced, Website Data, Remove All Website Data, Remove Now | This route keeps your history. Clear History and Website Data removes both at once |
| Microsoft Edge | Settings, Privacy, Clear browsing data, or type edge://settings/clearbrowserdata | Edge's own documentation warns the clear propagates to every synced device |
| Brave | Same Chromium path as Chrome, under Privacy and security | Shields already block cross-site cookie tracking by default, so routine clearing achieves less here |
Two habits are worth more than the frequency debate. Close the tabs first, and select a time range of all time rather than the last hour, because a partial range leaves the oldest identifiers exactly where they were.
Two refinements come up constantly in support threads and both are worth knowing. Firefox and Chrome will each remove data for a single site while leaving everything else signed in, which answers the complaint that clearing costs you every login at once. And if the goal is not to keep repeating it, set the browser to clear cookies when it closes rather than relying on a schedule you will forget.
What Changed in 2026, and Why Nobody Ranking Mentions It
The background to this question shifted substantially over the past year, and every page currently ranking for it predates or ignores the change. Anyone still repeating that third-party cookies are about to disappear from Chrome is working from a plan that was abandoned.
Google's own status page for the Privacy Sandbox technologies, last updated 14 August 2026, sorts each one into four buckets: "Continue to support", "Deprecate and remove", "Discontinue" and "Do not launch". The list under the second bucket is the story.
Read together, the buckets say something plain. The advertising replacements for cookies are being withdrawn and third-party cookies remain a user choice in Chrome's settings. The two features that would have reduced fingerprinting are the ones that were canceled. The layer a cookie clear cannot reach is the layer receiving the least protection.
| Bucket, as Google labels it | Examples named on the page | What it means for this question |
|---|---|---|
| Continue to support | Storage and Network State Partitioning, CHIPS, Bounce tracking mitigations, User-Agent reduction | The protections that survived are the quiet structural ones, and they help |
| Deprecate and remove | Topics, Protected Audience, Attribution Reporting, Shared Storage | The cookie replacements for advertising are being withdrawn, not shipped |
| Discontinue | IP Protection, Partitioned Popins | The feature that would have masked the identifier you cannot clear is gone |
| Do not launch | Script Blocking, Private Proofs, Probabilistic Reveal Tokens | Blocking known fingerprinting scripts was considered and shelved |
One more current fact belongs here, because it contradicts advice that is still widely repeated. Mozilla's own support page on resist fingerprinting, last revised in September 2026, states "we do not recommend this feature for the average Firefox user", and steers people to Fingerprinting Protection in the standard settings instead.
For a reader the practical reading is narrower than the industry coverage suggests. Cookies are not leaving Chrome, so the deletion described on this page keeps working exactly as described. What changed is that the machinery built to replace cookies is being dismantled rather than launched, and the protections aimed at the layer you cannot clear were the ones dropped.
What to Do, By Situation
My position, stated plainly
If a support agent told you to clear cache and cookies to fix a broken page, that is unrelated to tracking and worth doing. It fixes stale files, it will sign you out, and it will not delete your saved passwords. Those are the only consequences.
And if you clear on a schedule out of habit, consider whether you are buying anything. Clearing weekly does not compound: what it removes is removed, and what it cannot reach is unaffected by doing it more often.
The Answer, Stated Once
Clearing cookies stops one category of tracking completely and leaves three untouched. The boundary is whether the identifier was ever stored in your browser. Cookies, local storage and IndexedDB were, so they go. Your fingerprint, your address and your account were not.
The 150,000-user study supplies the scale of what remains: most of the anonymity a reset buys can be stripped back from one session either side of it. That is not an argument against clearing. It is an argument against treating a clear as a fresh identity, the mistake the "useless" framing and the "clear it weekly" habit make from opposite directions.
Judged against what it claims to do, clearing cookies works. Judged against becoming a different person online, no browser menu was ever going to deliver that. If the address is what concerns you, the options for changing it without paying for one are a separate decision from anything here.
Two neighboring questions finish the picture. Why a private window is not a new identity covers the mode most people reach for next, and removing the records that sit outside your browser entirely deals with the half no checkbox reaches.