What is a cookie? Browser cookies explained

TL;DR: A cookie is a small piece of data — typically a few hundred bytes — that a website stores in your browser to remember information between requests. Cookies power logins, shopping carts, and analytics; they also enabled the cross-site tracking era that browsers are now winding down.

A cookie is a name-value text record that a website sets in your browser via the Set-Cookie HTTP response header, and that the browser automatically attaches to subsequent requests to the same domain through the Cookie request header. Cookies are the original mechanism for state on an otherwise stateless HTTP web — they predate localStorage, IndexedDB, service workers, and every modern client-storage alternative. Every cookie you have ever encountered, from “stay signed in” to the EU consent banner asking about them, is governed by this single small protocol¹.

How cookies work

In short: Cookies are a thin layer on top of HTTP. The server sets one with a Set-Cookie: name=value response header; the browser stores it in a per-domain cookie jar; on every subsequent matching request the browser sends Cookie: name=value back. There is no client-side handshake — the browser obeys the server’s directives within the constraints of RFC 6265.

The cookie mechanism is widely credited to Lou Montulli, a Netscape engineer, who introduced it in 1994 to solve “remember the shopping cart between pages” for the e-commerce client MCI Net². Three decades later the underlying protocol is essentially unchanged. The formal specification is IETF RFC 6265¹, with an active revision in IETF drafts³ that tightens the security and privacy boundaries.

A minimal cookie exchange looks like this:

# Server response
HTTP/1.1 200 OK
Set-Cookie: sid=abc123; Path=/; HttpOnly; Secure; SameSite=Lax

# Subsequent client request to the same site
GET /account HTTP/1.1
Cookie: sid=abc123

The browser does not interpret the value abc123 — it is opaque to the browser. The server interprets it (typically as a database session key). The browser’s job is to decide which cookies to attach to each request based on the cookie’s Domain, Path, Secure, SameSite, and expiry attributes.

Key point: A cookie is set by the server, stored by the browser, and read by the server on every subsequent matching request. The browser is the courier, not the author.

Anatomy of a cookie

In short: A cookie has one mandatory part (name=value) and seven attributes the server can set: Domain, Path, Expires, Max-Age, Secure, HttpOnly, and SameSite. Each attribute narrows or restricts when the browser sends the cookie back.

The full attribute set defined by RFC 6265¹ and its bis revision³:

• Name and Value — the only mandatory pair. ASCII text. Together must fit in roughly 4 KB⁴.
• Domain — defaults to the host that sent Set-Cookie. Setting Domain=example.com makes the cookie apply to example.com and all subdomains.
• Path — defaults to the request path’s directory. Setting Path=/account scopes the cookie to URLs under /account.
• Expires / Max-Age — date or duration. Omitting both makes the cookie a session cookie (deleted when the browser session ends). Max-Age=0 deletes the cookie immediately.
• Secure — when set, the browser only sends the cookie over HTTPS. Plain-HTTP requests do not see it.
• HttpOnly — when set, JavaScript in the page cannot access the cookie via document.cookie. The primary defense against session-cookie theft through XSS.
• SameSite — Strict / Lax / None. Governs cross-site request behavior (covered below).
• Priority (Chrome-specific extension) — Low / Medium / High. Hints to the browser which cookies to evict first when the per-domain cookie jar is full.

Types of cookies

In short: Cookies are classified along two orthogonal axes — lifetime (session vs persistent) and origin (first-party vs third-party). A single cookie always has one value on each axis. Privacy regulations and browser settings then layer on a usage-based category system (strictly necessary / functional / analytics / advertising) that you see on consent banners.

Six common categories users and regulators talk about, mapped onto the underlying protocol:

The Information Commissioner’s Office (UK) summarizes the distinction succinctly⁶:

Strictly necessary cookies are those that are essential to provide an online service requested by the user. Most other cookies require informed consent before they are set.

What cookies are used for

In short: At the protocol level a cookie is generic name-value storage. In practice, the web uses cookies for six distinct jobs, in roughly decreasing order of how much they matter to user experience.

The six dominant cookie use cases on the modern web:

1. Authentication and session management — a session ID cookie that tells the server which logged-in user a request belongs to. Almost always HttpOnly, Secure, SameSite=Lax or Strict.
2. CSRF protection tokens — a random anti-forgery value the server checks on state-changing requests. Usually paired with a hidden form field.
3. Shopping cart and unfinished work — preserving cart contents and form drafts across page loads. Often a single ID pointing at server-side state.
4. User preferences — language, theme, layout density, accessibility settings. Small persistent cookies with Max-Age of months to years.
5. First-party analytics — visitor identification and session timing for products like Plausible, Fathom, or self-hosted PostHog (when configured cookie-based).
6. Advertising and cross-site tracking — third-party cookies set by ad networks, retargeters, and analytics platforms that need to identify the same user across multiple sites. This is the category browsers are actively winding down.

For developers, the practical implication is that most cookies you set should be first-party, scoped to the current site, marked HttpOnly and Secure, and given SameSite=Lax unless you have a specific cross-site flow that needs None.

SameSite, HttpOnly, Secure — the three security attributes

In short: Three cookie attributes — SameSite, HttpOnly, and Secure — defend against three different attack classes. Setting all three correctly is the single highest-leverage cookie-security improvement a server can make.

