Cookie

Usage

The Cookie header carries name-value pairs previously stored by the Set-Cookie response header. After a server sets a cookie, the browser includes the corresponding Cookie header in subsequent requests to the same domain, subject to path, domain, and expiration rules.

Cookies maintain state across the stateless HTTP protocol. Common uses include Session management, Authentication tokens, user preferences, and tracking identifiers. The server reads the Cookie header to identify the client, restore session context, or apply stored settings.

Multiple cookie pairs appear on a single Cookie header line, separated by semicolons and spaces. The syntax carries only the name and value of each cookie. Attributes like Expires, Path, Secure, and HttpOnly exist only in the Set-Cookie header and do not repeat in the Cookie header.

Cookie: name1=value1; name2=value2

Example

A server sets three cookies in a response. The sid cookie holds a session identifier, lang stores a language preference, and theme records a display setting.

HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: sid=abc123; Path=/; Secure; HttpOnly
Set-Cookie: lang=en; Path=/
Set-Cookie: theme=dark; Path=/

The browser includes all applicable cookies in the next request to the same domain. Only the name-value pairs travel in the Cookie header.

GET /dashboard HTTP/1.1
Host: example.re
Cookie: sid=abc123; lang=en; theme=dark

A POST request to a login endpoint receives a session cookie. The Secure attribute ensures the cookie only travels over HTTPS, and HttpOnly prevents JavaScript access.

HTTP/1.1 200 OK
Set-Cookie: token=eyJhbGciOi; Secure; HttpOnly; SameSite=Strict

Subsequent requests carry the token automatically.

GET /api/profile HTTP/1.1
Host: example.re
Cookie: token=eyJhbGciOi

SameSite enforcement

Browsers default to SameSite=Lax when no SameSite attribute is set. This blocks most cross-site cookie transmission by default. SameSite=None requires the Secure flag. Full SameSite reference