Cookie Discovery
How the Cookiewise scanner inventories cookies and related storage on your website.
How Scanning Works
Cookiewise launches a headless Chromium browser (Puppeteer) and visits your site the way a visitor would. During the scan it:
- Loads your homepage and waits for scripts and lazy content to run
- Crawls further pages from internal links and
sitemap.xml, up to the page count you choose (maximum 200) - Clicks Accept and Reject on the homepage in isolated browser contexts so cookies that only appear after a consent choice are included
- Reads the browser cookie jar via Chrome DevTools (
Network.getAllCookies), including HttpOnly, Secure, and third-party cookies - Labels HTTP vs JavaScript cookies from intercepted
Set-Cookieheaders (JavaScript-set cookies are those present in the jar but not seen in a header) - Records script initiators when Chrome reports which request set a cookie
- Inventories web storage —
localStorage,sessionStorage, and IndexedDB database names - Flags third-party domains from cookie hosts and network requests
- Detects known vendors from scripts that load after Accept even when they have not written a cookie yet. The catalog is a hand-maintained overlay plus vendors imported from the Open Cookie Database (hosts and cookie names, grouped by platform)
Starting a Scan
- Navigate to Cookie Scanner
- Select the website to scan
- Choose the number of pages (1–200). Larger counts take longer; sitemap URLs are included when available
- Optionally set a weekly or monthly rescan schedule
- Click Start Scan
A 10-page scan typically completes in one to three minutes. Deeper crawls and the dual consent pass take longer.
What Gets Detected
First-Party Cookies
Cookies set on your registrable domain — session IDs, preferences, authentication tokens, shopping carts.
Third-Party Cookies
Cookies from external services — analytics, ad networks, embedded widgets.
HTTP Cookies
Seen in server Set-Cookie headers. Often used for authentication and server-side tracking.
JavaScript and storage
Cookies present in the jar without a matching header, plus localStorage, sessionStorage, and IndexedDB names.
Vendors loaded after Accept
Known widgets (chat, translate, maps, video) seen in network requests after consent. Listed as Functional or Social with “cookies on use” when no cookie was written during the crawl.
Cookie Details Captured
For each item discovered, the scanner records:
- Name — Cookie or storage key
- Type — HTTP cookie, localStorage, sessionStorage, IndexedDB, or a consent-gated vendor script
- Domain — Host that owns the item
- Path — Cookie path scope (cookies only)
- Expiration — Session or persistent duration
- Secure / HttpOnly / SameSite — Cookie flags from the browser jar
- Initiator — Script or response URL when Chrome reports it
- Consent path — Seen after Accept, Reject, or both
- Category and confidence — From the known-cookie database, Open Cookie Database rules, or AI with a review flag when confidence is low
What the scanner does not do
- It does not log into member areas unless those URLs are publicly linked
- It does not fill payment forms or complete checkouts
- It does not inventory arbitrary image pixels or ultrasound beacons. Unknown script/XHR hosts after Accept are queued for review instead of guessed
- Classification is not the same as IAB TCF vendor IDs — categories follow common CMP groups
- The banner blocks those detected vendor hosts until consent; it does not rewrite every third-party URL on the page
Re-scanning
Your website changes over time — new plugins, updated tracking codes, new third-party integrations. We recommend:
- Weekly or monthly scheduled scans for actively developed sites
- After every deployment if you add new tracking or analytics tools
- A manual scan when you change your tag manager or consent setup
Each new scan updates your cookie inventory. Items that no longer appear are marked inactive. New or low-confidence items are flagged for review. Manual category overrides are kept.