Cookies, Fingerprints and IP Addresses: Who Holds Each One

Clearing your cookies is a real privacy action with a narrow reach. It removes something a website handed you to keep. It does nothing to the other two things that recognise you, and the reason is not that they are cleverer. It is that neither one was ever in your hands.

A cookie is something a site gives you to hold

RFC 6265, published on the IETF standards track in April 2011, sets out the mechanism in one sentence of its introduction: “Using the Set-Cookie header field, an HTTP server can pass name/value pairs and associated metadata (called cookies) to a user agent.” Its overview is blunter still: “To store state, the origin server includes a Set-Cookie header in an HTTP response. In subsequent requests, the user agent returns a Cookie request header to the origin server.”

Read that as a transfer of custody rather than as a tracking technique. The server composes the value. Your browser files it. Your browser then presents it again, unprompted, on every later request that matches. At no point does the site reach across and take it back. The whole arrangement runs on your software volunteering something.

That custody is why your browser ships with a cookie manager at all. There is a list it can show you, because the list is on your machine. The specification lists what gets written down for each one: “The user agent stores the following fields about each cookie: name, value, expiry-time, domain, path, creation-time, last-access-time, persistent-flag, host-only-flag, secure-only-flag, and http-only-flag.” Eleven fields, sitting in storage you control.

The specification also expects you to interfere with it. Its note on expiry dates says the browser “might delete the cookie before the expiration date if the user agent’s cookie store exceeds its quota or if the user manually deletes the server’s cookie.” Deleting a cookie is not a trick played on a website. It is behaviour the standard wrote down in advance.

Two attributes decide how far a cookie travels

A cookie does not travel everywhere, and two attributes fix where it goes. The site chooses both.

Domain decides which hosts receive it. In the specification’s words, “the Domain attribute specifies those hosts to which the cookie will be sent.” Leave the attribute out and the reach narrows, because “if the server omits the Domain attribute, the user agent will return the cookie only to the origin server.”

Path decides which parts of a site receive it. “The scope of each cookie is limited to a set of paths, controlled by the Path attribute.” The specification then warns against overreading that, noting that “although seemingly useful for isolating cookies between different paths within a given host, the Path attribute cannot be relied upon for security.”

Your browser gets a vote of its own. The storage rules open by granting it one, saying a user agent may ignore a received cookie in its entirety, and the example offered is refusing cookies that arrive in third-party responses. Which of those refusals your browser actually makes is a settings question, and the answer can change again when you open a private session.

A fingerprint is worked out about you, not handed to you

Nothing arrives. Nothing is filed on your side. A script reads values your browser answers with anyway, derives an identifier from the combination, and keeps that identifier at its own end.

The W3C’s Privacy Working Group published a group note in March 2025, Mitigating Browser Fingerprinting in Web Specifications, which defines the practice as “the capability of a site to identify or re-identify a visiting user, user agent or device via configuration settings or other observable characteristics.” The group describes that document as work in progress and says it is not endorsed by W3C itself, so read it as the working group’s position rather than as a standard.

It draws the comparison this article is about, and it draws it against cookies by name: “In contrast to other mechanisms defined by Web standards for maintaining state (e.g. cookies), browser fingerprinting allows for collection of data about user activity without clear indications that such collection is happening.”

The consequence follows from the custody rather than from the cleverness. There is no fingerprint manager in your browser because there is no fingerprint on your machine to manage. The note states the result plainly: “Browser fingerprinting also allows for tracking of activity without clear or effective user controls: a browser fingerprint typically cannot be cleared or re-set.”

Scope diverges as well. A cookie’s reach is fixed by attributes the server sets. A fingerprint has no attribute to set, and the note spells out what that costs, saying different sites may be able to combine information about a single user “even where a cookie policy would block accessing of cookies between origins, because the fingerprint is relatively unique and the same for all origins.” Which values get read, and why refusing them breaks ordinary page features, is a subject of its own, covered in the signals a fingerprinting script actually reads.

Your address was issued to the connection

The third identifier is neither stored by you nor derived by anyone. It is allocated, by a network, to a connection. It is also the one that arrives whether or not anything asks for it, because a reply has to be addressed somewhere.

What it picks out is a network rather than a person, and our own IP lookup puts that limit in its own copy: “IP lookup data is not a person lookup. It usually identifies the organisation that controls the network.” Location from an address is an estimate drawn from databases and routing records. A network exchange, a datacentre, a region or a city are all listed on that same page as possible answers, which is a wide enough spread to be worth holding in mind.

The three answer different questions, which is the cleanest way to hold them apart. An address describes the network path a request arrived on. A cookie describes a previous visit to one site. A fingerprint describes a device, across any site that bothers to look.

Clearing one leaves the other two where they were

This is where the custody argument earns its keep, and it is not a rhetorical flourish. The W3C note says it directly, naming two remedies in the same breath: “tools such as clearing cookies or using a VPN do not prevent further correlation.”

Clearing cookies removes something you were holding, which is exactly why it works and exactly why it stops there. The site loses the token it gave you. It does not lose the record it built from how your device renders, and it does not lose anything about the address your request arrived on.

Changing your visible address changes the network a request appears to come from, and leaves the browser alone. Your fonts, your rendering behaviour, your timezone and your screen dimensions all arrive unaltered.

Reducing your fingerprint is a matter of degree rather than removal, because there is nothing to delete, only a signal to make less distinctive. The same note is candid about the ceiling here, saying that “complete elimination of the capability of browser fingerprinting by a determined adversary through solely technical means that are widely deployed is implausible.”

There is a small irony sitting in the middle of all this. Whether your browser accepts cookies is itself one of the values a fingerprinting script can read, and our own fingerprint test reports it as a row like any other. Switching cookies off does not take you out of the picture. It alters one detail of it.

What the browser checks can and cannot tell you

Whether cookies are enabled is one of the values in what your browser announces about itself, and what sits inside them is not. That readout sets the cookie state beside Do Not Track, language, platform, screen, viewport, a CPU estimate and a device memory estimate, then prints the request headers our server receives. Two things are held back from that second list deliberately, and the page names both: authorisation headers, and cookies. The tool confirms the channel is open without opening it. Your browser’s own settings screen is still where you see and clear the cookies themselves.

Our browser fingerprint exposure check puts its own limit in writing: “This is an exposure check, not a global uniqueness guarantee.” Alongside a score, it breaks the result down signal by signal, covering canvas, WebGL, the font signature, and one row, the TLS handshake, produced by your network stack instead of by the browser. How rare your particular combination is, it cannot say, because that answer needs a comparison population it does not hold.

Neither tool detects tracking. What they show is what is available to be collected, and that is a narrower thing to claim.

Three identifiers, three holders, three different remedies. That is the whole shape of it, and it is why an action aimed squarely at one of them leaves the other two where they were.