Once you understand that cookies are about memory, the next question is obvious:

How do they actually work?

Cookies ride on HTTP

Cookies are not magic browser thoughts floating in the air.

They are usually passed through HTTP headers.

That means the browser and the server use standard request and response machinery to set and send them.

A common pattern looks like this:

  1. the browser makes a request
  2. the server responds with a Set-Cookie header
  3. the browser stores the cookie if it accepts it
  4. later requests may include that cookie back in the Cookie header

That is the loop.

Server-set cookies

The classic pattern is for the server to set a cookie in the response.

For example, the server might say:

  • here is a session identifier
  • here is a preference value
  • keep this for a while and send it back under the right conditions

This is the version many people are really talking about when they talk about cookies.

JavaScript-set cookies

Cookies can also be created or changed in JavaScript.

That means code running in the browser can write cookie values too.

This is often used for:

  • client-side preferences
  • certain analytics patterns
  • older script-driven state handling

However, not every cookie should be writable from JavaScript.

Some cookies are safer when JavaScript cannot read them directly.

Cookies have attributes that control how they behave.

These details matter.

Domain

A cookie can be scoped to a specific host or a broader domain.

That affects whether it applies only to one subdomain or across a larger portion of the site’s domain space.

Path

A cookie can be limited to a particular path.

That means the browser may only send it for certain parts of a site.

Expires / Max-Age

Cookies can expire.

Some are:

  • session cookies, which disappear when the browsing session ends
  • persistent cookies, which stay until a set time or duration passes

Secure

A Secure cookie should only be sent over HTTPS.

That is an important protection.

HttpOnly

An HttpOnly cookie cannot be read directly by JavaScript.

This is often used to reduce certain kinds of browser-side risk.

SameSite

SameSite helps control whether cookies are sent along with cross-site requests.

This matters for security and tracking behavior.

Common values include:

  • Strict
  • Lax
  • None

First-party and third-party context

People also talk about first-party and third-party cookies.

The short version is:

  • first-party cookies are associated with the site you are directly visiting
  • third-party cookies are tied to outside services participating in the page, such as ad or tracking systems

This distinction matters because it changes how much the cookie is about the site itself versus a larger tracking ecosystem.

What happens when cookies get too big?

Browsers and servers do not treat cookies like an infinite junk drawer.

Cookies have practical limits.

If a cookie grows too large, you can run into problems such as:

  • cookies being rejected
  • headers becoming bloated
  • requests carrying too much unnecessary data
  • mysterious breakage in sessions or application behavior

A cookie should carry just enough memory to do its job. It should not become a moving van full of state.

Why misconfigured cookies cause pain

When cookies are set with the wrong attributes, strange things happen.

Examples:

  • a cookie not being available where you expect it
  • a login session failing unexpectedly
  • state disappearing between subdomains
  • a cookie working over HTTP but not HTTPS
  • cross-site flows breaking
  • JavaScript being able to read something it should not

This is why cookies are easy to underestimate.

They look small. They can still break real parts of a site.

The practical mental model

If you want the practical model, use this:

  • the server or browser writes memory into a cookie
  • the browser stores it with rules attached
  • later requests may send it back depending on those rules
  • the server or browser uses that returned value to reconstruct continuity

That is the mechanism.

Final thought

Cookies are small, but they are part of serious machinery.

They travel on headers. They carry state. They obey scope and security rules. And when those rules are wrong, the web gets weird fast.

This article is part of a series:

  1. What Is a Cookie on a Website?
  2. Cookies Are Really About Memory
  3. How Website Cookies Actually Work
  4. Cookies, Privacy, and Consent

Next: Ready for the human and legal layer?

Cookies, Privacy, and Consent