How Cookie Tracking Works (and the Tracking Methods That Don't Need Cookies)

What a Cookie Is

An HTTP cookie is a small piece of text a website asks your browser to store. The next time you visit that site, the browser sends the cookie back. Cookies were originally designed to remember login state (so you don't have to log in on every page load) and to remember shopping cart contents.

The tracking use case is a side effect: if a site can store a unique identifier in your cookie and read it back, it has a way to recognise you across visits.

First-Party vs Third-Party

A first-party cookie is set by the site you're actually visiting (the URL in your address bar). These are usually benign — needed for login, language preferences, cart contents.

A third-party cookie is set by a different site whose content is embedded in the page you're viewing — an ad network's iframe, a social-media 'like' button, an analytics script. Third-party cookies are the engine of cross-site tracking. The same ad network's cookie set on news.com and shop.com lets them link your behaviour across both.

The Death (and Half-Life) of Third-Party Cookies

Safari blocked third-party cookies by default in 2020. Firefox blocked them in 2019. Chrome was supposed to block them in 2024 but delayed multiple times; as of late 2025, Chrome's plan is partial deprecation via Tracking Protection rather than a blanket block. The net effect: third-party cookies still exist in Chrome, mostly don't in Safari and Firefox.

But cross-site tracking didn't stop — the industry pivoted to other techniques.

Tracking Without Cookies

• Browser fingerprinting (see our dedicated article)
• First-party scripts — the tracking company gets the site to host their script as if it's first-party, so first-party cookies suffice
• CNAME cloaking — tracker hosts itself at a subdomain of the publisher (tracking.example.com is really a CNAME to tracker.com), bypassing third-party cookie blocks
• Local storage — HTML5 localStorage isn't cleared with cookies in most settings
• Indexed DB, Cache API, Service Workers — other browser-storage mechanisms that survive cookie clears
• Login wall + email-based identity — sites that require login link your activity to a stable identity (your email), making cookies unnecessary

Supercookies and Evercookies

Historically, sites used 'evercookies' — tracking identifiers stored in 10+ different browser locations simultaneously, so clearing one didn't break the link. Browsers have largely closed this off, but the spirit (redundant storage to survive user cleanup) persists.

Defences

• Block third-party cookies entirely (default in Safari/Firefox; settable in Chrome via Settings → Privacy and Security → Cookies)
• Use uBlock Origin to block third-party scripts at the network level
• Use Firefox containers (or similar in Edge) to isolate cookies per site / context
• Use Brave's Shields, which include strong default tracker blocking
• Periodically clear all site data, not just cookies (in Safari: Develop → Empty Caches and Develop → Disable Site-Specific Hacks)

The Bigger Picture

Cookie consent banners (the 'Accept All Cookies?' popups) give the impression you're in control. In practice, the consent flows are designed to make Accept easier than Reject, and even if you click Reject, fingerprinting and other cookieless tracking continues. Your best defence is browser-level blocking, not site-level consent.

Related Guides

See also: browser fingerprinting explained, what incognito mode actually does, and how ad targeting works.