Small pieces of data the browser stores and sends back to the server with each request, often carrying the "it's still me" proof.
Why it exists
The browser needs to hand the same small piece of identifying data back to the server on every request, automatically, so the server can recognize a returning visitor. Asking the user to resupply it each time is impossible. Cookies exist as the browser's built-in way to store and resend that data, which is what keeps you logged in and your cart intact between pages.
How it actually works
When you log in, the server can hand the browser a cookie. The browser keeps it and automatically attaches it to every future request to that site, which is how the server recognizes you without asking again.
Cookies also store preferences and, controversially, tracking identifiers used by advertisers. The same simple mechanism serves login and surveillance, which is why cookie law and consent banners exist.
A senior PM walks you through it
A junior PM, stuck
Legal asked me for a list of which TiffinBox cookies need a consent banner and which do not, and I cannot tell our login cookie apart from the tracking one. They both look like a name, a random value, and some settings I do not understand. I do not want to either block users behind a banner they should not see or skip consent on something that legally needs it.
A cookie is one line the server sends the browser, and the parts that decide consent are all readable on that line: whose domain set it, and whether it is there to keep someone logged in or to follow them around. You can classify these in about five minutes. Here is the login cookie TiffinBox sets, split attribute by attribute, next to a third-party tracking cookie that landed on the same page, because the difference between them is the whole answer for legal.
The login cookie and a tracking cookie, from the same page load
The login cookie, set by POST /api/auth/login
1Set-Cookie: tb_session=9f2a7c1e8b40d5;
2 Max-Age=2592000;
3 Path=/;
4 HttpOnly;
5 Secure;
6 SameSite=Lax
A third-party tracking cookie set on the same page
7Set-Cookie: _ga=GA1.2.884201.1741267261;
8 Domain=.analytics-vendor.com;
9 Max-Age=63072000;
10 Path=/
Click a step to see the lines it points at.
Mistakes I've seen
Putting every cookie behind the consent banner. The login cookie is strictly necessary, so gating it logs users out until they click accept, and it does not need consent in the first place.
Deciding ownership by the page a cookie appeared on. The Domain field is what says who gets the data; a cookie set on your checkout page whose Domain is a vendor's is the vendor's cookie, and the data leaves with them.
Reading the value and skipping the flags. HttpOnly and Secure are the whole difference between a session a script can steal and one it cannot, and the random string tells you nothing about that.
Filing "logged out when I switched browsers" as a bug. A cookie lives in one browser on one device, so a new browser simply has no tb_session yet, which is expected behavior, not a defect.
Reply to legal with: "tb_session is strictly necessary. It is our first-party login cookie, HttpOnly and Secure, and it expires in 30 days, so it needs no consent. The _ga cookie is a third-party tracking cookie on a vendor domain with a two-year life, so it must sit behind consent and not be set until the user agrees." You classified each cookie by its domain, its flags, and its job. That is the entire skill.
Where a PM meets this
Cookie consent and privacy law (what you may store, what needs permission) are product-and-legal decisions, not just engineering ones.
"Logged out when I switched browsers" is expected: cookies live in one browser on one device.
Hear it in a meeting
"That tracking cookie needs consent under the new policy."