Browser cookies are still the most commonly used method for tracking the session state of websites and the identity of visitors. Sánchez-Rola et al. [1Sanchez-Rola, Iskander; Dell'Amico, Matteo; Kotzias, Platon; Balzarotti, Davide; Bilge, Leyla; Vervier, Pierre-Antoine; Santos, Igor (2019): "Can I Opt Out Yet? GDPR and the Global Illusion of Cookie Control", pp. 340–351. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)] found cookies capable of identifying a user on more than 90% of the websites they visited, often without those users' knowledge.¹⁾ While other stateless tracking technologies, such as Fingerprinting or Link decorators, exist, cookies remain the primary choice, with stateless methods typically used in combination with cookies. This trend persists, and third-party cookies were in the end not discontinued: on 22 April 2025 Google announced it would “maintain our current approach to offering users third-party cookie choice in Chrome, and will not be rolling out a new standalone prompt for third-party cookies”.²⁾ They remain allowed by default in Chrome, blocked in its Incognito mode, and partitioned per top-level site by default in Firefox and Safari — so what a measurement observes depends on which browser it drove and in which mode; see Since 2022 the engine decides, not you.

This page is about deciding what a cookie you have already recorded is for. That is a labelling problem with a specific and unusual property: there is no ground truth. Nobody can read a cookie value and know that it carries an advertising identifier; every label on this page comes from someone's declaration, someone's list, or someone's model, and the interesting methodological questions are all about which of those you chose and how much of your data it could label at all.

• Automating Cookie Consent and GDPR Violation Detection [4Bollinger, Dino; Kubicek, Karel; Cotrini, Carlos; Basin, David (2022): "Automating Cookie Consent and GDPR Violation Detection", in: 31st USENIX Security Symposium (USENIX Security 22), pp. 2893-2910. USENIX Association, Boston, MA. (Link)], USENIX Security 2022 — the reference point for purpose classification. It builds the ground truth (2.2M cookies declared by website operators through their CMPs), trains a classifier on it, and measures Cookiepedia against the same labels. Read §4 for the evaluation and Table 3 for the number most papers forget to report: Cookiepedia's cookie coverage of 79.2%.
• CookieGraph: Understanding and Detecting First-Party Tracking Cookies [5Munir, Shaoor; Siby, Sandra; Iqbal, Umar; Englehardt, Steven; Shafiq, Zubair; Troncoso, Carmela (2023): "CookieGraph: Understanding and Detecting First-Party Tracking Cookies", pp. 3490–3504. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)], CCS 2023 — the graph-feature successor, and the paper that made first-party tracking cookies a measurable category. Its released artifact is also the easiest way to see how thin name-based labelling is in practice (see Coverage is the number you have to report).
• Semantics-Aware Cookie Purpose Compliance [6Chen, Baiqi; Lyu, Jiawei; Wu, Tingmin; Chhetri, Mohan Baruwal; Bai, Guangdong (2025): "Semantics-Aware Cookie Purpose Compliance", in: Proceedings of the ACM Web Conference. (DOI)], TheWebConf 2025 — the only peer-reviewed LLM cookie classifier in these seven venues. Read it for the design (segment the value, then interpret the segments) rather than for the F1.
• Crumbling Cookie Categories [7Jiwani, Soha; Sasheendran, Rachna; Abhyankar, Adhishree; Bouma-Sims, Elijah; Cranor, Lorrie (2024): "Crumbling Cookie Categories: Deconstructing Common Cookie Categories to Create Categories that People Understand", Proceedings on Privacy Enhancing Technologies . (DOI)], PoPETs 2024 — the categories you are classifying into are not understood by the people they exist for. 7% of participants correctly identified the standard definition of a “functional” cookie, and 24% that of a “performance” cookie.
• Journey to the Center of the Cookie Ecosystem [8Sánchez-Rola, Iskander; Dell'Amico, Matteo; Balzarotti, Davide; Vervier, Pierre-Antoine; Bilge, Leyla (2021): "Journey to the Center of the Cookie Ecosystem: Unraveling Actors' Roles and Relationships", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)], IEEE S&P 2022 — the largest identifier-classification run in the corpus (137,997,677 cookies over 6.2M pages, 48% classed as identifiers) and the paper that moved the field from length-and-expiry thresholds to an entropy test.
• Then, for the mechanics your classifier sits on top of: Browser storage for what your crawler actually captured, and Cookie syncing for what happens to an identifier after you have found it.

Cookies touch six pages on this wiki, and the boundaries are drawn by what you are doing with the cookie, not by the mechanism. This page is deliberately narrow.

Two consequences worth stating, because both were live judgement calls when this page was rewritten. Identifier detection is documented on The Identifier Heuristic Is the Measurement, not here — it is the same heuristic whether you are looking for a sync or counting ID cookies, and duplicating the table would guarantee the two copies drift. This page says which of the 53 papers do it and how the family has moved; the heuristics themselves are one click away. And the platform history — the third-party-cookie deprecation, its reversal, CHIPS, partitioning — lives on Privacy sandbox; this page carries only the one sentence above, because a measurement that classifies cookies has to know that the population of cookies is browser-conditional and does not need the roadmap.

First-party cookies are set by the domain the user is directly visiting, while all other cookies are considered third-party cookies. Although third-party cookies are significantly more used for tracking than first-party cookies, it is wrong to claim that first-party cookies are always benign and third-party cookies are always intrusive. First-party cookies can also track users or even be set by third parties using CNAME cloaking and there are many third-party cookies serving necessary functionality such as SSO.

The only difference is from the browser perspective. First-party cookies are accessible only from the first-party website's context, while third-party cookies are accessible across multiple websites that embed the same third party. But this implementation depends on the browser, with Safari and Firefox setting the storage for third parties for every website separately.

Munir et al. [5Munir, Shaoor; Siby, Sandra; Iqbal, Umar; Englehardt, Steven; Shafiq, Zubair; Troncoso, Carmela (2023): "CookieGraph: Understanding and Detecting First-Party Tracking Cookies", pp. 3490–3504. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)] observed that 89.86% of the top-million websites use first-party tracking cookies. Of these, 96.61% are ghostwritten by third-party scripts embedded in the first-party context, and some are set by fingerprinting scripts. Kancherla et al. [9Kancherla, Gayatri Priyadarsini; Goel, Dishank; Bichhawat, Abhishek (2025): "Least Privilege Access for Persistent Storage Mechanisms in Web Browsers", in: Proceedings of the ACM Web Conference. (DOI)] measured the same relationship from the access side rather than the setting side and found that 89.84% of all cookie accesses on the Tranco top 10,000 are performed by third-party JavaScript — a share, not a volume, and one that is nearly identical for localStorage (90.98%) and not far off for IndexedDB (72.49%).

