sajad torkamani

A cookie is a small piece of data that a web server sends to a user’s browser. The browser typically stores the cookie and sends it in subsequent requests to the same server.

Cookies are typically used to persist stateful information between HTTP requests. HTTP is a stateless protocol which means that a web server has no way of knowing if two incoming requests are from the same user.

A common use of cookies is for a server to generate a unique identifier for a user session (e.g., PHPSESSIONID=783748378), send this to the browser, and have the browser store it and send it in every subsequent request.

In this way, each browser session has a unique identifier and the web server can store data against this identifier (e.g., to indicate whether a user has authenticated, to persist user settings, or to track user behavior).

Setting cookies

When a web server wants to give a user a cookie, it uses the Set-Cookie header in its response:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Set-Cookie: GUID=00a48b7f6a4946a8adf593373e53347c;
  ; path=/

Cookies can only be 4KB in size so they’re not suitable for storing lots of data. Cookies are usually used to store a unique identifier for a user or for simple flags (e.g., acceptedCookieConsent=true).

If cookie support is enabled in a browser (as is the default), the browser will automatically send any cookies to the server in every subsequent HTTP request:

GET ... HTTP/1.1
Cookie: GUID=00a48b7f6a4946a8adf593373e53347c;

A cookie’s lifetime will depend on whether it’s a session cookie or a permanent cookie.


Session cookies are deleted when the current browser session ends. When a current session ends may vary from browser. Some browsers also use session restoring when you reopen the browser (e.g., Chrome’s chrome://settings/onStartup-> On start-up -> Continue where you left off) which means session cookies can last forever.


Permanent cookies are deleted when at the date specified by the Expires attribute:

Set-Cookie: name=value; expires=Monday, 12-July-2023 21:12:00 GMT

Domain restriction

A user agent is smart enough to only send cookies to the web server that sets them in the first place. For example, it will send cookies set by only in outgoing requests to, and it will send cookies set by only on outgoing requests to

A web application can restrict the scope of a cookie to specific subdomains or paths.

HTTP/1.1 200 OK
Set-Cookie: name=value;; path=/foo

In the above example, cookies set by will be allowed to be sent to both and any subdomains such as or

If we omit, the domain attribute, then cookies can only be sent to and not any of its subdomains.

Path restriction

The path attribute can be used to restrict cookies to a specific URL path. In the above example, cookies will only be sent if the outgoing request URL points to /foo or a path inside /foo such as /foo/bar.

HttpOnly cookies

A HttpOnly cookie is not accessible from client-side JavaScript (via [Document.cookie]( A web server can make a cookie HttpOnly by passing it as an attribute to Set-Cookie:

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

Secure cookies

A cookie with the Secure flag is only sent to the server if the request is made over HTTPS. When used in conjunction with the HttpOnly attribute, this adds an extra layer of security by protecting against man-in-the-middle-attacks.


Tagged: HTTP