HTTP Headers

Set Cookie

HTTP Header

The HTTP Set-Cookie response header is used to send a cookie from the server to the user agent, enabling the user agent to send it back to the server in subsequent requests.
To transmit multiple cookies, the server should include multiple Set-Cookie headers in the same response.

Note: Modern browsers restrict access to the Set-Cookie header via JavaScript for security reasons. As specified by the Fetch standard, Set-Cookie is considered a forbidden response header name and is automatically filtered out from responses accessible to frontend code.
When making cross-origin requests with the Fetch API or XMLHttpRequest API, browsers will ignore Set-Cookie headers unless credentials are included.

For more detailed information, consult the guide on Using HTTP cookies.

Header type	Response header
Forbidden request header	No
Forbidden response header name	Yes

Syntax

 Set-Cookie: <cookie-name>=<cookie-value>
 Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>
 Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>
 Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly
 Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<number>
 Set-Cookie: <cookie-name>=<cookie-value>; Partitioned
 Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>
 Set-Cookie: <cookie-name>=<cookie-value>; Secure

 Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict
 Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Lax
 Set-Cookie: <cookie-name>=<cookie-value>; SameSite=None; Secure

 // Multiple attributes are also possible, for example:
 Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly

Directives

Attributes

Defines the cookie name and its value. A cookie definition begins with a name-value pair.

A <cookie-name> can contain any US-ASCII characters except for control characters (ASCII characters 0 up to 31 and ASCII character 127) or separator characters (space, tab and the characters: ( ) < > @ , ; : \ ” / [ ] ? = { }).

A <cookie-value> can optionally be wrapped in double quotes and include any US-ASCII character excluding control characters (ASCII characters 0 up to 31 and ASCII character 127), whitespace, double quotes, commas, semicolons, and backslashes.

Encoding: Many implementations perform percent-encoding on cookie values. However, this is not required by the RFC specification. The percent-encoding helps satisfy the characters allowed for <cookie-value>.

Note:

Some <cookie-name> have specific semantics:

__Secure- prefix: Cookies starting with __Secure- must be set with the secure flag from a secure page (HTTPS).

__Host- prefix: Cookies starting with __Host- are sent only to the host subdomain or domain that set them, not to any other host. They must be set with the secure flag, from a secure page (HTTPS), must not have a domain specified, and the path must be “/”.

Domain=<domain-value> Optional

Defines the host to which the cookie will be sent. Only the current domain or a higher-order domain (excluding public suffixes) can be set. Setting the domain makes the cookie available to the specified domain and its subdomains. If omitted, the default is the host of the current URL, excluding subdomains. Leading dots in domain names are ignored. Multiple host/domain values are not allowed; if a domain is specified, subdomains are always included.

Expires=<date> Optional

Indicates the maximum lifetime of the cookie as an HTTP-date timestamp. If not specified, the cookie is a session cookie that is removed when the client shuts down. The server sets this attribute, and browsers adjust for clock differences using a max-age or expiry value. The date must be formatted according to the RFC date formats.

Warning: Many browsers have session restore features that save and restore session cookies even after the browser is closed.

HttpOnly Optional

Prevents JavaScript from accessing the cookie via Document.cookie. However, cookies with HttpOnly are still included with JavaScript-initiated requests like XMLHttpRequest or fetch. This helps mitigate cross-site scripting (XSS) attacks.

Max-Age=<number> Optional

Specifies the number of seconds until the cookie expires. Zero or negative values expire the cookie immediately. If both Max-Age and Expires are set, Max-Age takes precedence.

Partitioned Optional

Indicates the cookie should be stored using partitioned storage. When set, the Secure attribute must also be present. For more details, see Cookies Having Independent Partitioned State (CHIPS).

Path=<path-value> Optional

Specifies the URL path that must exist in the request URL for the browser to send the cookie. The “/” character is a directory separator. For example, Path=/docs matches /docs, /docs/, /docs/Web/, and /docs/Web/HTTP, but not / or /docsets.

Note: The Path attribute controls which parts of a site the browser sends cookies for. It does not serve as a security measure against reading cookies from other paths.

SameSite=<samesite-value> Optional

Controls whether cookies are sent with cross-site requests, which helps prevent cross-site request forgery (CSRF). Possible values include:

Strict: Send cookies only for requests originating from the same site that set them.
Lax: Send cookies for same-site requests and certain cross-site requests such as top-level navigations or user-initiated actions like link clicks or form submissions, but not for unsafe methods like POST, PUT, or DELETE. Some browsers default to Lax if not specified, allowing POST requests set within two minutes of cookie creation.
None: Send cookies with all requests, including cross-site, but the Secure attribute must also be set.

Secure Optional

Ensures that cookies are only sent to the server over HTTPS connections, making them less vulnerable to man-in-the-middle attacks. Note that having the Secure attribute does not prevent JavaScript or disk access unless HttpOnly is also set. Insecure sites using HTTP cannot set cookies with the Secure attribute. When on localhost, the Secure attribute is ignored.

Examples

Session cookies are deleted when the client closes, with no Expires or Max-Age specified.

Example:

Set-Cookie: sessionId=38afes7a8

Permanent cookies persist beyond the session, with an explicit expiry date or Max-Age.

Examples:

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT
Set-Cookie: id=a3fWa; Max-Age=2592000

Cookies for a domain not including the server should be rejected.

Example:

Set-Cookie: qwerty=219ffwef9w0f; Domain=some-company.co.uk

Cookies for a subdomain of the serving domain are also rejected.

Example:

Set-Cookie: sessionId=e8bb43229de9; Domain=foo.example.com

Cookie names with __Secure- or __Host- prefixes can only be used if set with the secure attribute from a secure origin. The __Host- prefix requires a path of “/” and no Domain attribute. Cookies with these prefixes are accepted only from HTTPS origins, but some clients may ignore these restrictions.

Warning: For clients that do not support cookie prefixes, these additional guarantees are not enforced, and such cookies are always accepted.

Partitioned cookies must be set with the Secure attribute and optionally can use the __Host prefix for binding to hostname. Example:

Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;

How to Modify Header using Requestly

Requestly is a powerful Chrome extension that allows you to modify HTTP headers, including the Set-Cookie header. This is especially useful for testing how your application handles cookies during development or debugging. Steps to Modify the Set-Cookie Header:

Install and open the Requestly Chrome extension. You can find it on the Chrome Web Store.
Create a new rule: Click on “Create Rule” and choose “Modify Headers” from the list of available rule types.
Add a new header modification:
- Under “Action”, select “Add” or “Override”.
- In the “Header Name” field, enter Set-Cookie.
- In the “Header Value” field, enter the cookie string you want to set (e.g., sessionId=abc123; Path=/; HttpOnly).
Set the URL condition: Specify the URL or pattern where this header change should apply (e.g., https://your-api.com/*).
Save the rule.

With this setup, Requestly will inject or override the Set-Cookie header in all matching responses, allowing you to test cookie behavior such as authentication, session management, or feature flags on your server.

Sometimes, you need to modify the Set-Cookie header to test how your app responds to different cookie values or attributes without changing backend code. This helps ensure your site handles cookies securely and correctly under various scenarios.

Set Cookie

Syntax

Directives

Examples

How to Modify Header using Requestly

Level up your dev Game