The Set-Cookie
HTTP response header is used to send cookies from the server to the user agent.
For more information, see the guide on HTTP cookies.
Header type | Response header |
---|---|
Forbidden header name | no |
Set-Cookie: <cookie-name>=<cookie-value> Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date> Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<non-zero-digit> Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value> Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value> Set-Cookie: <cookie-name>=<cookie-value>; Secure Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Lax // Multiple directives are also possible, for example: Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly
<cookie-name>=<cookie-value>
<cookie-name>
can be any US-ASCII characters except control characters (CTLs), spaces, or tabs. It also must not contain a separator character like the following: ( ) < > @ , ; : \ " / [ ] ? = { }.<cookie-value>
can optionally be set in double quotes and any US-ASCII characters excluding CTLs, whitespace, double quotes, comma, semicolon, and backslash are allowed. Encoding: Many implementations perform URL encoding on cookie values, however it is not required per the RFC specification. It does help satisfying the requirements about which characters are allowed for <cookie-value> though.__Secure-
: Cookies with a name starting with __Secure-
(dash is part of the prefix) must be set with the secure
flag and must be from a secure page (HTTPS).__Host-
: Cookies with a name starting with __Host-
must be set with the secure
flag, must be from a secure page (HTTPS), must not have a domain specified (and therefore aren't sent to subdomains) and the path must be "/".The maximum lifetime of the cookie as an HTTP-date timestamp. See Date
for the detailed format. If not specified, the cookie will have the lifetime of a session cookie. A session is finished when the client is shut down meaning that session cookies will get removed at that point. However, many web browsers have a feature called session restore that will save all your tabs and have them come back next time you use the browser. Cookies will also be present and it's like you had never actually closed the browser.
When an expiry date is set, the time and date set is relative to the client the cookie is being set on, not the server.
Expires
and Max-Age
) are set, Max-Age
will have precedence.Note: Insecure sites (http:
) can't set cookies with the "secure" directive anymore (new in Chrome 52+ and Firefox 52+).
Document.cookie
property, the XMLHttpRequest
and Request
APIs to mitigate attacks against cross-site scripting (XSS).Allows servers to assert that a cookie ought not to be sent along with cross-site requests, which provides some protection against cross-site request forgery attacks (CSRF).
Session cookies will get removed when the client is shut down. They don't specify the Expires
or Max-Age
directives. Note that web browser have often enabled session restoring.
Set-Cookie: sessionid=38afes7a8; HttpOnly; Path=/
Instead of expiring when the client is closed, permanent cookies expire at a specific date (Expires
) or after a specific length of time (Max-Age
).
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
A cookie belonging to a domain that does not include the origin server should be rejected by the user agent. The following cookie will be rejected if it was set by a server hosted on originalcompany.com.
Set-Cookie: qwerty=219ffwef9w0f; Domain=somecompany.co.uk; Path=/; Expires=Wed, 30 Aug 2019 00:00:00 GMT
Cookies names with the prefixes __Secure-
and __Host-
can be used only if they are set with the secure
directive from a secure (HTTPS) origin. In addition, cookies with the __Host-
prefix must have a path of "/" (the entire host) and must not have a domain attribute. For clients that don't implement cookie prefixes, you cannot count on having these additional assurances and the cookies will always be accepted.
// Both accepted when from a secure origin (HTTPS) Set-Cookie: __Secure-ID=123; Secure; Domain=example.com Set-Cookie: __Host-ID=123; Secure; Path=/ // Rejected due to missing Secure directive Set-Cookie: __Secure-id=1 // Rejected due to the missing Path=/ directive Set-Cookie: __Host-id=1; Secure // Rejected due to setting a domain Set-Cookie: __Host-id=1; Secure; Path=/; domain=example.com
Specification | Title |
---|---|
RFC 6265, section 4.1: Set-Cookie | HTTP State Management Mechanism |
RFC draft-ietf-httpbis-cookie-prefixes-00 | Cookie Prefixes |
RFC draft-ietf-httpbis-cookie-same-site-00 | Same-Site Cookies |
RFC draft-ietf-httpbis-cookie-alone-01 | Strict Secure Cookies |
Feature | Chrome | Edge | Firefox | Internet Explorer | Opera | Safari |
---|---|---|---|---|---|---|
Basic support | Yes | Yes | Yes | Yes | Yes | Yes |
Max-Age |
Yes | Yes | Yes | 8 | Yes | Yes |
HttpOnly |
1 | Yes | 3 | 9 | 11 | 5 |
Cookie prefixes | 49 | Yes | 50 | ? | 36 | Yes |
SameSite |
51 | No | No1 | No | 39 | No |
Feature | Android webview | Chrome for Android | Edge mobile | Firefox for Android | IE mobile | Opera Android | iOS Safari |
---|---|---|---|---|---|---|---|
Basic support | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
Max-Age |
Yes | Yes | Yes | Yes | Yes | Yes | Yes |
HttpOnly |
? | Yes | Yes | 4 | Yes | Yes | iOS 4 |
Cookie prefixes | ? | 49 | Yes | 50 | ? | 36 | Yes |
SameSite |
51 | 51 | No | No1 | No | 39 | No |
1. See bug 795346 on Bugzilla.
http:
) can't set cookies with the "secure" directive anymore.
© 2005–2018 Mozilla Developer Network and individual contributors.
Licensed under the Creative Commons Attribution-ShareAlike License v2.5 or later.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie