Typically, the server will use the contents of HTTP cookies to determine whether different requests come from the same browser/user and then issue a personalized or generic response as appropriate. The following describes a basic user sign-in system:

1. The user sends sign-in credentials to the server, for example via a form submission.
2. If the credentials are correct, the server updates the UI to indicate that the user is signed in, and responds with a cookie containing a session ID that records their sign-in status on the browser.
3. At a later time, the user moves to a different page on the same site. The browser sends the cookie containing the session ID along with the corresponding request to indicate that it still thinks the user is signed in.
4. The server checks the session ID and, if it is still valid, sends the user a personalized version of the new page. If it is not valid, the session ID is deleted and the user is shown a generic version of the page (or perhaps shown an "access denied" message and asked to sign in again).

Cookies are mainly used for three purposes:

• Session management: User sign-in status, shopping cart contents, game scores, or any other user session-related details that the server needs to remember.
• Personalization: User preferences such as display language and UI theme.
• Tracking: Recording and analyzing user behavior.

In the early days of the web when there was no other option, cookies were used for general client-side data storage purposes. Modern storage APIs are now recommended, for example theWeb Storage API (localStorage andsessionStorage) andIndexedDB.

They are designed with storage in mind, never send data to the server, and don't come with other drawbacks of using cookies for storage:

• Browsers are generally limited to a maximum number of cookies per domain (varies by browser, generally in the hundreds), and a maximum size per cookie (usually 4KB). Storage APIs can store larger amounts of data.
• Cookies are sent with every request, so they can worsen performance (for example on slow mobile data connections), especially if you have a lot of cookies set.

After receiving an HTTP request, a server can send one or moreSet-Cookie headers with the response, each one of which will set a separate cookie. A cookie is set by specifying a name-value pair like this:

Set-Cookie: <cookie-name>=<cookie-value>

The following HTTP response instructs the receiving browser to store a pair of cookies:

HTTP/2.0 200 OKContent-Type: text/htmlSet-Cookie: yummy_cookie=chocolateSet-Cookie: tasty_cookie=strawberry[page content]

When a new request is made, the browser usually sends previously stored cookies for the current domain back to the server within aCookie HTTP header:

GET /sample_page.html HTTP/2.0Host: www.example.orgCookie: yummy_cookie=chocolate; tasty_cookie=strawberry

You can specify an expiration date or time period after which the cookie should be deleted and no longer sent. Depending on the attributes set within theSet-Cookie header when the cookies are created, they can be eitherpermanent orsession cookies:

• Permanent cookies are deleted after the date specified in theExpires attribute:

  http

  Set-Cookie: id=a3fWa; Expires=Thu, 31 Oct 2021 07:28:00 GMT;

  or after the period specified in theMax-Age attribute:

  http

  Set-Cookie: id=a3fWa; Max-Age=2592000

  Note:Expires has been available for longer thanMax-Age, howeverMax-Age is less error-prone, and takes precedence when both are set. The rationale behind this is that when you set anExpires date and time, they're relative to the client the cookie is being set on. If the server is set to a different time, this could cause errors.

• Session cookies — cookies without aMax-Age orExpires attribute – are deleted when the current session ends. The browser defines when the "current session" ends, and some browsers usesession restoring when restarting. This can cause session cookies to last indefinitely.

  Note:If your site authenticates users, it should regenerate and resend session cookies, even ones that already exist, whenever a user authenticates. This approach helps preventsession fixation attacks, where a third-party can reuse a user's session.

There are some techniques designed to recreate cookies after they're deleted. These are known as "zombie" cookies. These techniques violate the principles of userprivacy and control, may violatedata privacy regulations, and could expose a website using them to legal liability.

To update a cookie via HTTP, the server can send aSet-Cookie header with the existing cookie's name and a new value. For example:

Set-Cookie: id=new-value

There are several reasons why you might want to do this, for example if a user has updated their preferences and the application wants to reflect the changes in client-side data (you could also do this with a client-side storage mechanism such asWeb Storage).

Updating cookies via JavaScript

In the browser, you can create new cookies via JavaScript using theDocument.cookie property, or the asynchronousCookie Store API. Note that all examples below useDocument.cookie, as it is the most widely supported/established option.

document.cookie = "yummy_cookie=chocolate";document.cookie = "tasty_cookie=strawberry";

You can also access existing cookies and set new values for them, provided theHttpOnly attribute isn't set on them (i.e., in theSet-Cookie header that created it):