The practical consequence for a classifier is that the party of a cookie is a property of the observation, not of the cookie: the same name and value can be first-party on one site and third-party on another, and only 2 of the 53 cookie-classifying papers in the corpus state a rule for deciding it at all (one uses the Public Suffix List, one compares host domains). If your classifier takes the party as a feature — CookieBlock and CookieGraph both do — say which eTLD list you used and at which version.

Before choosing a method, decide which of these you are answering. The paper-counts are over the 53 corpus papers that classify a cookie; a paper answering two questions is in two rows.

The rows are not interchangeable and the errors do not compose. A purpose label is only as good as the operator declaration behind it, and operators are wrong: [4Bollinger, Dino; Kubicek, Karel; Cotrini, Carlos; Basin, David (2022): "Automating Cookie Consent and GDPR Violation Detection", in: 31st USENIX Security Symposium (USENIX Security 22), pp. 2893-2910. USENIX Association, Boston, MA. (Link)] found that 36.4% of the 29,398 websites it examined had at least one cookie with an incorrectly assigned purpose, and 85.8% had at least one cookie with a missing declaration or missing purpose. A tracking label inherits every judgement in a filter list, including the ones the list makes for breakage reasons rather than privacy reasons — see Ground truth, and the circularity. An identifier label is a predicate you wrote yourself, so it is exactly as defensible as the paragraph in which you describe it.

Law³⁾ recognizes only two categories of cookies: those strictly necessary for the service and others. The industry, however, has developed various categorization schemes:

• Cookie guide by UK’s International Chamber of Commerce (ICC UK) from 2012 is the most widely adopted scheme, with the following four categories:⁴⁾
  • Strictly-necessary cookies:
    • Required to enable essential functions of the website, such as registration or shopping carts. They are always enabled to allow for a smooth and problem-free browsing experience.
  • Functionality cookies:
    • Enable non-essential convenience or usability features of a website, such as saving style preferences between visits. However, this may also include a minor number of tracking cookies. We recommend enabling these cookies to improve the user experience.
  • Analytics cookies:
    • Used to collect statistical information about how visitors use a website. This information is often used to measure the performance and guide the development of a website, but can include sensitive data and allow user tracking. Disable these if you are concerned over potential trackers from analytics services.
  • Advertising/tracking cookies:
    • Used to tailor advertisements to the viewer, help track the user and collect sensitive data of the user's browsing behavior, usually across multiple websites. Said data is then also often sold to third parties. We recommend rejecting these types of cookies to protect your privacy.
• The IAB Europe TCF purposes, used by CMPs implementing the TCF. The count has moved and older papers will say 12: as of 2026-09-10 the live policy defines 11 purposes plus 3 special purposes (plus 3 features and 2 special features). TCF v2.2 added Purpose 11 and Special Purpose 3 was added later; the 2021 snapshot a lot of the literature cites has 10 purposes and 2 special purposes. Cite the version, not the number. See TCF consent strings.

The ICC scheme is the field's default and it is not stated as such. Of the 29 corpus papers that name any category scheme on a cookie tuple, 11 (37.9%) use the ICC four — but only 8 name the ICC or the International Chamber of Commerce; the other three simply write the four categories out. Counted by exact string the largest group is two papers. The fold and every contributing string are on cookies.

* 2025–2026 is a provisional bucket; see the box above. The columns count papers, and a paper using two families is counted in both, so the columns do not sum to the denominator row.

Each of these rests on a named, dated source that supersedes the thing it retires, not on a corpus count.

• A fixed length window, or a long expiry, as the identifier test. These were the standard predicates from 2014 to about 2021 and they are weak now. The replacement is an entropy or guessability test on the value: zxcvbn guesses ≥ 10^9 is the criterion used by [1Sanchez-Rola, Iskander; Dell'Amico, Matteo; Kotzias, Platon; Balzarotti, Davide; Bilge, Leyla; Vervier, Pierre-Antoine; Santos, Igor (2019): "Can I Opt Out Yet? GDPR and the Global Illusion of Cookie Control", pp. 340–351. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)] and [8Sánchez-Rola, Iskander; Dell'Amico, Matteo; Balzarotti, Davide; Vervier, Pierre-Antoine; Bilge, Leyla (2021): "Journey to the Center of the Cookie Ecosystem: Unraveling Actors' Roles and Relationships", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)], adopted by [12Calzavara, Stefano; Casarin, Samuele; Squarcina, Marco; Maffei, Matteo (2026): "From Syntactic Matching to Taint Tracking and Back: A Comparative Study of Web Tracking Detection Techniques", in: Proceedings on Privacy Enhancing Technologies. (Link)], and used by [13Tang, Brian; Bui, Duc; Shin, Kang G. (2025): "Navigating Cookie Consent Violations Across the Globe", in: Proceedings of the USENIX Security Symposium. (Link)] in 2025 to find tracking UIDs. Note how thin the corpus evidence for the name is, and that this is a case where the mechanism has spread further than the library: exactly 2 of the 5,869 readable papers mention zxcvbn within 150 characters of the word “cookie”, while 35 mention entropy in the same window. The full argument, with the ten-heuristic comparison table, is on The Identifier Heuristic Is the Measurement — do not write a new one without reading it.
• Installing the CookieBlock extension into a Chrome crawler. This was the recipe on this page until September 2026 and it no longer works. CookieBlock is a Manifest V2 extension⁵⁾ and Chrome disabled Manifest V2 everywhere with Chrome 138 on 24 July 2025, removing support entirely in Chrome 139.⁶⁾ The Chrome Web Store listing now returns “This item is not available”.⁷⁾ Use the Firefox add-on or the offline classifier instead — see CookieBlock.
• Treating “the cookie has a purpose label” and “the cookie was in the database” as the same event. Every purpose-database paper before about 2022 reports a category distribution without reporting how many cookies got no category at all. That is not a rounding error: see the next section.
• “Third-party cookies are about to disappear, so cookie classification is about to stop mattering.” They are not, and it does not. The framing that holds is “Chrome keeps them, Safari and Firefox do not”, which makes every prevalence figure on this page browser-conditional. The detail is on Privacy sandbox.

