HTTP Cookie

High-level description of how cookies work. Source: Pixel Privacy, 2019.[(Pixel Privacy, 2019)]
High-level description of how cookies work. Source: Pixel Privacy, 2019.[(Pixel Privacy, 2019)]

HTTP cookies are small bits of information exchanged between client and server over the HTTP protocol. The server sets these cookies. The client receives and saves them locally. Subsequently, whenever the client makes a request to the server, it includes these cookies in the request. The server uses these cookies to provide the desired services.

Cookies are exchanged as simple strings in HTTP headers. Each cookie is a name-value pair. Cookies are scoped to the domain and web server path. Clients (formally called user agents) are typically web browsers. Often cookies are persistent even when browsers are closed.

Cookies bring efficiency and convenience to the web browsing experience. However, cookies have been misused to track users (privacy) or hack systems (security). These threats are being addressed by regulations and alternative technical solutions.


  • What's the problem that an HTTP cookie solves?
    HTTP cookie set during user login and subsequently used to manage the session. Source: Hsu 2018.
    HTTP cookie set during user login and subsequently used to manage the session. Source: Hsu 2018.

    HTTP protocol enables client-server communication on the web. HTTP itself is a stateless protocol. A server doesn't use information from previous requests to respond to the current request.

    However, many scenarios require the server to maintain some state information about the client. For example, a user logs into Gmail. Subsequently, she may read emails, compose a new mail, add attachments or change her mail settings. Each of these is one or more independent HTTP requests. Without state, the server would have to authenticate the user with each request. Instead, authentication is done once, cookies are set, and cookies are exchanged in subsequent requests to identify the authenticated user. In other words, cookies enable stateful communication on top of stateless HTTP.

    There are plenty of other examples where stateful communication is beneficial: adding items to a shopping cart on an e-commerce site, transferring money from one bank account to another, participating in an online Q&A forum, setting the language preference on a multilingual site, or searching where search engines use past queries to determine context.

  • What are the main uses of HTTP cookies?

    The way Google uses cookies gives us an insight into the different uses of cookies:

    • Preferences: Remember a user's language preference or region. For example, this can be used to serve local weather or traffic reports. Users can also personalize font, text size or colours.
    • Security: Used to authenticate users and protect user data from unauthorized access.
    • Processes: Used to make the site work properly for the user. This includes navigation or protected access of certain resources. For example, many documents can be opened in Google Docs in the same browser.
    • Advertising: Serve personalized ads to user. For example, recent Google searches may be used to personalize ads.
    • Session State: Used to learn how user uses the site, which pages are frequently visited, or measure effectiveness of affiliate advertising.
    • Analytics: Collect site statistics to learn how users interact with the site, without identifying users individually.

    Broadly, we can group cookies into three categories: session management (login, shopping carts, game scores), personalization (preferences, themes, settings), and tracking (recording and analyzing user behaviour).

  • What are the different types of cookies?

    In terms of validity, we can identify session cookies and permanent cookies. Session cookies are deleted once the browser is closed. Permanent cookies persist even when the browser is closed but can be set to expire after a specified datetime. Most permanent cookies persist for one or two years. Browser will delete them if user doesn't visit those sites before the cookies expire.

    In terms of domain, first-party cookies are cookies exchanged with the site currently being visited. Third-party cookies are cookies exchanged with another site that's different from the current site. This happens because the current site uses some content from the third-party site.

    While not exactly HTTP cookies, there are also Flash cookies. These may be exchanged by sites that use Flash plugins. They're often called "supercookies" since users can't easily delete them. Related to this are Zombie cookies that recreate automatically even if deleted. To make the web more secure, browsers will stop supporting Flash from end of 2020.

  • Could you explain first-party and third-party cookies?
    Illustrating first-party and third-party servers/cookies. Source: Matchett 2020.
    Illustrating first-party and third-party servers/cookies. Source: Matchett 2020.

    Suppose a user visits the site This server will respond with the content. The content may contain links to or load resources from another server. For example, might provide ad services for the content publisher at Thus, the user sees the site's content plus ads from the ad server.

    Cookies set by are called first-party cookies. Such cookies are often necessary for the correct working of the site or application. Users typically don't block these cookies.

    Cookies set by the third-party server are called third-party cookies. Third-party cookies can be misused since they can be used to track user behaviour across sites. For example, if the user visits another site that also uses the same third-party ad services, the ad service now knows that the user visited both the sites. Due to privacy concerns, some users block third-party cookies.

    Third-party cookies come from ad services, social media plugins, live chat popups, etc. In future, such cookies may become obsolete as newer technologies replace them.

  • What are some essentials on HTTP cookies?
    Basic use of Set-Cookie and Cookie headers. Source: Barth 2011a, sec. 3.1.[Barth 2011a, sec. 3.1]
    Basic use of Set-Cookie and Cookie headers. Source: Barth 2011a, sec. 3.1.[Barth 2011a, sec. 3.1]

    Server sets an HTTP cookie using Set-Cookie response header. A single response can set multiple cookies but a single Set-Cookie header can set only one cookie. A cookie is basically of the form name=value followed by zero or more attribute name-value pairs. Pairs are separated by a semi-colon and whitespace.

    When a client sends a request, applicable cookies are sent in Cookie header. All cookies are sent in a single Cookie header. Cookie name-value pairs are separated by a semi-colon and whitespace. Attribute name-value pairs are not part of the request. The order in which the cookies appear in the header should not be significant to the server.

    Attributes may contain only the name and no value. Two attributes of this nature are Secure and HttpOnly.

    At the client-side, clients shall ignore unrecognized attributes but not the entire cookie. When a client receives the same cookie as an already stored cookie (with same domain and path attributes), the new cookie shall replace the old one. At the server-side, semantics are application-specific.

  • Could you describe the different attributes of a cookie?

    Attribute names are recognized in a case-insensitive manner. These attributes can be optionally used for each HTTP cookie:

    • Expires: Cookie expires at the specified datetime. Servers can delete an existing cookie by specifying a past datetime.
    • Max-Age: Specifies in seconds when cookie expires relative to current time.
    • Domain: Cookie is applicable to the specified domain and its subdomains. For example, with, cookie will be sent with requests to both and If absent, cookie will be sent only to the origin server and not to subdomains.
    • Path: Specifies the applicable document path. For example, with Path=/dashboard, cookie will be sent for both /dashboard and /dashboard/today but not for /posts. For global cookie, use Path=/. If omitted, path defaults to current document location.
    • Secure: With this attribute, cookie is sent only over HTTPS connections.
    • HttpOnly: This makes the cookie inaccessible using document.cookie JavaScript API. Only the server can edit such a cookie.
    • SameSite: This mitigates the risk of Cross-Site Request Forgery (CSRF) attacks. With a suitable setting, client sends the cookie only to origin server and not to third-party servers.
  • Could you explain the SameSite attribute?
    Use of SameSite attribute prevents CSRF attacks. Source: Garcia 2018.
    Use of SameSite attribute prevents CSRF attacks. Source: Garcia 2018.

    SameSite cookie attribute can mitigate the risk of CSRF attacks. A typical CSRF attack is when you visit that then makes a cross-site request from your browser to your blog to modify or even delete blog posts.

    SameSite cookie attribute takes one of three values:

    • Strict: This is the most restrictive setting. Third-party cookies are ignored. While this is safe, it can also dampen user experience. For example, assume a user is already logged into a site User visits where she clicks a link leading to her blog. Since cookies are not sent, the login will not be recognized until the user refreshes the page on her blog in a first-party context.
    • Lax: This relaxes the restriction from Strict mode. When the user follows the link, the browser will include the cookies. Cookies are included only with GET requests.
    • None: This is the most open setting but Secure attribute is mandatory. Third-party cookies are allowed. This means that if were to request an image from, third-party cookies would be sent, which doesn't happen for Lax mode.
  • What are some shortcomings of HTTP cookies?

    Cookies can only contain simple strings. They're not suited to handle complex data structures. Each cookie has a size limit of 4KB. Cookies can be edited or deleted by users at the client side. Applications must be designed to handle this. Cookies are not encrypted, which means that they're not suited to handle sensitive information. Any encryption must be provided by the application. Cookies can also "leak" from one browser tab to the next, creating unintended effects on the application.

    Since cookies are sent with every request, this has a performance impact, especially on slow mobile network connections.

    Privacy concerns of cookies are well known. Third-party cookies are widely used by ad networks and social networking sites to track users and assemble extensive profile of users in terms of behaviour and preferences. Via social engineering, they can also be used to hack into user accounts, servers and bank accounts.

    Modern solutions to avoid using cookies include Web Storage API or IndexedDB for storage; JSON Web Tokens for token-based authentication; and Google's Privacy Sandbox or Storage Access API for cross-origin requests. Fingerprinting could be used for tracking users.

  • Which are the standards relevant to HTTP cookies?

    The main document is IETF's RFC 6265 titled HTTP State Management Mechanism. This defines what's a cookie and the Set-Cookie header fields. It describes server-side and client-side requirements. It also addresses implementation, privacy and security aspects.

    As on October 2020, RFC 6265bis was in draft form. It aims to update RFC 6265. Among its additions are cookie prefixes (__Secure- and __Host-) and SameSite attribute.

    The concept of origin is essential for cookies. Origin is defined in RFC 6454 titled The Web Origin Concept.

    Two relevant W3C Working Group Notes to look at are Tracking Preference Expression (DNT) and Tracking Compliance and Scope.


