Internet and networks

What a cookie is

A cookie is a small scrap of text a site puts in your browser, and the browser sends that same scrap back on every later request to that site; this is exactly why you stay logged in after signing in once. A cookie is not a program and nothing of it runs on your device; it is only a label, and the whole argument is about who is allowed to read that label.

  • Lesson 12 of 12
  • Beginner
  • Free, no signup

Four cookies an ordinary page can carry

The numbers point at the role of each cookie, not at where you see them; a cookie is not visible on the page.

  • 1

    The session and login cookie

    First party and essential. Without it you would sign in again on every click, and it has no place in a consent banner.

  • 2

    The basket and preferences

    First party. The language you picked and the message you dismissed sit here too, and go when you clear cookies.

  • 3

    The analytics cookie

    Usually first party, but written by JavaScript rather than a server header. First party does not mean harmless.

  • 4

    The third party cookie

    From the domain of an embedded video or an advert. This is the one that makes cross site tracking possible.

A page can carry none of these. The front page of this very site sets no cookie from the server side for an anonymous visitor.

Last checked: Facts and tool names in this lesson are re-checked against their sources on this date.

The protocol the web is built on has no memory. Every request is a stranger to the server, and once it has answered, it forgets you. If nothing sat in between, you would have to log in again every time you clicked a link inside a site.

A cookie is that thing. The server answers a request with a Set-Cookie header and the browser stores that text; from then on the browser sends the same text back on every request to that domain. The server reads it and knows you are the same person who logged in ten seconds ago. The rules are written in RFC 6265 and have been roughly the same since the 1990s.

It has three main uses and the first outweighs the others. Holding a session, meaning staying logged in. Holding state, such as a shopping basket and the language you picked. And counting and tracking, which is the part that became contentious.

Let us end one common misunderstanding right here: a cookie is not a virus and cannot be one. A cookie is text and text does not run. A site cannot use a cookie to read your files or reach your camera. The danger of cookies comes from somewhere else: if somebody steals your session cookie, they can get in as you without knowing your password, and this is why sites invalidate every session after a password change.

A glass cookie with a white tag travelling between a red browser frame and a blue server box

The difference is not technical, it is one of ownership. A first party cookie is set by the same domain written in the address bar. A third party cookie is set by another domain that supplies a piece of that page: an embedded video, a social button, an advert, or an analytics script.

And that single difference is what makes cross site tracking possible. Suppose an advertising company has a script on a thousand different sites. Every time you open one of those thousand, your browser sends that company its own cookie back, because the cookie belongs to that company domain and has nothing to do with the site you opened. The result is that the company holds a list of the sites you visit without you ever having dealt with it.

Browsers have been restricting this for years and today they do not behave alike. Firefox keeps each site cookies in a separate jar for that site, under a name of its own, and Safari has an option for preventing cross site tracking. This situation has shifted year by year and may shift again; rather than believing a sentence in an article, open your own browser privacy settings page and see what is switched on right now.

One distinction worth keeping clear: the session cookie of a site you are using and the cookie of an advertising network are technically the same thing and, in meaning, two entirely different things. The privacy argument is about the second, not the first, and blocking cookies wholesale blocks both together.

One technology, two owners, two meanings

First party cookie

  • Set by the same domain written in the address bar
  • Sent back only to that same site
  • Login, basket, language, and that site own analytics
  • Browsers usually do not restrict it
  • Blocking it means a broken site, not more privacy

Third party cookie

  • Set by another domain that supplies a piece of the page
  • Sent back on every site that carries the same piece
  • Adverts, social buttons, embedded video
  • Browsers have restricted it for years and do not behave alike
  • Blocking it usually breaks nothing

The line between these two is not always clean. An outside service can run from a subdomain of the site itself and count as first party to the browser while still sending the data to that outside company.

We will show this with our own site, because a real example beats an abstract explanation. If you open the front page of rgb.ir right now as an ordinary visitor, the site gives you no cookie at all: there is not one Set-Cookie header in the server answer. Nor does it need one, because an anonymous visitor has nothing to remember.

But it is that absence of a cookie that decides what you are given. There is one line in our web server configuration that, before any PHP runs at all, looks at the cookie header of the request and searches for four names: the WordPress login cookie, the password protected page cookie, the cookie of somebody who has commented before, and the user role cookie the cache plugin writes. If none of them is there, the web server sends a ready made file off the disk and PHP never wakes up. If one of them is there, the request is handed to WordPress so the page is built afresh.