The single most under-reported quantity in cookie purpose classification is what fraction of your cookies got a label at all. A database lookup that answers for 40% of your cookies and a classifier that answers for 100% of them are not comparable no matter what their accuracies are, and the category distribution you publish is a distribution over the part that answered.

Four independent measurements, four different populations, all of them published:

The last row is a vendor figure and the fourth is reproducible in one command:

curl -sL 'https://raw.githubusercontent.com/cookiegraph/CookieGraph/main/Feature%20Extraction%20and%20Classifier/code/labelling_scripts/cookies_categories_updated.csv' \
  | python3 -c "import csv,sys,collections; r=csv.reader(sys.stdin); next(r); c=collections.Counter(x[2] for x in r); n=sum(c.values()); [print(f'{v:8d} {100*v/n:5.1f}%  {k}') for k,v in c.most_common()]"

The script that produces this table with its denominators is ''cookiepedia_coverage.py''.

Using datasets of cookies or online classification services has significant disadvantages: they cannot classify unseen data or assign one cookie multiple classes based on dynamic content. However, they offer advantages over ML methods, such as post-crawl classification of detected cookies — which is why they are the largest family in the table above.

Many websites label cookies in their consent notices or privacy policies. Some CMPs unify the display of cookie lists, which enables large-scale scraping of these labels. Bollinger and Kubicek et al. [4Bollinger, Dino; Kubicek, Karel; Cotrini, Carlos; Basin, David (2022): "Automating Cookie Consent and GDPR Violation Detection", in: 31st USENIX Security Symposium (USENIX Security 22), pp. 2893-2910. USENIX Association, Boston, MA. (Link)] crawled 30k websites using CMPs, collecting a dataset of 2.2 million declared cookies, with over 80% being third-party cookies.

The dataset is available here as part of this publication artifact. Scraped cookie categories are in /04_Cookie_Databases/tranco_05May_20210510_201615.sqlite, in the table consent_data, with the following columns:

• name and domain: Identify cookies by name and domain.
• cat_name: Category defined by website operators via the CMP, often aligning with the 12 IAB TCF purposes.
• cat_id: Numeric representation of ICC UK categories: 0 = Strictly-necessary, 1 = Functionality, 2 = Analytics, 3 = Advertising/tracking.

Note that 80% of cookies are third-party cookies, the majority of these involve multiple entries for a given name and domain. However, these entries might assign contradicting labels, in fact, the paper puts a lower bound of 7.2% on the share of third-party cookie labels that are noise — labels that do not match the majority label for that cookie. You should therefore aggregate labels for given cookie and domain pair, and then pick the most popular category.

There will be soon a new release based on December 2024 crawl, reach Karel Kubicek if you are reading this text and wanting the data.

Cookiepedia is a commercial website by OneTrust, containing 42,020,489 cookies as of 2026-09-10. Categories align with ICC UK's four categories, Strictly Necessary, Functionality, Performance=Analytics, and Targeting/Advertising, read more about the labeling process. OneTrust uses Cookiepedia to simplify cookie category assignments for their users (website operators), which however incentivizes labeling cookies as strictly necessary to avoid website breakage. This was observed by Bollinger and Kubicek et al. [4Bollinger, Dino; Kubicek, Karel; Cotrini, Carlos; Basin, David (2022): "Automating Cookie Consent and GDPR Violation Detection", in: 31st USENIX Security Symposium (USENIX Security 22), pp. 2893-2910. USENIX Association, Boston, MA. (Link)] in Section 4.5.

It is the field's default label source: 17 of the 53 cookie-classifying papers in the corpus use a purpose database, and Cookiepedia is named in 14 of them, from 2016 [16Cahn, Aaron; Alfeld, Scott; Barford, Paul; Muthukrishnan, S. (2016): "An Empirical Study of Web Cookies", in: Proceedings of the ACM Web Conference. (DOI)] to 2025 [13Tang, Brian; Bui, Duc; Shin, Kang G. (2025): "Navigating Cookie Consent Violations Across the Globe", in: Proceedings of the USENIX Security Symposium. (Link)].

To use Cookiepedia directly on the website, you can either select to search by website or cookie name. In the first case, Cookiepedia overviews of all the first- and third-party cookies, and in the latter, it shows the aggregated purpose across all websites with this cookie. This has limitations for first-party cookies, as different websites may use cookies with the same name for different purposes. For instance user_id cookies is classified as Strictly Necessary despite that many websites use it to track users.¹⁰⁾

You can scrape Cookiepedia or download dataset of almost 1M cookies collected by [5Munir, Shaoor; Siby, Sandra; Iqbal, Umar; Englehardt, Steven; Shafiq, Zubair; Troncoso, Carmela (2023): "CookieGraph: Understanding and Detecting First-Party Tracking Cookies", pp. 3490–3504. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)] as a CSV here. Note that the site rejects plain curl with HTTP 403; a scraper needs a real browser or a browser-like client.¹¹⁾

Accuracy, on the one dataset where anyone measured it. [4Bollinger, Dino; Kubicek, Karel; Cotrini, Carlos; Basin, David (2022): "Automating Cookie Consent and GDPR Violation Detection", in: 31st USENIX Security Symposium (USENIX Security 22), pp. 2893-2910. USENIX Association, Boston, MA. (Link)] evaluated Cookiepedia against 277k operator-declared labels and reports macro-recall (balanced accuracy) of 84.7%, against 84.4% for its own XGBoost model — the basis for the “competitive with human expertise” claim below. Precision is very uneven across classes: 94.5% for necessary, 84.2% for analytics, 38.1% for functional. Nobody has re-measured Cookiepedia since.¹²⁾

