How cookies work

A cookie is a small chunk of data that a website stores in the browser. Each cookie is a key-value pair with a set of attributes that determine when and where the cookie is used. Those attributes can control things like expiration dates or restrict the cookie to HTTPS-only transmission. Cookies can be set via HTTP headers or through the JavaScript document.cookie interface.

Cookies are one of the primary mechanisms for adding persistent state to websites. Over time their capabilities have evolved, but that growth has left some problematic legacy issues. To address those, browsers such as Chrome, Firefox, and Edge are moving toward more privacy-preserving default behaviors.

Consider a blog that shows a "What's new" promotion. You want returning users to be able to dismiss the promotion and not see it again for a month. Storing that preference in a cookie that expires in 2,600,000 seconds and is only sent over HTTPS would produce a header like this:

Set-Cookie: promo_shown=1; Max-Age=2600000; Secure

When the reader visits on a secure connection and the cookie is less than a month old, their browser sends the cookie back in the request header:

Cookie: promo_shown=1

You can also read and write site-accessible cookies in JavaScript by assigning to document.cookie. A single assignment creates or overrides the cookie with the given key. Reading document.cookie outputs all cookies available in the current context, each separated by a semicolon:

→ document.cookie = "promo_shown=1; Max-Age=2600000; Secure"
← "promo_shown=1; Max-Age=2600000; Secure"

→ document.cookie;
← "promo_shown=1; color_theme=peachpuff; sidebar_loc=left"

Popular sites tend to set far more than three cookies, and many of those get sent on every single request to the domain. A significant number of cookies carries implications: upload bandwidth is often more constrained than download, and the extra bytes on every outbound request add latency to time to first byte. Keep the number and size of cookies you set conservative. Use Max-Age to make sure cookies don't persist longer than necessary.

First-party versus third-party cookies

When you inspect the cookies on a site, you will see entries for a range of domains, not just the one in the address bar. A cookie matching the current site's domain is a first-party cookie; settings from any other domain are third-party cookies. This label is context-relative, not absolute, since the same cookie can be first-party on one site and third-party on another. It depends entirely on which site the user is currently visiting.

To continue the earlier example, suppose one of your blog posts hosts an image at /blog/img/amazing-cat.png, and another site decides to embed that exact image. If the visitor has the promo_shown cookie from your site, that cookie still gets sent when the browser requests the image from the third-party site. The promo_shown cookie serves no purpose in that context; it only adds overhead to the image request.

There are useful applications for third-party cookies, however. Embedded YouTube videos that offer a "Watch later" button rely on this mechanism to pass the signed-in session state into the embedded player. That means a signed-in visitor can use the button without having to leave your page and sign in again on the main YouTube site.

The open-by-default culture of the web has contributed to significant privacy and security concerns. Cross-site request forgery (CSRF) attacks depend on the browser attaching cookies to any request aimed at a given origin, regardless of which site initiated the request. If a user visits evil.example, that site can trigger requests to your-blog.example, carrying along the associated cookies. Without careful validation on your server, evil.example could cause unwanted actions such as deleting posts or injecting content.

Users have also become increasingly aware of cookies being used to track behavior across multiple sites. You can express the intended scope of each cookie explicitly with the SameSite attribute. The promo_shown cookie should only work in a first-party context, while a session cookie for an embeddable widget is deliberately intended to deliver signed-in state to third-party contexts where the widget appears.

To set the correct attributes on your first-party cookies, refer to the guidance on first-party cookie recipes.