Cookie exchange between server and client. Source: Montulli 1995, fig. 4.

Netscape Communications Corp. files a US patent titled Persistent client state in a hypertext transfer protocol based client-server system. It describes, "… when a server responds to an http request by returning an HTTP object to a client, the server may also send a piece of state information that the client system will store. In an embodiment of the present invention, the state information is referred to as a 'cookie'."


Cookies are described in detail in an IETF document RFC 2109 titled HTTP State Management Mechanism. Subsequently, this RFC is superseded by RFC 6265 (April 2011).


The European Union passes ePrivacy Directive (EPD). This is amended in 2009 and again in 2017 at the direction of General Data Protection Regulation (GDPR). In time, EPD comes to be called the Cookie Law.


Federal Trade Commission orders Google to pay a penalty of $22.5 million for placing tracking cookies in Apple's Safari browser. This violated a privacy agreement between FTC and Google. These cookies were placed by Google's DoubleClick advertising network and bypassed Safari's default setting of blocking third-party cookies.


Details on SameSite cookies are published in an IETF draft that aims to update RFC 6265. This enables servers to assert that cookies should not be sent with cross-site requests. This mitigates the risk of cross-site request forgery (CSRF) attacks. This draft later becomes part of RFC 6265bis draft.


Version 00 of RFC 6265bis is published. Version 06 of this Internet-Draft is published in April 2020. When eventually approved, this would supersede RFC 6265.