Cookie-Script is a commercial CMP whose cookie scanner exposes a name-keyed category database using the same four ICC UK categories plus an “unclassified” bucket. It is the second-most-used purpose database in the corpus — 3 papers, all 2024–2025 [15Lin, Maxwell; Lin, Shihan; Wu, Helen; Wang, Karen; Yang, Xiaowei (2024): "Browsing without Third-Party Cookies: What Do You See?", in: Proceedings of the ACM Internet Measurement Conference. (DOI), 6Chen, Baiqi; Lyu, Jiawei; Wu, Tingmin; Chhetri, Mohan Baruwal; Bai, Guangdong (2025): "Semantics-Aware Cookie Purpose Compliance", in: Proceedings of the ACM Web Conference. (DOI)] — and it is not mentioned anywhere on this page before 2026, which is a good illustration of how quietly a label source becomes standard.

Its unclassified rate is the reason to know about it: across 255 websites with cookie notices from the Tranco top 350, [15Lin, Maxwell; Lin, Shihan; Wu, Helen; Wang, Karen; Yang, Xiaowei (2024): "Browsing without Third-Party Cookies: What Do You See?", in: Proceedings of the ACM Internet Measurement Conference. (DOI)] categorised 18,074 cookies with Cookie-Script and 14,619 of them (80.9%) came back unclassified. The paper's own Table 1 caption puts it plainly: “the vast majority of cookies are unclassified”.

Cookiedatabase.org is an open alternative to Cookiepedia, started in 2019, operated by the Complianz CMP and funded by Complianz and the SIDN Fund. Contributions come from the websites using Complianz for consent management. They use the following categories:

1. Statistics-Anonymous
2. Statistics/analytics (also known as performance)
3. Marketing/Tracking (also known as Ad-storage, or social media)
4. Functional (also known as technical, essential or strictly necessary)
5. Preferences Cookies (in some jurisdictions known as functionality)

The site no longer publishes a cookie count; its public WordPress API exposes 501 service “Data Passports” as of 2026-09-10, which is a count of services, not cookies.¹³⁾ Earlier versions of this page carried a figure of 15.5k cookies; it can no longer be verified from the site and has been removed rather than refreshed. Two corpus papers use it [17Bouhoula, Ahmed; Kubicek, Karel; Zac, Amit; Cotrini, Carlos; Basin, David (2024): "Automated Large-Scale Analysis of Cookie Notice Compliance", in: Proceedings of the USENIX Security Symposium. (Link)].

The Open Cookie Database is a crowdsourced effort to describe and categorize major cookies. As of 2026-09-10 the published CSV contains 2,266 cookies and the repository is actively maintained (last commit 2026-08-21).¹⁴⁾ Categories are similar to the ICC UK guide:

