Cookie attributes

When a web server responds to a request for a resource, the server can include a Set-Cookie header along with its response. That header tells your browser to store a cookie. For example: Set-Cookie:cat=tabby. What are cookies? explains how cookies work.

In addition to providing a cookie name and value, Set-Cookie can include attributes to control if cookies are set, and when they expire. Cookie attributes are separated by semicolons. For example:

    Set-Cookie:cat=tabby; Secure; HTTPOnly; Expires=Tue, 31 Dec 2999 23:59:59 GMT;

This document explains the most important cookie attributes:

Using HTTP cookies explains cookie attributes in more technical detail.

Secure

If a Set-Cookie header includes Secure, the cookie will only be included with encrypted requests that use the HTTPS protocol: the cookie won't be included in HTTP requests. This can help stop intermediary attacks, where an attacker secretly intervenes in communications between the browser and the server — to pass on information, and potentially alter it.

HTTPOnly

If a Set-Cookie header includes HTTPOnly, JavaScript cannot access the cookie, for example by using document.cookie. This helps protect against certain types of attacks that target cookies.

SameSite

A request for a resource from a site that's different from the site you're visiting is a cross-site request. A cookie set in response to a cross-site request is a third-party cookie.

The SameSite attribute controls whether a third-party cookie will be included in a request. It has three possible values: Strict, Lax, or None.

Find out more: What are third-party cookies?

Strict

The cookie will only be sent in response to requests from a page that's on the cookie's origin site. For example: imagine a user visits cats.example and has a cookie set with the attribute SameSite=Strict. Later on, the user is on a different site, and they follow a link to a page on cats.example. The cookie that was set won't be included in that request.

Lax

This works the same way as Strict, except that the browser will also include the cookie when the user follows a link to the cookie's origin site. (In the previous Strict example, the cookie would be included when the user follows the link to cats.example.) Lax is the default, if no SameSite attribute is included in a Set-Cookie header.

None

No constraints: the cookie will be included with a request, whether or not it's cross-site. With SameSite=None, the cookie must also have the Secure attribute.

Partitioned

This attribute lets you opt in a cookie to partitioned storage, with a separate "cookie jar" per top-level site. The cookie is double-keyed, by the top-level site as well as the domain that sets it.

For example: imagine that website A and website B both include an iframe from website C. A partitioned cookie set by the iframe on website A cannot be accessed by the iframe on website B: the AC cookie is separate from the BC cookie.

Diagram showing that two different web sites embedding a common third-party will no longer share cookies for that third-party.
With cookie partitioning, a third-party service that sets a cookie when embedded in one top-level site cannot access that same cookie when the service is embedded in other top-level sites.

Cookies with a Partitioned attribute are known as CHIPS: Cookies Having Independent Partitioned State.

Partitioned cookies must have the Secure attribute.

Find out more: Cookies Having Independent Partitioned State.

Expires and Max-Age

You can specify an Expires date and time, or a Max-Age in seconds, after which a cookie should be deleted and no longer sent. For example:

  • Set-Cookie:cat=tabby; Expires=Tue, 31 Dec 2999 23:59:59 GMT;
  • Set-Cookie:cat=tabby; Max-Age=86400

If you don't specify a Max-Age or Expires attribute, a cookie will be deleted when the current session ends. This kind of cookie is sometimes known as a session cookie.

Domain

If a Set-Cookie header has a Domain attribute, the cookie will be included with requests to the domain specified, and any of its subdomains.

If a Set-Cookie header doesn't have a Domain attribute, the cookie won't be included with requests to subdomains.

In other words, including the Domain attribute reduces domain restrictions.

For example, with a response from the website cats.example:

  • Set-Cookie:cat=tabby
    The cookie will only be included with requests to cats.example
  • Set-Cookie:cat=tabby; Domain=cats.example
    The cookie will be included with requests to cats.example, and also any requests for resources on subdomains such as fluffy.cats.example or user.assets.cats.example

Path

If a Path attribute is included in a Set-Cookie response header, the cookie that's set will only be included in requests to URLs (on the site that set the cookie!) which match the Path value.

For example:

  • Set-Cookie:cat=tabby; Path=/articles
    The cookie will be included for a request to any URL path that begins with /articles:
    ✅ https://cats.example/articles/tabby/index.html
    ✅ https://cats.example/articles/breeds/tabby/index.html
    ❎ https://cats.example/images/tabby.jpg
    ❎ https://cats.example/en/articles/tabby/index.html
  • Set-Cookie:cat=tabby; Path=/
    All requests to any URL on the site will include the cookie.

If a Set-Cookie response header doesn't have a Path value, the cookie will only be included with requests to the same directory. For example, imagine that a cat=tabby cookie is set in response to a request for cats.example/images/tabby.jpg. If no Path is set, the cookie will only be included with requests for files within the cats.example/images directory.

Demos

Tools

Find out more