technology

Explain it: What Are Browser Cookies and Why Do Websites Use Them?

  • SHARE
Explain it

... like I'm 5 years old

You add a book to an online shop’s cart, browse a few other pages, and return to find the book still there. A browser cookie helps make that possible. It is a small piece of text stored by your browser for a website. When your browser contacts that site again, it can send the cookie back, allowing the site to recognize a continuing visit.

Websites use cookies because each request for a page is otherwise a separate interaction. A cookie might help a shop keep track of a cart, help a news site remember your display preferences, or help a service keep you signed in. Often, the cookie contains an identifier rather than your name or the contents of your cart. The website uses that identifier to find the corresponding information in its own system. For a broader look at how browsers and servers exchange requests, see how the internet works.

Cookies can serve less welcome purposes, too. A company whose advertising tools appear on several websites may use cookies to help recognize a browser across those sites. That is one reason cookie choices deserve a moment’s attention: a cookie that keeps you signed in and one used for cross-site tracking solve very different problems. You can review or delete stored cookies in your browser, although doing so may sign you out or reset preferences.

Think of a cookie as a coat-check ticket. The ticket does not contain your coat, but when you bring it back, the attendant can find what was set aside for you.

Explain it

... like I'm in College

Imagine opening a shopping site for the first time. Its server sends a page to your browser and can include an instruction to save a cookie. On a later request to the appropriate site, your browser returns that cookie. The server can then connect the request to an existing shopping session instead of treating it as an entirely new visit. Website code can also create some cookies in the browser, though it cannot access every cookie.

A cookie has a name and value, along with possible rules about where and when it is sent. Some are intended to last only for a browsing session; others have an expiration time and can remain after you close the browser. These choices help explain why one site forgets your cart overnight while another remembers a setting for weeks. A cookie is not a program, and it does not, by itself, reveal every page you visit. What matters is which site receives it and what information that site associates with its value.

The distinction between first-party and third-party cookies depends on the site you are visiting. A cookie used by the site in your address bar is first-party. A cookie associated with another site whose content is embedded on that page may be third-party. The latter can support useful embedded features, but it can also help link activity across unrelated websites. Browsers differ in how they limit that behavior.

If you want to understand a particular website’s practices, its privacy information is a better starting point than assuming every cookie has the same purpose. For instance, Explain It Daily’s privacy policy describes its stated uses of cookies and advertising tools.

EXPLAIN IT with

Picture two people building a Lego city. You are the visitor, working at one table; the website runs a parts counter at another. Each time you ask for a new set of instructions, you make a fresh trip to the counter. Without some way to connect those trips, the attendant may not know which unfinished project is yours.

The attendant gives you a small Lego tile marked with a project number. That tile is the cookie. You keep it at your table—your browser—and show it when you return to that counter. The attendant checks the number against a record behind the desk, where your selected pieces—the shopping cart—are listed. The tile need not contain the whole project; it can simply point the attendant to the right record.

Now imagine that the tile has rules. It might work only at this counter, or stop working at the end of the day. Another tile might remain useful longer so the attendant remembers which instruction language you prefer. Those are simplified versions of a cookie’s scope and lifetime. Taking away a tile may mean starting a new visit or choosing your preferences again.

Finally, suppose a separate Lego supply company operates a little kiosk inside several different builders’ rooms. If it can recognize the same tile in each room, it may connect your visits. That is the privacy concern behind some third-party cookies. The original counter’s tile helps you finish your castle; the kiosk’s tile might help someone follow where else you build. Same basic mechanism, very different reason to use it.

Explain it

... like I'm an expert

At the protocol level, HTTP does not inherently maintain an application session between requests. A server can issue a Set-Cookie response header containing a name-value pair; the user agent stores it and sends it in a Cookie request header when the applicable rules permit. The value commonly identifies server-side session state. Keeping an authentication session in a cookie does not mean placing a password in it, nor does it remove the need to protect the session identifier.

Those applicable rules are central to the design. Domain and Path influence where a cookie is sent; Expires or Max-Age controls its intended lifetime. Secure restricts transmission to secure connections, while HttpOnly prevents access through JavaScript APIs such as document.cookie. SameSite limits when cookies accompany cross-site requests, helping reduce certain cross-site request forgery risks. None of these attributes substitutes for sound session handling or broader defenses against attacks. Mozilla’s secure cookie configuration guide explains the practical trade-offs.

Scope and context also matter for privacy. A third-party resource embedded across multiple top-level sites may receive requests that enable cross-site recognition when its cookies are available. Restrictions on third-party cookies can interrupt that pattern, though implementation and exceptions vary by browser. Partitioned cookies address some embedded-service needs by separating a third party’s cookie storage according to the top-level site. They do not make every privacy concern disappear; they change one important way identifiers can be shared.

The engineering question, then, is not whether cookies are good or bad. It is whether each cookie has a necessary purpose, an appropriately limited scope and lifetime, and protections suited to the consequences if its value is exposed.

  • SHARE