Handling of third-party cookies due to ITP. Source: Wilander 2017.

Intelligent Tracking Prevention (ITP) is released as a new WebKit feature, where WebKit is the engine used in Safari web browser. ITP collects statistics about resource loads and user interactions. Via machine learning, it classifies if a domain is likely to do cross-site tracking. If so classified, it's cookies can't be used in third-party requests after 24 hours and are purged after 30 days. In March 2020, WebKit fully blocks third-party cookies. For cross-site integration, they propose Storage Access API as an alternative.


First approved in April 2016, General Data Protection Regulation (GDPR) comes into effect. Any cookie that can identify individuals is considered personal data. Such cookies require a user's explicit consent. Simply using the site doesn't imply consent. Site should provide user a means to withdraw consent. User consent must be stored. Sites must clarify the purpose of each cookie and the data it collects.


W3C publishes a working group note titled Tracking Preference Expression. Also called Do Not Track (DNT), this gives users a means to express their preference with regard to tracking. When enabled, it's sent as a separate header with content DNT:0 or DNT:1. If not enabled, servers can't assume users are saying yes to tracking. The earliest draft of this note can be traced to November 2011.


Due to the privacy concerns surrounding third-party cookies, Google proposes a new initiative called Privacy Sandbox. This is a designed to protect user privacy while keeping content accessible on the web. They note that simply blocking third-party cookies is not effective since fingerprinting can still be used to identify users across websites; and unlike cookies, fingerprints can't be cleared. Moreover, blocking cookies denies publishers funding via ad revenues. Google Chrome plans to phase out third-party cookies by 2022.


