Cookie
The HTTP Cookie request header carries stored name-value pairs back to the server, enabling session persistence and state management across the stateless HTTP protocol.
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
Note
The cookie specification update
(draft-ietf-httpbis-rfc6265bis) revises cookie
handling with SameSite defaults,
__Host- and __Secure- prefixes, and the
Partitioned attribute for cookies in third-party
contexts. The draft is in active development.
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
SEO impact
Googlebot sends cookies when set by the origin but does not persist cookies across separate crawl sessions. Large cookies on asset domains increase request size during rendering. A cookieless domain for static assets avoids this overhead.