How Does Cookies Work? | Browser Data Made Simple

Cookies are one of those web ideas you use all day without noticing. You open a shop site and your cart is still there. You refresh a page and you’re still signed in. You set dark mode once and it “sticks.” None of that happens by magic.

The web runs on HTTP requests: your browser asks for a page, the server replies, and that’s it. Each request stands alone unless the browser and server agree on a way to remember something. Cookies are one of the oldest, simplest ways to do that.

This article breaks cookies down into the real mechanics: what gets stored, when it gets sent, how rules like Domain, Path, and SameSite change behavior, and why cookie settings can make logins loop or carts reset.

How Does Cookies Work? In Plain Browser Terms

At a high level, the flow has two moving parts: a server can ask the browser to store a cookie, and the browser can attach that cookie to later requests that match the cookie’s rules.

When a server wants to set a cookie, it sends an HTTP response header. Your browser reads it, stores the cookie, and applies the cookie’s attributes (like when it expires or which paths it can be sent to). The standard header used for this is the Set-Cookie response header.

On later requests to the same site (and only when the cookie’s scope rules match), the browser adds a request header that contains one or more cookies. The server reads those values and decides what to do next, like mapping a session ID to your account state.

What Actually Happens On A Page Load

1. Your browser requests a URL. It sends a normal HTTP request for a page, an API call, or an image.

2. The browser checks stored cookies. It filters cookies by rules like domain and path, then decides which ones are eligible to send for this request.

3. Eligible cookies get attached. The browser includes those cookie name/value pairs in the request.

4. The server responds. It may return content, and it may include one or more Set-Cookie headers to create, update, or expire cookies.

5. The browser stores updates. It writes new cookie values, refreshes expiry timers, and applies attribute rules.

Why Cookies Exist In The First Place

HTTP is mostly stateless: a server can’t assume that two requests came from the same person. Cookies let a server store a small token in the browser so the next request can carry identity or preference information back to the server.

The best mental model is this: a cookie is a label your browser is willing to carry for a site, with strict rules about when that label gets shown.

What A Cookie Can Store And What It Should Not

A cookie is a name and a value, plus metadata (attributes). The name/value part is the payload. The attributes are the rules for when the payload can be sent.

Cookies are not a safe place for secrets. A cookie value can be seen by the browser and may be exposed in different ways depending on attributes and scripts running on a page. Many sites store an opaque session token in a cookie rather than personal data. The server keeps the real account data on its side and uses the token as a lookup pointer.

Common Cookie Payload Patterns

• Session ID token. A short random string that maps to server-side session state.

• Preference flags. Theme choice, locale, dismissed banner state, or layout toggles.

• Non-sensitive UX memory. Last seen item ID, sort order, or a “seen tour” marker.

Session Cookies Vs Persistent Cookies

The term “session cookie” often confuses people because it sounds like it must be tied to login sessions. In cookie terms, “session” usually means “stored until the browser session ends.” A session cookie has no explicit expiry timestamp, so it typically disappears when the browser closes.

A persistent cookie has an expiry set through attributes like Expires or Max-Age. That means it can stay on disk and survive browser restarts until it expires or you delete it.

Login flows may use either style. Some sites keep login state in a short-lived session cookie and refresh it via background requests. Others use persistent cookies with tighter flags and short expiry windows to reduce risk.

First-Party And Third-Party Cookies

“First-party” and “third-party” describe the relationship between the site you’re visiting and the domain that set the cookie.

A first-party cookie is set by the site shown in your address bar (or a closely related domain used by that site). A third-party cookie is set by a different domain that’s embedded into the page, like an ad tag, a widget, or an analytics endpoint loaded from another domain.

Modern browsers have tightened rules around cross-site tracking and third-party cookies. That has changed how ad tech and embedded services work, and it’s why you may see more “sign in with a popup” patterns or redirected auth handshakes.

Cookie Types And What They Do

People use “cookie type” in casual ways. Here are common categories, plus what they tend to mean in practice.

Cookie Type	What It Usually Means	Where You’ll Notice It
Session cookie	Stored until the browser session ends	You sign out when the browser closes
Persistent cookie	Has an expiry time (Expires or Max-Age)	“Keep me signed in” or saved preferences
First-party cookie	Set by the site you’re visiting	Cart state, login token, site settings
Third-party cookie	Set by an embedded different domain	Embedded services, older ad tracking setups
HttpOnly cookie	Not readable by JavaScript on the page	Session tokens that resist script-based theft
Secure cookie	Only sent over HTTPS	Login and account flows on secure sites
SameSite cookie	Controls cross-site sending behavior	Checkout, SSO logins, embedded widgets
Partitioned cookie	Isolated per top-level site context	Some embedded content that still needs state

Cookie Attributes That Change Everything

Most cookie confusion comes from attributes. The name/value is easy. The rules are where real behavior lives. The server sets these attributes in the Set-Cookie header, and the browser enforces them.

Domain And Path

Domain defines which hostnames can receive the cookie. If a cookie is scoped to a parent domain, it may be sent to subdomains too. If it’s scoped tightly, it may be sent only to the exact host that set it.

Path limits the cookie to a URL path prefix. A cookie with Path=/account might be sent to /account/settings but not to /blog.

These two attributes are the main reason you can be signed in on one subdomain and signed out on another. It’s not always “broken auth.” It can be a scope mismatch.

Expires And Max-Age

These control lifetime. Expires uses a timestamp. Max-Age uses a number of seconds from the time it was set. If neither is present, the cookie is usually treated as a session cookie.

When a cookie expires, the browser stops sending it. Many servers also set an expiry in the past to force deletion.