console.log(document.cookie);// logs "yummy_cookie=chocolate; tasty_cookie=strawberry"document.cookie = "yummy_cookie=blueberry";console.log(document.cookie);// logs "tasty_cookie=strawberry; yummy_cookie=blueberry"

Note that, for security purposes, you can't change cookie values by sending an updatedCookie header directly when initiating a request, i.e., viafetch() orXMLHttpRequest. Note that there are also good reasons why you shouldn't allow JavaScript to modify cookies — i.e., setHttpOnly during creation. See theSecurity section for more details.

When you store information in cookies, by default all cookie values are visible to, and can be changed by, the end user. You really don't want your cookies to be misused — for example accessed/modified by bad actors, or sent to domains where they shouldn't be sent. The potential consequences can range from annoying — apps not working or exhibiting strange behavior — to catastrophic. A criminal could for example steal a session ID and use it to set a cookie that makes it look like they are logged in as someone else, taking control of their bank or e-commerce account in the process.

You can secure your cookies in a variety of ways, which are reviewed in this section.

You can ensure that cookies are sent securely and aren't accessed by unintended parties or scripts in one of two ways: with theSecure attribute and theHttpOnly attribute:

Set-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly

• A cookie with theSecure attribute is only sent to the server with an encrypted request over the HTTPS protocol. It's never sent with unsecured HTTP (except on localhost), which meansman-in-the-middle attackers can't access it easily. Insecure sites (withhttp: in the URL) can't set cookies with theSecure attribute. However, don't assume thatSecure prevents all access to sensitive information in cookies. For example, someone with access to the client's hard disk (or JavaScript if theHttpOnly attribute isn't set) can read and modify the information.

• A cookie with theHttpOnly attribute can't be accessed by JavaScript, for example usingDocument.cookie; it can only be accessed when it reaches the server. Cookies that persist user sessions for example should have theHttpOnly attribute set — it would be really insecure to make them available to JavaScript. This precaution helps mitigate cross-site scripting (XSS) attacks.

TheDomain andPath attributes define thescope of a cookie: what URLs the cookies are sent to.

• TheDomain attribute specifies which server can receive a cookie. If specified, cookies are available on the specified server and its subdomains. For example, if you setDomain=mozilla.org frommozilla.org, cookies are available on that domain and subdomains likedeveloper.mozilla.org.

  http

  Set-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly; Domain=mozilla.org

  If theSet-Cookie header does not specify aDomain attribute, the cookies are available on the server that sets itbut not on its subdomains. Therefore, specifyingDomain is less restrictive than omitting it.Note that a server can only set theDomain attribute to its own domain or a parent domain, not to a subdomain or some other domain.So, for example, a server with domainfoo.example.com could set the attribute toexample.com orfoo.example.com, but notbar.foo.example.com orelsewhere.com (the cookies would still besent to subdomains such asbar.foo.example.com though).SeeInvalid domains for more details.

• ThePath attribute indicates a URL path that must exist in the requested URL in order to send theCookie header. For example:

  http

  Set-Cookie: id=a3fWa; Expires=Thu, 21 Oct 2021 07:28:00 GMT; Secure; HttpOnly; Path=/docs

  The%x2F ("/") character is considered a directory separator, and subdirectories match as well. For example, if you setPath=/docs, these request paths match:

  • /docs
  • /docs/
  • /docs/Web/
  • /docs/Web/HTTP

  But these request paths don't:

  • /
  • /docsets
  • /fr/docs

  Note:Thepath attribute lets you control what cookies the browser sends based on the different parts of a site.It is not intended as a security measure, anddoes not protect against unauthorized reading of the cookie from a different path.

TheSameSite attribute lets servers specify whether/when cookies are sent with cross-site requests — i.e.,third-party cookies. Cross-site requests are requests where thesite (the registrable domain) and/or the scheme (http or https) do not match the site the user is currently visiting. This includes requests sent when links are clicked on other sites to navigate to your site, and any request sent by embedded third-party content.

SameSite helps to prevent leakage of information, preserving userprivacy and providing some protection againstcross-site request forgery attacks. It takes three possible values:Strict,Lax, andNone:

• Strict causes the browser to only send the cookie in response to requests originating from the cookie's origin site. This should be used when you have cookies relating to functionality that will always be behind an initial navigation, such as authentication or storing shopping cart information.

  http

  Set-Cookie: cart=110045_77895_53420; SameSite=Strict

  Note:Cookies that are used for sensitive information should also have a shortlifetime.