So the millisecond difference between a visitor and a logged in user sits in that one label. And it explains why some problems are only seen by logged in users and go unnoticed by you, who are always logged into your own site: you and your guests are effectively receiving two different pages.

One more thing follows from here. The Google analytics script on this same site writes its cookie not with a server header but with JavaScript inside the browser, and because it runs on our own domain it is a first party cookie. Which means first party alone does not mean harmless; it only says who wrote it.

The question our web server asks before anything else

Does the request carry one of the four cookies

yes

The page is built afresh

  • the WordPress login cookie
  • the password protected page cookie
  • the cookie of somebody who has commented
  • the user role cookie the cache plugin writes
no

A ready made file off the disk

  • no PHP runs at all
  • no query reaches the database
  • the answer sets no cookie either
  • what every guest of the site receives

This decision belongs to the configuration of this site and every site has its own rule. The transferable point is that the absence of a cookie decides as much as its presence.

What does clearing cookies actually do?

Three things, and no more. You are logged out of every site you were signed into. The small preferences sites remembered disappear, such as the language you picked and the fact that you dismissed a message. And the basket empties on sites that keep it in a cookie, though many shops keep it on your account and nothing is lost.

Now three things clearing cookies does not do that people think it does. It does not delete your account and removes nothing from the site server; whatever the site stored about you is still there. It does not make you anonymous, because your IP address, your browser characteristics and above all the account you are about to sign back into are all still there. And it does not empty the browser cache; that is a different thing with its own separate option in the same settings window.

So when is it genuinely useful? For one specific class of problem with clear symptoms: when you are stuck in a login loop and the site keeps returning you to the sign in page, when a site insists on recognising you as an old account, and when a form keeps throwing a strange, unexplainable error. In support, when we see those three signs this is the first thing we ask for.

And a practical warning: clearing cookies throws you out of everything, including places whose password you do not remember. Before pressing that button, make sure you can reach your recovery email. If your trouble is with one site only, the same window lets you clear the cookies of that one domain and leave the rest untouched; that is almost always the better option.

Its root is a European law, not a technical standard. The European Union directive on electronic privacy says consent is required to place something on a user device, and it explicitly exempts the things strictly necessary to deliver the very service the user asked for. This is why the login cookie is not in that banner and does not need to be: without it, the service you asked for does not work at all.

In Iran there is no law that requires this banner. So most of the banners you see on Persian sites either came with a foreign template or were added because everybody else has one.

And now a position not everyone likes. A banner that sets tracking cookies before you click and then says that by continuing you have agreed is worse than having no banner. Because it has already done the thing, and on top of that it claims a consent it never obtained. If you are going to put up a banner, either genuinely wait for the click and load no non essential script until that moment, or do not put one up at all and have a clear privacy policy page instead that says what you collect.

And as people who implement this on client sites, let us name a hidden cost: every consent banner is a layer of JavaScript that runs on every page load, and it is usually among the first things to show up in a speed report. If it is not going to change the behaviour of the site for real, you are only selling every visitor some extra weight.

The fast path, with AI

The ordinary way to find out what a site keeps about you is to read its privacy policy page, which is usually written in generalities. The fast way is to take the real list of cookies out of the browser yourself and then ask the language model to classify each one. The difference is that in a few minutes you see what the site actually set, not what the legal text says.

  1. Open a private window and visit only that one site. This takes your earlier cookies out of the picture and the result comes out clean.
  2. Before clicking any button in the consent banner, open the developer tools and look at the cookie list under storage. Whatever is there right now was set without your consent.
  3. Copy the name and domain columns, then click accept all and copy again. The difference between the two lists is exactly what your consent released.
  4. Hand both lists to the model and ask it to mark each cookie as first or third party and say which ones were set before you clicked. A fast, cheap model is enough here; the job is classification, not judgment.

Copy-ready recipe

You are a web privacy analyst. Work only from the two lists below and add no cookie that is not in them.

The domain of the site I opened: {domain}

Cookie list before clicking any banner button (name and domain):
{list}

Cookie list after clicking accept all (name and domain):
{list}

Build a table with these columns: cookie name, domain, first or third party, present before the click or after.
Decide first or third party only by comparing the cookie domain with the site domain I wrote.

After the table, write three sentences:
1. How many cookies were set before any click, and how many of those were third party.
2. Whether that is consistent with a consent banner claiming it sets nothing before a choice is made.
3. If you cannot tell what a cookie does from its name, write unknown. Do not guess.