Secure And HttpOnly

Secure means the cookie is sent only over HTTPS. That blocks the cookie from riding along on plain HTTP requests.

HttpOnly blocks access from JavaScript running on the page. The browser can still send the cookie to the server, but scripts can’t read it through document.cookie. This reduces the blast radius of script injection bugs.

SameSite

SameSite controls whether a cookie is sent in cross-site request contexts. If you’ve ever had a login popup fail, a checkout redirect lose state, or an embedded app forget you, SameSite rules can be involved.

At a high level:

• SameSite=Strict is restrictive. The cookie is held back on many cross-site navigations.

• SameSite=Lax is a middle ground. It often allows cookies on top-level navigations while limiting background cross-site requests.

• SameSite=None allows cross-site sending, and it is commonly paired with Secure.

Prefixes Like __Host- And __Secure-

Some cookie name prefixes signal tighter rules. A cookie starting with __Host- is intended to be host-only and scoped to the root path. __Secure- signals that it should be set over HTTPS. These prefixes help teams avoid weak cookie settings in large systems.

Cookies And Caching, Tabs, And Incognito

Cookies interact with other browser features in ways that surprise people.

Cookies Are Separate From Cache

Your cache stores copies of files like images and scripts. A cookie stores state tokens and preferences. Clearing cache alone won’t always fix a broken sign-in loop, because the cookie that drives the session can still be present.

Multiple Tabs Share Cookie Storage Per Profile

Tabs in the same browser profile usually share cookie storage. That’s why signing out in one tab signs you out in another. It’s one jar of cookies per profile, not per tab.

Private Browsing Uses A Separate Temporary Store

Private browsing modes keep cookies isolated from your normal profile and wipe them when the private window closes. That’s why private mode is a quick way to test whether an issue is caused by stored cookies.

When Cookies Go Wrong And What It Looks Like

Cookie issues often show up as “the site is broken,” but the symptoms are pretty consistent. You might see sign-in pages refresh endlessly, carts empty after each click, or settings that refuse to stick.

The trick is to match the symptom to the likely cookie rule that’s failing.

Symptom	Common Cookie Cause	What To Try
Login loop after entering correct password	Session cookie not being stored or not being sent back	Allow site cookies, then retry; try a private window
“Stay signed in” never sticks	Persistent cookie blocked or expiring fast	Check cookie settings; clear site data and sign in again
Cart empties after each page change	Cart ID cookie missing or scoped to a different path/domain	Disable strict blocking for that site; reload and test
Embedded sign-in fails inside another site	SameSite blocks cross-site cookie sending	Open the service in a top-level tab and sign in there
Site works in one browser but not another	Different default cookie blocking rules	Compare privacy settings and extensions between browsers
Random logouts during the day	Clock skew or short Max-Age window	Fix system time; sign in again after adjusting
Admin panel actions fail after login	HttpOnly/CSRF token mismatch, stale cookies	Clear site cookies only (not all browsing data) and retry
Works on Wi-Fi, fails on a captive network	HTTP intercept breaks HTTPS flow, cookie not set	Complete captive portal step, then reload the site

Cookie Rules From The Standard View

Cookies have a long history and a lot of edge cases. The formal behavior is defined in standards that spell out how Cookie and Set-Cookie headers work, along with parsing rules and storage rules. A foundational reference is RFC 6265 (HTTP State Management Mechanism), which describes core cookie semantics and how user agents should store and send them.

You don’t need to read the whole standard to understand day-to-day behavior, but it helps to know that browsers follow a written set of rules, not vibes. When something breaks, it usually traces back to a rule mismatch: scope, expiry, cross-site sending, or blocked storage.

Practical Tips For Readers

If you’re not building websites and you just want things to work, these are the highest-yield habits.

Clear Site Cookies Without Nuking Everything

When a single site is stuck in a bad state, clearing only that site’s cookies is cleaner than wiping all browsing data. It keeps other sessions intact and it removes the one cookie jar that’s causing the loop.

Watch Extensions That Intercept Requests

Privacy extensions, script blockers, and some antivirus add-ons can block third-party requests and cookies. That can be great for tracking reduction, but it can also break sign-in flows that rely on cross-site redirects.

Use A Private Window As A Fast Test

If a site works in a private window but not in your regular profile, stored cookies or extensions are the likely difference. That test saves time.

Practical Tips For Developers

If you build web apps, cookie choices show up as user pain fast. A few patterns help keep things steady.

Store Tokens, Not Personal Data

Keep cookie payloads small and opaque. Put sensitive state on the server, and store a random identifier in the cookie. That limits harm if a cookie leaks.

Set Tight Scope

Be deliberate with Domain and Path. Loose scope can leak cookies to places you didn’t intend, especially across subdomains. Tight scope can prevent accidental collisions between apps.

Use Secure And HttpOnly For Session Cookies

Session cookies that represent authentication are safer with Secure and HttpOnly set. Secure avoids plain HTTP transport. HttpOnly blocks script access in the page context.

Plan SameSite For Auth And Payments

Login redirects, SSO, and payment provider handoffs often involve cross-site navigation. SameSite rules can block cookies in those moments. Test flows in real browsers with real settings, including strict modes.

So, What Should You Take Away?

Cookies are small, but their rules are where the action is. A server sets them through response headers, the browser stores them with attributes, and later requests carry them back only when scope and cross-site rules say “yes.”

When cookies behave, web apps feel smooth: sign-ins persist, carts stay stable, and preferences stick. When rules clash or storage gets blocked, the symptoms tend to repeat. Once you know the moving parts, those bugs stop feeling random.