These three attributes form the modern cookie-security baseline. Each defends against a specific attack class:

• Secure defends against passive network sniffing. The browser refuses to send the cookie over plain HTTP. Required on any cookie that holds session state, since session theft over an open Wi-Fi network is otherwise trivial.
• HttpOnly defends against XSS-driven session theft. JavaScript injected into the page via a cross-site-scripting vulnerability cannot read an HttpOnly cookie via document.cookie. The server still sees it; the attacker’s script does not.
• SameSite defends against CSRF and cross-site tracking. Three values:
  • SameSite=Strict — the cookie is only sent on same-site requests. Maximum protection; sometimes inconvenient (a user clicking from another site to your domain will appear logged-out on the first request).
  • SameSite=Lax — the cookie is sent on same-site requests plus top-level cross-site GET navigations (link clicks). The modern Chrome default since 2020⁷.
  • SameSite=None — the cookie is sent on every cross-site request. Required for legitimate third-party cookies (single sign-on, embedded payment widgets). Must be paired with Secure.

Google’s web.dev guidance is explicit on the priority order⁷: “If you only do one thing today, set SameSite=Lax on every session cookie.”

First-party vs third-party cookies and the deprecation story

In short: A first-party cookie is set by the site in the URL bar; a third-party cookie is set by another domain whose code runs on that site. Third-party cookies built the modern ad-tracking economy, and modern browsers are systematically restricting or eliminating them.

The third-party cookie wind-down is the most consequential change to the cookie ecosystem since the protocol was created. Status by browser as of mid-2026:

• Safari — third-party cookies have been blocked by default since Intelligent Tracking Prevention (ITP) shipped in Safari 11 (2017), with successive tightenings.
• Firefox — third-party cookies are partitioned by default under Total Cookie Protection (TCP) since 2022, effectively eliminating cross-site tracking.
• Chrome — after multiple postponements of full third-party cookie deprecation⁵, settled on a user-choice approach with Privacy Sandbox APIs as the proposed replacement for ad targeting, attribution, and fraud prevention.

For legitimate cross-site use cases (federated login, embedded checkout iframes), the modern alternative is CHIPS — Cookies Having Independent Partitioned State⁸. A cookie with the Partitioned attribute is stored in a separate jar per top-level site, so the same iframe loaded under two different parent sites cannot read the same cookie. CHIPS preserves the legitimate “remember settings inside this widget” use case while breaking the cross-site identifier flow.

If you maintain a service that depends on third-party cookies today, the immediate work is auditing your cookies for which ones need cross-site visibility (use CHIPS) versus which were tracking by design (rebuild on Privacy Sandbox or first-party data).

How to view, edit, and delete cookies

In short: Every modern browser lets you view cookies through Settings or DevTools. For repeatable workflows — debugging session bugs, exporting cookies as test fixtures, auditing what a site stored — a Manifest V3 extension like CookieVault Editor is the standard tool. The eight-step inspection workflow below works on every Chromium browser.

Eight-step quick reference for viewing and editing cookies in Chrome (Edge, Brave, Opera, Vivaldi, Arc work identically; Firefox is similar with a different menu layout):

1. Open the target site in a tab.
2. Press F12 to open DevTools.
3. Click the Application tab.
4. In the left sidebar under Storage, click Cookies.
5. Click the domain to see all cookies in scope.
6. Double-click a cell (Value, Expires, SameSite, etc.) to edit it in place.
7. Press Enter to commit the edit; the browser applies it immediately.
8. Reload the page to send the modified cookie on the next request.

For deleting cookies in bulk, the Chrome cookie deletion guide covers three methods. To keep logins while clearing trackers see clear cookies but stay logged in. For one-click repeatable edits across many sites, CookieVault Editor is the open-source Manifest V3 tool we maintain.

Common misconceptions about cookies

A short cleanup of statements you may have seen on the internet that are not true:

• “Cookies are viruses” — false. A cookie is a passive text record. It cannot install software, run code, or access files outside the browser’s cookie store.
• “Cookies store your password” — almost always false. A login cookie holds a session ID, not a password. The password is sent once to the server, hashed, and the server returns a session ID cookie. The password itself is not in the cookie.
• “Disabling cookies makes you anonymous” — false. Browsers are fingerprintable through many other channels (User-Agent, screen resolution, fonts, WebGL hashes, IP address) that do not depend on cookies.
• “All cookies track you across sites” — false. First-party cookies set by the site you are visiting do not see you on other sites. Cross-site tracking is specifically a third-party cookie concern.
• “Cookies are illegal under GDPR” — false. Cookies are legal. What GDPR (and the ePrivacy Directive) regulate is the consent requirement for non-essential cookies. Strictly necessary cookies do not require consent.
• “Clearing cookies fixes every browser issue” — partially true. Clearing cookies will reset session and preference state. It will not fix cached resources, service worker bugs, or extension conflicts.

See also

• How to delete cookies in Chrome
• Clear cookies but stay logged in
• How to edit cookies in Chrome
• How to export cookies to JSON
• CookieVault Editor — the open-source Manifest V3 cookie manager
• CookieVault Guardian — auto-delete cookies on tab close