Google Chrome browser changes the default value for attribute SameSite from None to Lax. Cookies without the SameSite attribute will be treated as having SameSite=Lax. This restricts the use of third-party cookies in unsafe contexts. Mozilla brings a similar change to its Firefox browser in June (for some beta users only). In May 2019, this was proposed in an IETF draft titled Incrementally Better Cookies.


  1. Barth, A. 2011a. "HTTP State Management Mechanism." RFC 6265, Proposed Standard, IETF, April. Accessed 2020-10-09.
  2. Barth, A. 2011b. "The Web Origin Concept." RFC 6454, Proposed Standard, IETF, December. Accessed 2020-10-09.
  3. Barth, A. and M. West. 2016. "HTTP State Management Mechanism." draft-ietf-httpbis-rfc6265bis-00, Internet-Draft, IETF, October 10. Accessed 2020-10-09.
  4. Beaumont, Richard. 2011. "W3C Do Not Track Draft Standard and the Cookie Law." CookieLaw Blog, November 16. Accessed 2020-10-09.
  5. Beaumont, Richard. 2016. "GDPR Compliance Means Cookie Notices Must Change." CookieLaw Blog, November 3. Accessed 2020-10-09.
  6. Conca, Mike. 2020. "Changes to SameSite Cookie Behavior – A Call to Action for Web Developers." Mozilla Hacks, August 4. Accessed 2020-10-10.
  7. EDPS. 2020. "ePrivacy Directive." European Data Protection Supervisor. Accessed 2020-10-10.
  8. Fielding, Roy T., (ed). 2011. "Tracking Preference Expression (DNT)." W3C Working Draft, W3C, November 14. Accessed 2020-10-09.
  9. Fielding, Roy T., and David Singer, (eds). 2019. "Tracking Preference Expression (DNT)." W3C Working Group Note, W3C, January 17. Accessed 2020-10-09.
  10. Flavio Copes. 2018. "Learn how HTTP Cookies work." Flavio Copes, March 30. Accessed 2020-10-09.
  11. FTC. 2012. "Google Will Pay $22.5 Million to Settle FTC Charges it Misrepresented Privacy Assurances to Users of Apple's Safari Internet Browser." Press Release, FTC, August 9. Accessed 2020-10-10.
  12. Gagliardi, Valentino. 2020. "A practical, Complete Tutorial on HTTP cookies." Blog, June 3. Accessed 2020-10-09.
  13. Garcia, Romain. 2018. "Protect yourself from CSRF attacks with the SameSite cookie attribute." Blog, Vaadata, October 18. Accessed 2020-10-10.
  14. Google. 2020. "Types of cookies used by Google." Google. Accessed 2020-10-09.
  15. Hickson, Ian (ed). 2016. "Web Storage." Second Edition, W3C Recommendation, April 19. Accessed 2020-10-10.
  16. Hsu, Sherry. 2018. "Session vs Token Based Authentication." Medium, June 30. Accessed 2020-10-09.
  17. Kristol, D. and L. Montulli. 1997. "HTTP State Management Mechanism." RFC 2109, IETF, February. Accessed 2020-10-10.
  18. Laforge, Anthony. 2017. "Saying goodbye to Flash in Chrome." Blog, Google, July 25. Accessed 2020-10-09.
  19. MadMarTech. 2020. "First Party Cookie vs Third Party Cookie." MadMarTech, March 11. Accessed 2020-10-09.
  20. Matchett, Abigail. 2020. "Google Chrome & Third-Party Cookies - What You Need to Know." Bounteous, April 9. Accessed 2020-10-09.
  21. MDN Web Docs. 2020a. "Using HTTP cookies." MDN Web Docs, Mozilla, September 28. Accessed 2020-10-09.
  22. MDN Web Docs. 2020b. "SameSite cookies." MDN Web Docs, Mozilla, September 9. Accessed 2020-10-09.
  23. Merewood, Rowan. 2019. "SameSite cookies explained.", May 7. Updated 2020-05-28. Accessed 2020-10-09.
  24. Montulli, Lou. 1995. "Persistent client state in a hypertext transfer protocol based client-server system." US Patent US5774670A, October 6. Accessed 2020-10-10.
  25. Palmer, Danny. 2019. "What is GDPR? Everything you need to know about the new general data protection regulations." ZDNet, May 17. Accessed 2020-10-10.
  26. Pixel Privacy. 2019. "Browser Fingerprinting." Pixel Privacy, December 9. Accessed 2020-10-09.
  27. Porter, Lenora. 2020. "Chrome's Changes Could Break Your App: Prepare for SameSite Cookie Updates." Blog, Heroku, February 3. Accessed 2020-10-10.
  28. Price, Dan. 2018. "7 Types of Browser Cookies You Need to Know About." Make Use Of, December 19. Accessed 2020-10-09.
  29. Proton Technologies AG. 2020. "Cookies, the GDPR, and the ePrivacy Directive." GDPR.EU, Proton Technologies AG. Accessed 2020-10-10.
  30. Rocket Lawyer. 2020. "Different types of internet cookies." Rocket Lawyer. Accessed 2020-10-09.
  31. Schuh, Justin. 2019a. "Building a more private web." Blog, Google, August 22. Accessed 2020-10-09.
  32. Schuh, Justin. 2019b. "Potential uses for the Privacy Sandbox." Chromium Blog, August 22. Accessed 2020-10-09.
  33. Schuh, Justin. 2020. "Building a more private web: A path towards making third party cookies obsolete." Chromium Blog, January 14. Accessed 2020-10-09.
  34. Smedberg, Benjamin. 2017. "Firefox Roadmap for Flash End-of-Life." Blog, Mozilla, July 25. Accessed 2020-10-09.
  35. Soffar, Heba. 2017. "Cookies uses, features, advantages and disadvantages." Online Sciences, May 26. Updated 2019-09-11. Accessed 2020-10-10.
  36. West, M. 2019. "Incrementally Better Cookies." draft-west-cookie-incrementalism-00, Internet-Draft, IETF, May 7. Accessed 2020-10-10.
  37. West, M. and M. Goodwin. 2016. "Same-Site Cookies." draft-ietf-httpbis-cookie-same-site-00, Internet-Draft, IETF, June 20. Accessed 2020-10-09.
  38. West, M. and J. Wilander, (eds). 2020. "Cookies: HTTP State Management Mechanism." draft-ietf-httpbis-rfc6265bis-06, Internet-Draft, IETF, April 20. Accessed 2020-10-09.
  39. Wilander, John. 2017. "Intelligent Tracking Prevention." Blog, WebKit, June 5. Accessed 2020-10-10.
  40. Wilander, John. 2020. "Full Third-Party Cookie Blocking and More." Blog, WebKit, March 24. Accessed 2020-10-10.
  41. Wlosik, Michal, and Michael Sweeney. 2018. "What’s the Difference Between First-Party and Third-Party Cookies?" Blog, Clearcode, November 2. Updated 2020-02-15. Accessed 2020-10-09.
  42. Zakas, Nicholas C. 2009. "HTTP cookies explained." Blog, Human Who Codes, May 5. Accessed 2020-10-09.

