Why does our website set cookies we never added?

A cookie is a note the server asks the browser to keep

Start with the mechanism, because almost every confusion here comes from imagining something more sinister or more complicated than what is happening.

MDN gives the plain definition: "A cookie (also known as a web cookie or browser cookie) is a small piece of data a server sends to a user's web browser."

The delivery is one line in a response. As the specification for that line puts it, "The HTTP Set-Cookie response header is used to send a cookie from the server to the user agent, so that the user agent can send it back to the server later." User agent is the technical word for the visitor's browser.

Why any of this exists is the part that makes the rest make sense. "Cookies enable web applications to store limited amounts of data and remember state information; by default the HTTP protocol is stateless".

Stateless means the web has no memory between requests. Every page load arrives as if it were the first. Without something like a cookie, a shopping basket empties between pages and a signed-in customer is a stranger on every click.

So cookies are not an add-on that somebody chose to bolt onto the web. They are the patch for a gap in how the web works, which is why they are everywhere.

MDN groups the uses into three: keeping a session going, remembering preferences, and tracking. Only the third is what people mean when they worry, and the first two are why you cannot simply switch the whole category off.

One more detail closes the loop on where they come from. The browser itself is an active participant, not just a filing cabinet: "The browser may store cookies, create new cookies, modify existing ones, and send them back to the same server with later requests."

The ones you did not add came with something you embedded

Here is the answer to the actual question, and the standard states it more plainly than most vendors will.

RFC 6265 describes what happens when a page is built from more than one source: "In rendering an HTML document, a user agent often requests resources from other servers (such as advertising networks). These third-party servers can use cookies to track the user even if the user never visits the server directly."

Read that against your own site. A map, a video player, a font, a chat widget, an analytics tag, a booking form, a review badge. Each one is content requested from somebody else's server, and each request is an opportunity for that server to set a cookie.

Nobody on your team added those cookies. Your team added a map.

The standard then explains what the third party gets out of it, which is the piece that makes a scan report look alarming: "if a user visits a site that contains content from a third party and then later visits another site that contains content from the same third party, the third party can track the user between the two sites".

That is the whole business model in one sentence. The value is not in knowing about your visitors. It is in recognising the same person across many sites, and your site is one of the many.

RFC 6265 is blunt about why cookies in particular do this well. They "facilitate tracking because they are persistent across user agent sessions and can be shared between hosts".

None of this means an embedded tool is a bad idea. It means an embedded tool is a decision with a second consequence, and the second consequence is invisible until somebody runs a scan.

Your visitors are not all seeing the same thing

This is where the subject gets genuinely confusing, and it is a fact about browsers rather than about your website.

The standard grants deliberate latitude here. "Some user agents restrict how third-party cookies behave." Some refuse to send cookies in third-party requests, and "Others refuse to process the Set-Cookie header in responses to third-party requests."

Then the summary, which is the sentence to remember: "User agents vary widely in their third-party cookie policies."

So two visitors on the same page with different browsers can end up with different cookies, and neither of them is experiencing a fault. Your own browser is one sample of one.

This has a practical edge. A tool that reports what your site does will report what it did in the browser it used. If somebody shows you a scan, ask what browser produced it before treating the list as the definitive answer.

It also means behaviour changes without you changing anything. Browser makers revise these policies on their own schedule, so a tag that quietly worked last year can stop working, and a tracking arrangement somebody sold you can decay without anybody telling you.

There are rules, and the documentation says whose problem they are

Cookies are one of the few web mechanisms with laws attached, and it is worth being precise about what can honestly be said here.

MDN lists European and Californian rules among the legislation covering cookie use, then makes a point owners routinely get wrong: "These regulations have global reach. They apply to any site on the World Wide Web that users from these jurisdictions access".

Not where your business is. Where your visitors are.

The requirements MDN describes go further than the banner most sites install. Beyond notifying people and letting them opt out, the list includes "Allowing users to use the bulk of your service without receiving cookies."

That is a design requirement, not a notice requirement, and a banner alone does not satisfy it.

On who is responsible, MDN is unambiguous: "The burden is on you to know and comply with these regulations."

We are not lawyers and cannot tell you what applies to your business. What we can tell you is the thing that actually trips people up, which is not a legal subtlety at all. Most owners believe installing a banner ended the matter. The documentation describes obligations about what the site does, and a banner is a notice about what the site does.

Finding out what your site actually does is the step almost everybody skips, and it is free.

What to check, in order

Five checks, and every one of them is free.

• Open your own site in a private window and look at the stored cookies in your browser's developer tools. Nothing to install, and it is the same information a paid scan sells you.
• List every embedded thing on your pages: maps, videos, fonts, chat, analytics, booking, reviews, social buttons. That list is almost certainly the source of the cookies you did not recognise.
• For each one, ask whether it is still earning its place. The cheapest fix is removing a widget nobody uses, because it takes its cookies with it.
• Check whether your banner actually gates anything. Many are installed so that scripts load and set cookies before anybody clicks, which means the banner is describing a decision that has already been made.
• Check in more than one browser, since policies differ and your usual browser is a sample of one.

Then keep the list. The useful artefact here is not a certificate or a badge. It is a short document naming everything embedded in your site, what it is for, and who decided to add it, because every cookie on the scan report traces back to one of those decisions.

Working out what a site is actually loading, and removing the things nobody can justify, is part of what we do when we look after a website.

Sources

• Using HTTP cookies (MDN Web Docs)
• The Set-Cookie header (MDN Web Docs)
• RFC 6265, HTTP State Management Mechanism (RFC Editor, Standards Track)

Last reviewed 2026-09-12.