How HTTP Cookies Work

BY TOOLS.FUN · MARCH 28, 2026 · 6 min read

HTTP cookies are small pieces of data a server sends to the browser, which the browser stores and sends back with subsequent requests. They are the foundation of sessions, personalisation, and much of the modern web — yet misunderstanding them leads to security holes and privacy issues.

How Cookies Are Set

A server sets a cookie by including a Set-Cookie header in the HTTP response:

Set-Cookie: session_id=abc123; Path=/; HttpOnly; Secure; SameSite=Lax

The browser stores this cookie and attaches it to every subsequent request to the same origin. You can inspect the raw headers of API calls using the cURL Converter to see exactly which cookies are being exchanged.

Session vs Persistent Cookies

A session cookie has no Expires or Max-Age attribute — it is deleted when the browser closes. A persistent cookie includes one of those attributes and survives browser restarts. Most login "remember me" features use persistent cookies with a long expiry, while shopping-cart state often lives in session cookies.

Key point: Never store sensitive data directly in a cookie. Store only an opaque session identifier and keep the actual data server-side.

Cookie Attributes for Security

Several attributes harden cookies against common attacks:

Secure — cookie is only sent over HTTPS. HttpOnly — cookie cannot be read by JavaScript (document.cookie), mitigating XSS theft. SameSite — controls whether the cookie is sent with cross-site requests.

Always set all three on authentication cookies. Use the Base64 Encoder to decode cookie values that are Base64-encoded (a common pattern in JWTs and serialised session blobs).

Understanding SameSite

The SameSite attribute has three values: Strict (never sent cross-site), Lax (sent on top-level navigations but not sub-requests), and None (always sent, requires Secure). Modern browsers default to Lax when no value is specified, which blocks most CSRF attacks by default.

Cookies and CSRF

Cross-Site Request Forgery exploits the fact that browsers automatically send cookies. An attacker's page can trigger a POST request to your bank, and the browser will attach your session cookie. SameSite=Lax or Strict blocks this, and adding a CSRF token provides defense-in-depth. You can generate strong random tokens with the Password Generator.

Key point: SameSite=Lax is a good default for most cookies. Only use SameSite=None when you explicitly need cross-site cookie sending (e.g., third-party embeds) and always combine it with Secure.

First-Party vs Third-Party Cookies

A first-party cookie belongs to the domain in the browser's address bar. A third-party cookie belongs to a different domain — typically an ad network or analytics provider embedded via an iframe. Browsers are increasingly blocking third-party cookies to protect user privacy. Chrome's Privacy Sandbox and Safari's Intelligent Tracking Prevention (ITP) have fundamentally changed how tracking works on the web.

Cookie Size and Limits

Browsers limit cookies to approximately 4 KB per cookie and roughly 50 cookies per domain. Exceeding these limits silently drops cookies. For large data, use server-side sessions and keep the cookie itself small — just a session identifier.

Debugging Cookies

Browser DevTools (Application → Cookies) show every cookie for the current domain, including all attributes. You can also use the document.cookie API in the console (for non-HttpOnly cookies) or the URL Encoder to decode percent-encoded cookie values.

Key point: When debugging authentication issues, always check cookie attributes first — a missing Secure flag on HTTPS, a wrong Path, or SameSite=Strict on a cross-origin flow are among the most common culprits.

← Back