Further Reading

  1. Flavio Copes. 2018. "Learn how HTTP Cookies work." Flavio Copes, March 30. Accessed 2020-10-09.
  2. Zakas, Nicholas C. 2009. "HTTP cookies explained." Blog, Human Who Codes, May 5. Accessed 2020-10-09.
  3. Gagliardi, Valentino. 2020. "A practical, Complete Tutorial on HTTP cookies." Blog, June 3. Accessed 2020-10-09.
  4. West, M. and J. Wilander, (eds). 2020. "Cookies: HTTP State Management Mechanism." draft-ietf-httpbis-rfc6265bis-06, Internet-Draft, IETF, April 20. Accessed 2020-10-09.
  5. Matchett, Abigail. 2020. "Google Chrome & Third-Party Cookies - What You Need to Know." Bounteous, April 9. Accessed 2020-10-09.
  6. UrRahman, Tariq. 2019. "Cookies, ITP and how it affects your privacy." The Startup, on Medium, June 29. Accessed 2020-10-09.

Article Stats

Author-wise Stats for Article Edits

No. of Edits
No. of Chats

Cite As

Devopedia. 2020. "HTTP Cookie." Version 4, October 11. Accessed 2020-11-25.
Contributed by
1 author

Last updated on
2020-10-11 17:33:16