• Functional (also known as technical, essential or strictly necessary)
• Personalization (also known as preferences)
• Analytics (also known as performance or statistics)
• Marketing (also known as tracking or social media)
• Security (custom category, used only by a few tens of cookies, which are mostly strictly necessary according to ICC UK's guide)

Its CSV also carries a Wildcard match column, which is the only one of these sources that addresses the dynamic-name problem described above.

CookieSearch is an open cookie database run by the CookieYes CMP, self-describing as “100,000+ cookies”, searchable by cookie name, ID, description, regex and script name. Its category scheme is six-valued — Necessary, Analytics, Advertisement, Functional, Performance, Others — so it does not map cleanly onto the ICC four: it splits analytics from performance, which the ICC scheme merges. Like the Open Cookie Database, it has zero mentions in the corpus. Treat the “100,000+” as a vendor self-report; there is no bulk export and no published methodology.¹⁵⁾

Using machine learning to classify cookies, rather than relying on static datasets, addresses the coverage limitation: a model that reads the cookie itself answers for 100% of your cookies, where a name lookup answers for 39–79% of them. Research indicates that ML methods may even outperform human classification. However, practical deployment of ML-based approaches faces challenges similar to those in ML-based advertising blocking: they are prone to adversarial attacks, may disrupt website functionality, and can potentially be used for fingerprinting. These limitations however does not hinder application of ML-based detection in research.

The corpus record is thinner than the literature's self-image. 5 of 53 papers reuse a published cookie classifier and 3 trained their own. The most recent conventionally-trained cookie classifier in these venues is [5Munir, Shaoor; Siby, Sandra; Iqbal, Umar; Englehardt, Steven; Shafiq, Zubair; Troncoso, Carmela (2023): "CookieGraph: Understanding and Detecting First-Party Tracking Cookies", pp. 3490–3504. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)] (2023); the only one since is [6Chen, Baiqi; Lyu, Jiawei; Wu, Tingmin; Chhetri, Mohan Baruwal; Bai, Guangdong (2025): "Semantics-Aware Cookie Purpose Compliance", in: Proceedings of the ACM Web Conference. (DOI)]'s fine-tuned GPT-3.5.

In Automating Cookie Consent and GDPR Violation Detection [4Bollinger, Dino; Kubicek, Karel; Cotrini, Carlos; Basin, David (2022): "Automating Cookie Consent and GDPR Violation Detection", in: 31st USENIX Security Symposium (USENIX Security 22), pp. 2893-2910. USENIX Association, Boston, MA. (Link)], researchers developed an ML model to classify cookies according to the four ICC UK purposes. They scraped data from 30k websites using CMPs like OneTrust and CookieBot, collecting over 2 million cookies labeled by website operators.

The researchers extracted statistically rich, domain-specific features from the collected cookies. These features are derived from multiple attributes, including the cookie name, domain, value, expiry, and flags such as “HttpOnly.” For example, the entropy of a cookie's value is a key feature for identifying unique identifiers used for tracking, while the presence of a language locale often signifies cookies necessary for language settings.

The authors trained an XGBoost model, achieving an 87.2% accuracy (84.4% balanced accuracy). This performance is competitive with the Cookiepedia dataset when considering website operators' labels as the ground truth, and it answers for 100% of cookies against Cookiepedia's 79.2% on the same data. The confusion matrices below provide a detailed comparison.

The classifier is released separately from the extension, as CookieBlock-Consent-Classifier. It takes a JSON file of cookies and produces features plus a prediction, so you can run it over cookies collected by any crawler — OpenWPM's javascript_cookies table, a Playwright storageState(), a CDP Network.getAllCookies dump. The input format is one object per cookie:

{
  "cookie_id": {
    "name": "<name>",
    "domain": "<domain>",
    "path": "/path",
    "first_party_domain": "http://first-party-domain",
    "label": 0,
    "cmp_origin": 0,
    "variable_data": [
      {
        "value": "<cookie content>",
        "expiry": "<expiration in seconds>",
        "session": "<true/false>",
        "http_only": true,
        "host_only": true,
        "secure": true,
        "same_site": "<no restriction/lax/strict>"
      }
    ]
  }
}

Two things the repository says that are easy to miss and change your results. Its README states that the Python feature extractor “differs from the Javascript version” and that “its outputs should not be used with the CookieBlock extension directly” — so an offline label and an extension label are not guaranteed to agree, and if your paper compares the two you have to say which you ran. And variable_data is a list: the model expects the sequence of values a cookie took across updates, not a single snapshot. A crawler that records the cookie jar once at the end of the visit throws away the feature the model most relies on. That is the reason for the instrumentation step below.

Whichever route you take, the model needs cookie updates, not a final jar. Use OpenWPM's cookie instrumentation (see OpenWPM), a CDP Network.responseReceivedExtraInfo listener, or the extension's own history database. The extension recipe, kept here because it is still what the Firefox route needs:

1. Install the CookieBlock extension in the same browser used by your crawler (see the links in the box above, and the CookieBlock page).
2. During installation, ensure all cookie categories and “Keep Track of Cookie History” are enabled. To be safe, open the cookie popup and click “Pause Cookie Removal.”
3. Identify the extension ID by navigating to CookieBlock's settings and checking the URL: chrome-extension://<ID>/options/cookieblock_options.html.
4. Export the profile and load it into your crawler.
5. After the crawl, collect all data from CookieBlock's database.

The following Python code illustrates these steps for a Selenium-operated Chrome browser. Note that while this step is manual, it is necessary to perform it only once. It is retained as a record of the method and as a template for the Firefox equivalent; as written it targets Chrome and will not work in Chrome 139 or later.

create_profile.py

from selenium import webdriver  # requires the Selenium package
 
# Initialize the ChromeDriver with options to set the profile path
options = webdriver.ChromeOptions()
options.add_argument("--user-data-dir=./profile_dir")
driver = webdriver.Chrome(options=options)
 
# Install the extension in the browser, retrieve its ID, and then close the browser.
# Backup ./profile_dir directory.

Edit your crawler to load the profile before starting the crawl and to extract the cookie category data afterward:

crawl.py

import json
from selenium import webdriver
import pandas as pd
 
# Before crawl: Initialize the ChromeDriver with the profile
options = webdriver.ChromeOptions()
options.add_argument("--user-data-dir=./profile_dir")
driver = webdriver.Chrome(options=options)
 
# Here is your crawler's logic
driver.get('https://google.com')  # example
 
# After crawl: 
# Extract the crawled data
EXTENSION_ID = 'fbhiolckidkciamgcobkokpelckgnnol'  # replace with your ID identified in step 3.
 
# Load extension settings
driver.get(f'chrome-extension://{EXTENSION_ID}/options/cookieblock_options.html')
 
# Extraction script
indexeddb_script = """
function getCookieBlockHistory() {
    return new Promise((resolve, reject) => {
        var request = window.indexedDB.open("CookieBlockHistory", 1);
 
        request.onerror = function(event) {
            reject("Error opening IndexedDB: " + event.target.errorCode);
        };
 
        request.onsuccess = function(event) {
            var db = event.target.result;
            var transaction = db.transaction(["cookies"], "readonly");
            var objectStore = transaction.objectStore("cookies");
            var data = [];
            objectStore.openCursor().onsuccess = function(event) {
                var cursor = event.target.result;
                if (cursor) {
                    data.push(cursor.value);
                    cursor.continue();
                }
            };
 
            transaction.oncomplete = function() {
                resolve(JSON.stringify(data));
            };
 
            transaction.onerror = function(event) {
                reject("Transaction error: " + event.target.errorCode);
            };
        };
    });
}
 
return getCookieBlockHistory().then(data => {
    return data;
}).catch(error => {
    return error;
});
"""
indexeddb_data = driver.execute_script(indexeddb_script)
 
try:
    cookies = json.loads(indexeddb_data)
except TypeError as e:
    print("Error:", e)
    cookies = []
 
df = pd.DataFrame(cookies)
df.to_csv('./cookies.csv', index=False)

Example output:

                 name                      domain path  current_label       label_ts storeId                                      variable_data
0                 AEC                 .google.com    /              0  1736265280414       0  [{'host_only': False, 'http_only': True, 'secu...
1               EUULE              www.google.com    /              0  1736265428337       0  [{'host_only': True, 'http_only': False, 'secu...
2                 NID                 .google.com    /              0  1736264250782       0  [{'host_only': False, 'http_only': True, 'secu...
3                 OTZ   chromewebstore.google.com    /              0  1736264250788       0  [{'host_only': True, 'http_only': False, 'secu...
4  TESTCOOKIESENABLED              www.google.com    /              0  1736265280594       0  [{'host_only': True, 'http_only': False, 'secu...
5       __Secure-ENID                 .google.com    /              0  1736265280415       0  [{'host_only': False, 'http_only': True, 'secu...
6                 _ga  .chromewebstore.google.com    /              2  1736264250780       0  [{'host_only': False, 'http_only': False, 'sec...
7      _ga_KHZNC1Q6K0  .chromewebstore.google.com    /              2  1736264250792       0  [{'host_only': False, 'http_only': False, 'sec...

Fields:

• name, domain, and path: identify the cookie
• current_label: ICC UK's four categories (0 = Strictly necessary, 1 = Functionality, 2 = Analytics, 3 = Advertising/tracking cookies)
• label_ts: timestamp of cookie creation
• variable_data: list of cookie changes, each containing:
  • http_only, secure, session, same_site: binary flags
  • expirationDate: timestamp
  • value: value of the cookie set in this change
  • timestamp: change timestamp

CookieGraph: Understanding and Detecting First-Party Tracking Cookies [5Munir, Shaoor; Siby, Sandra; Iqbal, Umar; Englehardt, Steven; Shafiq, Zubair; Troncoso, Carmela (2023): "CookieGraph: Understanding and Detecting First-Party Tracking Cookies", pp. 3490–3504. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)] extends CookieBlock to resist adversarial modifications by avoiding easily mutable features (e.g., name) and leveraging network graph features to capture cookie usage patterns. This approach requires even further instrumentation, available only in their custom crawler. It reports 90.18% accuracy, 90.07% precision and 92.09% recall.

Note that it answers a different question: CookieGraph's label is ATS versus non-ATS (advertising-and-tracking service or not), a binary tracking judgement, where CookieBlock's is a four-way purpose. Its ground truth is a combination of EasyList, EasyPrivacy, Cookiepedia and label propagation, so it inherits the filter lists' definition of a tracker — a legal claim built on it inherits that too.

Find the CookieGraph artifact at https://github.com/cookiegraph/CookieGraph/. One caveat if you reuse the labelling code: the file cookie_categories_updated.csv in labelling_scripts/ is not a CSV at all but a saved wget log; the real table is the similarly named cookies_categories_updated.csv.¹⁷⁾

Exactly one paper in these seven venues classifies cookies with a large language model: Semantics-Aware Cookie Purpose Compliance [6Chen, Baiqi; Lyu, Jiawei; Wu, Tingmin; Chhetri, Mohan Baruwal; Bai, Guangdong (2025): "Semantics-Aware Cookie Purpose Compliance", in: Proceedings of the ACM Web Conference. (DOI)], TheWebConf 2025. That is 1 of the 53 papers that classify a cookie, or 1.9%.

Its design is the transferable part. Rather than treating the cookie value as an opaque blob with an entropy, it segments the value into primitive units and fine-tunes GPT-3.5-turbo to interpret each segment's semantics, then maps the interpretation onto four GDPR-framed purposes (necessary, preference, statistics, marketing). Ground truth is 2,300 cookies from Alexa top-3k sites labelled by three independent authors, with Fleiss' kappa 0.978. It reports an F1 of 0.95 against Cookiepedia, Cookie-Script and CookieBlock on that set, “surpassing the CMPs and CookieBlock by around 10% and 18%”. Applied to the Alexa top 1k it finds 25.4% of websites provide no cookie declaration and 44.1% show a potential purpose violation.

Why cookies lag is a reasonable thing to speculate about in a related-work section and this page will not pretend to know. Two candidate explanations that a reviewer will accept: a cookie name-and-value pair is a very short, low-context input compared to a privacy policy, and the task already has a cheap, accepted baseline in a database lookup, so the marginal value of an LLM is lower than for tasks with no baseline at all.

A Supervised Learning Approach to Protect Client Authentication on the Web [18Calzavara, Stefano; Tolomei, Gabriele; Casini, Andrea; Bugliesi, Michele; Orlando, Salvatore (2015): "A Supervised Learning Approach to Protect Client Authentication on the Web", ACM Trans. Web 9(3). (DOI) (Link)] investigates classifying cookies used for authentication. However, the code and model have not been published. This is the smallest of the four questions in the corpus — 5 of 53 papers — and unlike the others it has a behavioural ground truth available: remove the cookie, resubmit the request, see whether the session survives. [19Calzavara, Stefano; Tolomei, Gabriele; Bugliesi, Michele; Orlando, Salvatore (2014): "Quite a mess in my cookie jar!: leveraging machine learning to protect web authentication", in: Proceedings of the ACM Web Conference. (DOI)] builds a 327-cookie gold set exactly this way.

Everything in this section is a count over the corpus: 5,859 papers from CCS, IMC, NDSS, PoPETs, USENIX Security, TheWebConf and IEEE S&P, 2010–2026. EuroS&P, ACSAC, RAID, AsiaCCS, CHI and SOUPS are not in it, so every figure below is a claim about those seven venues and nothing else. The report script and its unedited output are on cookies.

A paper is in the population if it has at least one classification tuple whose target is cookie. That is an enum field, not free text, so the set is stable between extraction runs — which is why it was preferred to a keyword sweep.

53 is the denominator for everything in this section, not 5,859 and not 1,120. Three papers whose detection tuple names a “cookie” that is not an HTTP cookie — a DNS cookie, a TCP SYN cookie, a Bloom cookie — are excluded by name rather than by regex, so the exclusion can be argued with individually.

A third of the field is at one venue, and PoPETs' rate is more than ten times IEEE S&P's — though IEEE S&P contributes 2 papers, so read the ratio as indicative rather than as a measurement. If you are doing a literature review on cookie classification and you search the “big four” security conferences, you will miss most of it. The absence of SOUPS and CHI from this corpus compounds the same problem in the other direction: the usable-privacy half of this literature — [7Jiwani, Soha; Sasheendran, Rachna; Abhyankar, Adhishree; Bouma-Sims, Elijah; Cranor, Lorrie (2024): "Crumbling Cookie Categories: Deconstructing Common Cookie Categories to Create Categories that People Understand", Proceedings on Privacy Enhancing Technologies . (DOI)], [11Schöni, Lorin; Kubicek, Karel; Zimmermann, Verena (2024): "Block Cookies, Not Websites: Analysing Mental Models and Usability of the Privacy-Preserving Browser Extension CookieBlock", in: Proceedings on Privacy Enhancing Technologies, pp. 192-216. (DOI)] — reaches these figures only because it happened to appear at PoPETs.

* Provisional venue-years: CCS 2026 and IMC 2026 have not been held, and IEEE S&P and WWW 2026 are incompletely selected, so 2026 is a floor and should not be read as a decline. 2010–2013 contributed one paper in total (CCS 2011) and are omitted. The share column is against papers that classified anything that year, which is the fairer denominator: it controls for the corpus roughly quintupling over the window.

The topic is not growing as a share of classification work. It sits between 0.4% and 2.4% for the whole window with no trend, and the 2025 peak of 11 papers is 1.8% — the same share as 2020.

The full table with statuses is in Which Methods Are Current. The two movements worth stating plainly:

• Purpose databases went from nothing to the default. Zero papers 2010–2015, one 2016–2019, three 2020–2022, then 8 of the 10 papers in 2023–2024 and 5 of the 12 in 2025–2026. Nothing about cookies changed; Cookiepedia became easy to query and CookieGraph published a dump of it.
• Hand-written one-off rules are still the largest family at 20 of 53 papers, and they are almost entirely unreusable — 61 distinct resourceName strings across 79 tuples, of which 27 begin with the word “custom” and 34 contain it.

Cookie-classification papers document their ground truth and their validation worse than the corpus average for classification work, by 16 and 38 percentage points. On a task whose defining difficulty is that there is no ground truth, that is the most uncomfortable pair of numbers on this page.

none-reported and not-applicable are sentinels and are never counted as answers; the rows overlap because a paper with several cookie tuples can appear in several. Manual validation of a sample is the field's realistic minimum and only a quarter of the papers do it.

The corpus-wide comparison, the four validation kinds and what each is worth on a task like this one are on Annotation; 32.1% is the lowest rate of any target on this wiki that has a page.

Of the 53, 49 have a crawl configuration recorded. Against the 1,080 crawling papers corpus-wide:

Cookie papers are twice as likely as the field to state a consent action (65.3% against 32.3%) and three and a half times as likely to state statefulness (73.5% against 20.3%) — the two settings that most change a cookie count. That is a real result and it is also the floor, not the ceiling: 20.4% state whether the browser was headless, and headlessness changes what a site serves.

Each figure carries its own denominator and they are not comparable to each other. Every one below was checked against the paper's own text; the quote-check pass is in the report output.

The last row is the one to keep in mind while reading the rest. Every percentage above is a percentage of a category system that the people it exists for cannot use.

The full query log, the report script, its unedited output, the folds with their residues, the quote checks and the external-source verification are on cookies. Corpus-wide caveats — how the corpus was built, which venue-years are provisional, how stable each extracted field is — are on Corpus.

Specific to this page:

• The population is an extraction artefact, and it is a floor. A paper enters the 53 because the extraction model assigned target: cookie to one of its classification tuples. A paper that classifies cookies as an incidental step of a study about something else may have had that step filed under other, and would be missing. The wider “measures something about cookies” set is 117 papers, and the gap between 53 and 117 is mostly papers that count or track cookies without labelling them — but not entirely.
• The four-question split is one person's reading, applied per resourceName string. Every one of the 61 distinct strings is mapped by hand in the report script and every mapping is printed with the paper it came from, so a disagreement can be located and argued. The script throws rather than silently dropping a tuple whose string is not in the map, so a corpus refresh cannot quietly shrink a family. A zero residue here means the map is complete, not that every judgement in it is right.
• Free-text fields are folded, and the fold is a judgement. resourceName and taxonomy agree run-to-run on roughly 20% of exact strings, so nothing here is counted by exact string. The taxonomy fold leaves a residue of 7 tuples, printed in full on the provenance page.
• The measured-results table mixes populations on purpose and cannot be aggregated. Nothing in it can be averaged, ordered or plotted against anything else in it.
• Two figures in it have denominators that the extraction got wrong or left ambiguous, and were corrected by reading the paper: the 89.86% is over the top million from a separate deployment, not over the paper's own 20K stratified sample, and [8Sánchez-Rola, Iskander; Dell'Amico, Matteo; Balzarotti, Davide; Vervier, Pierre-Antoine; Bilge, Leyla (2021): "Journey to the Center of the Cookie Ecosystem: Unraveling Actors' Roles and Relationships", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)]'s 48% is over cookies, not websites.
• crawlConfig is a single object with one shared evidence quote, so the crawl-configuration table cannot be quote-checked field by field. See the caveat box beside it.
• The stability figures quoted for the extraction were measured on a previous, smaller corpus and have not been re-measured against the current 5,859-paper run. Treat them as the right order of magnitude.

If a reviewer is to accept a cookie classification result, the paper has to answer all of these. Most published papers answer fewer than half.

1. Which of the four questions you are answering — purpose, identifier, tracking, or security role. Say it in one sentence, in the methodology, before the method.
2. The label source, named and versioned. “Cookiepedia” is not a version; the database changes under you and nobody publishes a changelog. Record the date you queried it and, if you can, keep the raw responses.
3. Coverage. How many of your cookies got a label, as a fraction of how many you tried to label. This is the number the field omits most often and it bounds every percentage you go on to report.
4. What you did with the unlabelled remainder. Dropped, counted as “unknown”, or assigned a default — these give three different answers and the third is almost always wrong.
5. The taxonomy, by name and origin. “The four standard categories” is not a citation; the ICC UK guide is from 2012 and is a PDF you should link.
6. How you decided first versus third party, with the eTLD list and its version.
7. Your consent state, and preferably more than one. A purpose distribution before interaction and after rejection are different measurements of different populations.
8. Whether you captured cookie updates or a final jar. Models that use value entropy or value churn need the sequence.
9. Your validation. A hand-labelled sample with an agreement statistic is the realistic minimum. Only a quarter of published cookie-classification papers do this — being in that quarter is cheap and visible.
10. Which browser, in which mode, with which tracking protections. A cookie population is browser-conditional; see Browser protection.
11. That your figure is a lower bound, if it is. Name-keyed lookup misses dynamic names; filter-list provenance misses whatever the list misses; identifier heuristics miss encrypted and server-side identifiers.

• Measuring Cookie and ID Syncing — what happens to a cookie value after you have decided it is an identifier, and the identifier heuristics themselves.
• Browser Storage Beyond Cookies — the five other places a site can leave an identifier, and what your crawler silently missed.
• Granting Consent to Websites and Interaction — the consent state that changes every figure here.
• Measuring the Privacy Sandbox — the third-party-cookie deprecation, its reversal, and partitioning.
• Measuring with Browser Tracking Protections On — why a cookie population is browser-conditional.
• Classifying Web Requests — filter lists, and the circularity you inherit with them.
• TCF consent strings — the 12 IAB purposes, and reading what the site actually stored.
• Stateful and stateless crawling — whether your crawl carries cookies from one site to the next.
• OpenWPM — the cookie instrumentation the offline route expects.
• Classifying Websites — the per-target LLM adoption table this page's LLM section shares.
• Annotation and Validation — how to validate a label set whatever it labels, and why cookie classification is the worst-validated target here.

[1]

Sanchez-Rola, Iskander; Dell'Amico, Matteo; Kotzias, Platon; Balzarotti, Davide; Bilge, Leyla; Vervier, Pierre-Antoine; Santos, Igor (2019): "Can I Opt Out Yet? GDPR and the Global Illusion of Cookie Control", pp. 340–351. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)

[2]

Roesner, Franziska; Kohno, Tadayoshi; Wetherall, David (2012): "Detecting and Defending Against Third-Party Tracking on the Web", in: 9th USENIX Symposium on Networked Systems Design and Implementation (NSDI 12), pp. 155-168. USENIX Association, San Jose, CA. (Link)

[3]

Solomos, Konstantinos; Ilia, Panagiotis; Ioannidis, Sotiris; Kourtellis, Nicolas (2020): "Clash of the trackers: Measuring the evolution of the online tracking ecosystem".

[4]

Bollinger, Dino; Kubicek, Karel; Cotrini, Carlos; Basin, David (2022): "Automating Cookie Consent and GDPR Violation Detection", in: 31st USENIX Security Symposium (USENIX Security 22), pp. 2893-2910. USENIX Association, Boston, MA. (Link)

[5]

Munir, Shaoor; Siby, Sandra; Iqbal, Umar; Englehardt, Steven; Shafiq, Zubair; Troncoso, Carmela (2023): "CookieGraph: Understanding and Detecting First-Party Tracking Cookies", pp. 3490–3504. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)

[6]

Chen, Baiqi; Lyu, Jiawei; Wu, Tingmin; Chhetri, Mohan Baruwal; Bai, Guangdong (2025): "Semantics-Aware Cookie Purpose Compliance", in: Proceedings of the ACM Web Conference. (DOI)

[7]

Jiwani, Soha; Sasheendran, Rachna; Abhyankar, Adhishree; Bouma-Sims, Elijah; Cranor, Lorrie (2024): "Crumbling Cookie Categories: Deconstructing Common Cookie Categories to Create Categories that People Understand", Proceedings on Privacy Enhancing Technologies . (DOI)

[8]

Sánchez-Rola, Iskander; Dell'Amico, Matteo; Balzarotti, Davide; Vervier, Pierre-Antoine; Bilge, Leyla (2021): "Journey to the Center of the Cookie Ecosystem: Unraveling Actors' Roles and Relationships", in: Proceedings of the IEEE Symposium on Security and Privacy. (DOI)

[9]

Kancherla, Gayatri Priyadarsini; Goel, Dishank; Bichhawat, Abhishek (2025): "Least Privilege Access for Persistent Storage Mechanisms in Web Browsers", in: Proceedings of the ACM Web Conference. (DOI)

[10]

Kyi, Lin; Mhaidli, Abraham; Santos, Cristiana Teixeira; Roesner, Franziska; Biega, Asia J. (2024): "“It doesn’t tell me anything about how my data is used”: User Perceptions of Data Collection Purposes", in: Proceedings of the 2024 CHI Conference on Human Factors in Computing Systems. Association for Computing Machinery, New York, NY, USA. (DOI) (Link)

[11]

Schöni, Lorin; Kubicek, Karel; Zimmermann, Verena (2024): "Block Cookies, Not Websites: Analysing Mental Models and Usability of the Privacy-Preserving Browser Extension CookieBlock", in: Proceedings on Privacy Enhancing Technologies, pp. 192-216. (DOI)

[12]

Calzavara, Stefano; Casarin, Samuele; Squarcina, Marco; Maffei, Matteo (2026): "From Syntactic Matching to Taint Tracking and Back: A Comparative Study of Web Tracking Detection Techniques", in: Proceedings on Privacy Enhancing Technologies. (Link)

[13]

Tang, Brian; Bui, Duc; Shin, Kang G. (2025): "Navigating Cookie Consent Violations Across the Globe", in: Proceedings of the USENIX Security Symposium. (Link)

[14]

Demir, Nurullah; Urban, Tobias; Pohlmann, Norbert; Wressnegger, Christian (2024): "A Large-Scale Study of Cookie Banner Interaction Tools and their Impact on Users' Privacy", in: Proceedings on Privacy Enhancing Technologies, pp. 5-20. (DOI)

[15]

Lin, Maxwell; Lin, Shihan; Wu, Helen; Wang, Karen; Yang, Xiaowei (2024): "Browsing without Third-Party Cookies: What Do You See?", in: Proceedings of the ACM Internet Measurement Conference. (DOI)

[16]

Cahn, Aaron; Alfeld, Scott; Barford, Paul; Muthukrishnan, S. (2016): "An Empirical Study of Web Cookies", in: Proceedings of the ACM Web Conference. (DOI)

[17]

Bouhoula, Ahmed; Kubicek, Karel; Zac, Amit; Cotrini, Carlos; Basin, David (2024): "Automated Large-Scale Analysis of Cookie Notice Compliance", in: Proceedings of the USENIX Security Symposium. (Link)

[18]

Calzavara, Stefano; Tolomei, Gabriele; Casini, Andrea; Bugliesi, Michele; Orlando, Salvatore (2015): "A Supervised Learning Approach to Protect Client Authentication on the Web", ACM Trans. Web 9(3). (DOI) (Link)

[19]

Calzavara, Stefano; Tolomei, Gabriele; Bugliesi, Michele; Orlando, Salvatore (2014): "Quite a mess in my cookie jar!: leveraging machine learning to protect web authentication", in: Proceedings of the ACM Web Conference. (DOI)

[20]

Rasaii, Ali; Dao, Ha; Feldmann, Anja; Javid, Mohammadmahdi; Gasser, Oliver; Gosain, Devashish (2025): "Intractable Cookie Crumbs: Unveiling the Nexus of Stateful Banner Interaction and Tracking Cookies", in: Proceedings on Privacy Enhancing Technologies, pp. 429-445. (DOI)