Rule: write nothing from memory about what data any cookie collects unless its name is explicitly well known, and even then say that you are saying it from memory and that it must be confirmed from that service documentation.

Before you trust the output: Do not copy the value of a cookie, only the name and the domain. The value of a session cookie is effectively the key to that account, and pasting it into an online tool means handing over access. And do not treat the model answer about what data a cookie collects as evidence: it recognises well known names from memory and for the rest it constructs an explanation that cannot be checked. What this exercise genuinely gives you is one solid fact, and that is enough: how many cookies were set before you clicked.

AI in this kind of work

On this topic a language model does one job well and one job badly, and the boundary is exactly clear. Well: classifying a list you collected yourself, comparing two lists, and translating a legal text into ordinary language. Badly: telling you what data a particular cookie collects. That answer comes out of memory for a handful of very well known names and is constructed for the rest.

Tools that actually help

  • Gemini Enough for exactly this cookie list classification, and here a fast cheap model beats an expensive one, because the job is comparing domains and not judgment. Google own page says the Gemini app works in more than 230 countries and territories, and Iran is not on that list.
  • Claude For when you want to compare a site privacy policy text against the real list of its cookies, a job that is careful reading of two long texts. Iran is not on Anthropic list of supported countries, so there is no official route to sign up or pay.
  • Gemini Notebook If a service privacy policy runs to tens of pages, uploading it and asking from inside that document beats reading a summary, because the answer points back to its own clause. It runs on a Google account, and Iran is not among the available regions.

Where it backfires

Two risks, and the second is more serious than the first. First, about cookies whose names it does not recognise the model constructs an explanation that cannot be checked and reads as entirely certain; Anthropic itself calls this confident invention hallucination in its documentation and writes about reducing it, which means the vendor treats it as a real weakness. The second risk is yours and not the model: the value of a session cookie is effectively the key to that account, and whoever holds that string gets in without your password. Pasting a full cookie list with its values into any online tool is handing over access, and Google own help page for Gemini also says plainly not to enter confidential information. Send the name and the domain and never the value. For what paying for these tools looks like from Iran, see the buying guide.

Sources: Anthropic: reduce hallucinations Anthropic: supported countries Google: Gemini Apps privacy and data Google: where Gemini Apps are available

Where this advice stops

A cookie is not the only way to remember you and this lesson explains only that one way. Browsers have other stores that clearing cookies does not necessarily empty, and there are methods of recognising a browser with no cookie at all that lean on the combined characteristics of the device; both deserve their own lesson. Another boundary about the state of browsers: their treatment of third party cookies has been changing for several years and any sentence we write here about today may be stale within a year, so the final reference is your own browser settings page and not this one. And on the law: what appears here is a description of a European rule and is not legal advice; if your site has European users, check this with somebody who does that for a living.

From our own work

Two things from our own site, both checkable right now. First: the front page of rgb.ir sends no Set-Cookie header at all to an anonymous visitor; we requested it again today and the answer carried zero cookies. Second and more important: our web server configuration file holds one conditional line that, before any PHP runs, checks the cookie header of the request against four names, the same four we listed in the third section. If none of them is present the request is routed to a ready made file on disk and the answer carries the header x-fp-cache: HIT-nginx, meaning WordPress never ran at all; we fetched the front page with exactly that header just now. If one of those four names is present, that single label changes the whole route and the page is built afresh. We took this not from an article but from the file that is routing your own request at this moment.

Real follow-up questions

Is a cookie dangerous?

A cookie itself is text and does not run, so it is not a virus and has no access to your files or your camera. The real dangers are two: a stolen session cookie, which means somebody getting into your account without a password, and cross site tracking, which is a privacy matter rather than a security one. For the first, not signing into important accounts on an unfamiliar device and network has the largest effect.

What happens if I block cookies entirely?

You cannot stay signed in to any site and your basket and preferences are kept nowhere. Almost nobody does this, and the more sensible move is to block third party cookies only, which catches the tracking part and leaves the login cookie untouched. That option is in the privacy settings of every current browser.

Does my Persian site need a cookie consent banner?

No law in Iran requires it. If your audience includes European users the matter is different and you should check with somebody whose job is law. Our view: a banner that sets tracking cookies before the user clicks is worse than no banner, because it has done the thing and also claims a consent it did not obtain.

Keep learning