• Lax is similar, except the browser also sends the cookie when the usernavigates to the cookie's origin site (even if the user is coming from a different site). This is useful for cookies affecting the display of a site — for example you might have partner product information along with an affiliate link on your website. When that link is followed to the partner website, they might want to set a cookie stating that the affiliate link was followed, which displays a reward banner and provides a discount if the product is purchased.

  http

  Set-Cookie: affiliate=e4rt45dw; SameSite=Lax

• None specifies that cookies are sent on both originating and cross-site requests. This is useful if you want to send cookies along with requests made from third-party content embedded in other sites, for example, ad-tech or analytics providers. Note that ifSameSite=None is set then theSecure attribute must also be set —SameSite=None requires asecure context.

  http

  Set-Cookie: widget_session=7yjgj57e4n3d; SameSite=None; Secure; HttpOnly

If noSameSite attribute is set, the cookie is treated asLax by default.

Because of the design of the cookie mechanism, a server can't confirm that a cookie was set from a secure origin or even tellwhere a cookie was originally set.

An application on a subdomain can set a cookie with theDomain attribute, which gives access to that cookie on all other subdomains. This mechanism can be abused in asession fixation attack.

As adefense-in-depth measure, however, you can usecookie prefixes to assert specific facts about the cookie. Two prefixes are available:

• __Host-: If a cookie name has this prefix, it's accepted in aSet-Cookie header only if it's also marked with theSecure attribute, was sent from a secure origin, doesnot include aDomain attribute, and has thePath attribute set to/. In other words, the cookie isdomain-locked.
• __Secure-: If a cookie name has this prefix, it's accepted in aSet-Cookie header only if it's marked with theSecure attribute and was sent from a secure origin. This is weaker than the__Host- prefix.

The browser will reject cookies with these prefixes that don't comply with their restrictions. This ensures that subdomain-created cookies with prefixes are either confined to a subdomain or ignored completely. As the application server only checks for a specific cookie name when determining if the user is authenticated or a CSRF token is correct, this effectively acts as a defense measure againstsession fixation.

For more information about cookie prefixes and the current state of browser support, see thePrefixes section of the Set-Cookie reference article.

Earlier on we talked about how theSameSite attribute can be used to control when third-party cookies are sent, and that this can help preserve user privacy. Privacy is a very important consideration when building websites which, when done right, can build trust with your users. If done badly, it can completely erode that trust and cause all kinds of other problems.

Third-party cookies can be set by third-party content embedded in sites via<iframe>s. They have many legitimate uses include sharing user profile information, counting ad impressions, or collecting analytics across different related domains.

However, third-party cookies can also be used to create creepy, invasive user experiences. A third-party server can create a profile of a user's browsing history and habits based on cookies sent to it by the same browser when accessing multiple sites. The classic example is when you search for product information on one site and are then chased around the web by adverts for similar products wherever you go.

Browser vendors know that users don't like this behavior, and as a result have all started to block third-party cookies by default, or at least made plans to go in that direction. Third-party cookies (or just tracking cookies) may also be blocked by other browser settings or extensions.

See ourThird-party cookies article for detailed information on third-party cookies, the issues associated with them, and what alternatives are available. See ourPrivacy landing page for more information on privacy in general.

Legislation or regulations that cover the use of cookies include:

• TheGeneral Data Privacy Regulation (GDPR) in the European Union
• The ePrivacy Directive in the EU
• The California Consumer Privacy Act

These regulations have global reach. They apply to any site on theWorld Wide Web that users from these jurisdictions access (the EU and California, with the caveat that California's law applies only to entities with gross revenue over 25 million USD, among things).

These regulations include requirements such as:

• Notifying users that your site uses cookies.
• Allowing users to opt out of receiving some or all cookies.
• Allowing users to use the bulk of your service without receiving cookies.

There may be other regulations that govern the use of cookies in your locality. The burden is on you to know and comply with these regulations. There are companies that offer "cookie banner" code that helps you comply with these regulations.

• Related HTTP headers:Set-Cookie,Cookie
• Related JavaScript APIs:Document.cookie,Navigator.cookieEnabled,Cookie Store API
• Third-party cookies
• Cookie specification: RFC 6265
• Cookies, the GDPR, and the ePrivacy Directive