webtracking.org
tools

What is this cookie? Classify any cookie by vendor and purpose with the Cookie Scanner

Paste any cookie set and get vendor and purpose for each name — analytics, advertising, session replay, consent — classified locally against 85 built-in rules.

last verified 2026-07-18

Every cookie audit starts with the same tedious question, asked forty times in a row: what is _gcl_au? Who sets _clck? Is __cf_bm strictly necessary or does it belong behind the consent banner? The answers exist, but they are scattered across vendor documentation pages, and looking each name up by hand is exactly the kind of work that makes consent audits stall.

The Cookie Scanner collapses that lookup into one step. Paste a cookie set — or scan the browser you are sitting in — and every name comes back with a vendor, a purpose, a consent-banner category, a typical lifetime, and a short explanation. It runs entirely client-side: no account, no server, no network request of any kind. It is built for the people who have to produce or check a cookie table — measurement managers prepping a consent-banner configuration, implementation engineers explaining an unexpected cookie to legal, agencies doing a first-pass privacy review of a client site.

What it does

The tool has two tabs:

  • This browser reads what the current page’s own origin can see — document.cookie plus the keys of localStorage and sessionStorage — and classifies each item. Storage is classified by key only; values are never read (they can be large, and reading them is unnecessary for classification). A “Copy as list” button exports the names.
  • Classify a set takes pasted input in three shapes: a document.cookie string (a=1; b=2), a newline-delimited list of name=value pairs, or a raw Set-Cookie dump where attributes after the first ; are ignored. Results can be exported as CSV or JSON.

Each classified row shows six fields: name, value, vendor, purpose (with a first-party/third-party marker where the database knows the typical context), typical duration, and notes. Above the table, summary chips count the set by purpose, ordered by severity: advertising first, then session replay, analytics, functional, consent, necessary, and unclassified.

The purposes map to the consent-banner buckets auditors actually use: Strictly necessary, Functional, Analytics / performance, Advertising / targeting, Analytics / session replay, Consent management, and Unclassified.

How it works

The classification engine (cookies.js) is pure logic — no DOM access, no dependencies — and its core is a database of 85 rules. Each rule pairs a match condition with a full classification:

{ match: "prefix", key: "_hjSessionUser_", vendor: "Hotjar",
  purpose: "session-replay", typicalDuration: "1 year", thirdParty: false,
  notes: "Persistent Hotjar user ID across sessions (per site)." }

Rules match either an exact cookie name or a name prefix (the matcher also supports regex rules). They are tested in order and the first match wins, so specific rules sit before broad ones: _ga_ (the GA4 per-property cookie, _ga_<container-id>) is checked before the exact _ga client-ID rule, and _hjSessionUser_ before the catch-all _hj Hotjar prefix.

The database covers the names that dominate real audits: Google Analytics and Google Ads (_ga, _gid, _gat, _gcl_au), DoubleClick’s third-party set (IDE, test_cookie, DSID), Meta’s pixel cookies (_fbp, _fbc, fr), Microsoft UET and Clarity, Hotjar, Segment, Mixpanel, Amplitude, HubSpot, Matomo, Optimizely and VWO, LinkedIn, TikTok, Pinterest, X/Twitter, CDN and bot-management cookies from Cloudflare, DataDome, and AWS load balancers, consent-platform cookies from OneTrust, Cookiebot, CookieYes, and the IAB TCF euconsent-v2 string, plus framework session cookies like PHPSESSID, JSESSIONID, and csrftoken.

Three engine behaviours matter for trusting the output:

  1. No false positives by design. A name that matches nothing returns an explicit Unknown record with a note telling you to inspect it manually — the tool never guesses a vendor.
  2. __Secure- / __Host- prefix handling. These RFC 6265bis security prefixes are stripped and the remainder is re-classified, with a note recording the prefix. If the underlying name is still unrecognised, you get “known-secure, unknown vendor” rather than a wrong match.
  3. An attribute-aware parser. Input is split on newlines, then on semicolons, and every segment is treated as a candidate name=value pair — except recognised Set-Cookie attributes (Expires, Max-Age, Domain, Path, SameSite, Priority, and the valueless Secure, HttpOnly, Partitioned), which are skipped so a header dump does not produce junk rows. Names are deduped with last-value-wins, preserving first-seen order, and values containing = (common in consent strings) survive intact.

Exports mirror the table: JSON is the raw classified rows, and CSV uses RFC 4180 escaping with a spreadsheet-formula-injection guard (cells starting with =, +, -, or @ get a leading apostrophe) across the columns name, value, vendor, purpose, category, typical_duration, third_party, notes.

How to use it

  1. Open the Cookie Scanner. The This browser tab runs automatically on load; press Scan this browser to refresh it.
  2. To audit another site, open that site, run copy(document.cookie) in the browser console, then switch to the Classify a set tab and paste. Press Classify (or Ctrl/Cmd+Enter).
  3. Not sure what input looks like? The Sample button loads a realistic mixed set — GA4, the Facebook pixel, Clarity, Hotjar, DoubleClick, OneTrust, a Cloudflare bot cookie, a PHP session ID, and an unclassifiable custom preference — so you can see every purpose tag at once.
  4. Read the chips first for the headline (how much advertising and session replay is present), then work down the table. Rows marked Unclassified are your manual-review queue.
  5. Use Export CSV to hand the table to legal or paste it into a consent-banner audit sheet, or Export JSON to feed it into your own tooling.

Limitations

The tool is honest about these on the page itself, and they are worth restating:

  • Same-origin only, and no HttpOnly. A page can only read its own origin’s cookies, and HttpOnly cookies are hidden from JavaScript by design. That is why the “This browser” tab shows a short list on webtracking.org — the browser’s security model working, not a bug.
  • Name-based classification is a heuristic. Durations are typical lifetimes from the database, not the actual Expires/Max-Age of your cookies (the parser deliberately discards attributes). The first-party/third-party flag reflects the cookie’s usual serving context, not an observation of your site.
  • Coverage is well-known names. 85 rules catch the trackers that appear on most commercial sites, but site-specific and long-tail cookies come back Unclassified — deliberately so.
  • It sees names, not behaviour. The scanner cannot watch the network requests each tag fires, which third parties receive data, or whether any of it respects consent. Classification is an input to an audit, not the audit.

FAQ

Is my cookie data uploaded anywhere? No. The page and its engine run entirely in your browser and work offline; there is no server, no account, and no network request. The UI also never interpolates your input into HTML — every value is rendered as plain text.

Why does scanning “this browser” show so little? Because the tool can only read cookies on its own origin, and webtracking.org sets very few. To audit a different site, copy that site’s document.cookie from its console into the “Classify a set” tab.

Can I paste raw Set-Cookie response headers? Yes. The parser takes the name=value before the first semicolon and skips standard attributes like Path, Expires, HttpOnly, and Partitioned, so a header dump classifies cleanly.

What does “Unclassified” mean — is the cookie safe? Neither safe nor unsafe: it just is not in the built-in database. It could be a harmless site-specific preference or a niche tracker. Check the site’s cookie policy or inspect the value.

Does it detect trackers that use localStorage instead of cookies? Partially. The “This browser” tab classifies localStorage and sessionStorage keys against the same rule database (Amplitude and Mixpanel identifiers often live there), but it reads keys only, never values, and pasted sets are treated as cookies.