Key takeaways

A reliable cookie audit has four parts: observe what happens before a visitor chooses, test again after accepting and rejecting each category, inspect representative pages and interactions, and document every cookie with its purpose, provider, duration, and category.

Last reviewed: 29 August 2026

Start with a clean browser profile and Chrome or Firefox developer tools. Then use an automated scanner to cover more pages and compare its findings with your manual test. Neither method is complete on its own. Cookies may appear only after a video plays, a form opens, or a third-party script loads.

Your finished inventory should drive three practical updates: remove trackers you no longer need, configure non-essential tools so they wait for the right choice, and align your banner and cookie information with what the site actually does. A scan is evidence for that work, not a legal guarantee.

A cookie audit tests when your site stores or reads information on a visitor's device, why that happens, and whether the result matches the visitor's choice.

By the end, you should know what the site stores; which page, script, or service creates each item; when it appears; what it does; and how long it lasts. You should also know which banner category controls it, whether your public information describes it accurately, and whether you can remove it.

This matters because EU cookie rules are more precise than the shorthand “GDPR requires a cookie list.” At EU level, Article 5(3) of the ePrivacy Directive sets a baseline of clear information and prior consent for storing or accessing information on a user's device, unless the operation is strictly necessary to provide a service the user requested. EU countries implement that Directive through national law, so wording, exemptions, and enforcement can differ. Where personal data is involved, GDPR standards also shape whether consent is valid.

California takes a different approach. The CCPA does not simply require every business to publish an EU-style cookie table. Its notice, opt-out, and sensitive-data rules depend on how personal information is collected, sold, or shared. If you serve more than one region, treat the audit as a factual map of your technology, then apply the rules relevant to your business and visitors. See CCPA vs GDPR differences for a plain-English comparison.

Sites change quietly. A new widget may add storage, or an old campaign tag may remain active. You cannot configure a banner or write accurate cookie information until you know what the live site does.

Good preparation prevents stale browser data and an unrepresentative test path from distorting the result.

Choose representative pages and actions

Do not test only the homepage. Make a short test plan that covers the templates and tools most likely to behave differently:

Page or action Why include it
Homepage Tests global scripts and the initial consent state
Product or service page May contain reviews, booking tools, or personalization
Blog article May contain video, social, advertising, or recommendation widgets
Contact or lead form May load form, spam-prevention, or scheduling services
Checkout or account page Tests cart, authentication, payment, and security cookies
Embedded map or video Often introduces a separate third-party service
Accept all Shows the full consent-enabled state
Reject non-essential Tests whether optional tools remain blocked
Category-by-category choice Confirms that each control affects the intended tools
Withdraw or change choice Tests whether later changes take effect

For a small brochure site, five to ten URLs may be enough. For a shop or content site, select one URL from each major template and feature type. Aim for representative coverage, not an arbitrary page count.

Record the test conditions

Log the date, tester, URL, browser, device, login state, test region, consent path, pages, actions, and scanner settings. Cookie behavior may vary by privacy controls, login status, geography, or experiments. Recording the conditions makes a later comparison meaningful.

Start from a clean state

Use a fresh browser profile or a private/incognito window. Confirm that extensions are disabled unless one is part of the audit. Clear site data between test scenarios. Otherwise, an old consent choice or an existing identifier may hide the initial behavior.

A private window is not a perfect model of every visitor. Browsers can restrict third-party cookies differently. Repeat important tests in the browsers that matter to your audience.

How to audit cookies with Chrome DevTools

Chrome DevTools gives you a direct view of browser storage and network activity. The labels can change slightly between browser versions, but the basic workflow remains the same.

Step 1: Open DevTools before loading the page

Open a new blank tab in a clean private window or browser profile. While the tab is still blank, open DevTools:

  • Windows or Linux: F12 or Ctrl + Shift + I
  • macOS: Command + Option + I

Select Network, make sure recording is active, and enable Preserve log. Now type or paste the audit URL into the address bar and navigate to it. Opening DevTools before navigation captures the initial document request and its response headers.

After the page loads, select Application. In the left sidebar, expand Storage, then Cookies, and select each relevant origin.

For every later consent scenario, clear the site's cookies and other storage in Application, clear the Network request list, confirm that recording and Preserve log remain active, and then reload. Use the same clean-state sequence for no choice, acceptance, rejection, granular choice, and withdrawal.

On the initial clean navigation, do not interact with the banner. Wait for the visible page to settle, then note every cookie shown. Also scroll through the page because some resources load only when they approach the viewport.

Do not assume that every pre-choice cookie is wrong. A short-lived security, load-balancing, cart, or consent-preference cookie may be strictly necessary. Your task is to identify the purpose and test whether the exemption really applies. “Useful to the business” and “strictly necessary for the service requested by the visitor” are not the same test.

If analytics, advertising, session replay, or cross-site profiling appears before a visitor chooses, flag it for technical and legal review. The next question is which script or request created it.

DevTools exposes details that help you understand and document the cookie:

Field What it tells you
Name and value The identifier and stored value; do not copy live personal data into shared files
Domain and path The hosts and URL paths to which the browser may send it
Expires / Max-Age Whether it is a session cookie or when it expires
HttpOnly Whether JavaScript is prevented from reading it
Secure Whether it is limited to secure connections
SameSite Rules for cross-site sending
Partition key Whether supported browsers partition it by top-level site

The security attributes help you assess implementation, but they do not decide the consent category. A marketing cookie does not become necessary because it uses Secure or HttpOnly.

A cookie displayed under your own domain is not automatically “owned” by you in a practical sense. Third-party JavaScript can create a first-party cookie on your domain. Record both the cookie domain and the service or script responsible.

Step 4: Use the Network panel to find the source

The Application panel shows what exists. Network helps explain how it arrived. Enable Preserve log, reload from a cleared state, and filter by the suspected vendor or domain. Inspect request and response headers for Set-Cookie, cookies sent with later requests, and Initiator details that point to a script or tag.

JavaScript can also set cookies through document.cookie, so compare the request timeline with the Application panel. A tag manager's preview mode can help identify a tag, but may change site behavior.

Step 5: Test accept, reject, and granular choices

Clear site data before each scenario. Then repeat the same pages and interactions:

  • no choice;
  • accept all;
  • reject non-essential cookies;
  • accept one optional category at a time;
  • withdraw a previous choice.

Compare the inventories. After rejection, you may still see the cookie that stores the visitor's consent preference and other genuinely necessary items. Optional categories should not behave as accepted simply because the banner recorded a refusal.

When withdrawing consent, check both future behavior and existing storage. Stopping a script does not necessarily remove a cookie already stored in the browser.

Step 6: Trigger real interactions

Follow the page plan you prepared. Play the video, open live chat, submit a test form without real personal data, change language, add an item to the cart, and visit the checkout. Pause after each action and note what changed.

This is where manual audits earn their value: they reveal the connection between an action and a new cookie. Their weakness is coverage. You will only find behavior you actually trigger.

Want a broader first pass? Run the free ConsentEase cookie scanner, then use the manual steps above to investigate its findings and test your banner choices.

Audit across consent states

  1. 01

    Clean visit · no choice

    Open a fresh session. Do not interact with the banner; record what the page and its requests introduce.

  2. 02

    Accept

    Clear site data, accept optional purposes, then inspect the same routes and interactions again.

  3. 03

    Reject

    Clear site data, reject optional purposes, then repeat the same observation path.

  4. 04

    Compare inventories

    Place the dated observations side by side. Investigate differences by purpose, trigger, and source.

Keep conditions consistent: use the same pages, actions, browser context, and clean-state process for each observation.
A repeatable observation flow. It helps structure an inventory; it does not determine a cookie’s purpose, legal basis, or compliance status.

How to check cookies in Firefox

Open a fresh private window, press F12, select Storage, and expand Cookies. Use Network to investigate requests, and clear site data between the no-choice, accept, reject, and category tests.

Firefox may produce different results because browser privacy features differ. Record discrepancies and identify whether the browser blocked a request or storage. Browser extensions such as Cookie-Editor can help export a list, but they do not improve test coverage. Check the publisher, permissions, and data practices before installing one.

Audit third-party cookies and other browser storage

The term “cookie audit” is convenient but incomplete. Article 5(3) of the ePrivacy Directive refers more broadly to storing information or gaining access to information stored on a user's device. Your review should therefore look beyond the Cookies list.

In the Application or Storage panel, inspect local and session storage, IndexedDB, service workers, cache storage, embedded frames, and requests that transmit identifiers without setting a traditional cookie.

Also check external requests in the Network panel. A third-party request does not prove tracking: it could deliver a font, process a payment, or prevent fraud. Investigate what triggers it, what data it sends, whether it uses an identifier, when it becomes active, and whether your public information names the service accurately.

Modern browser restrictions can prevent a third-party cookie from being stored even though your page still sends a request and discloses information. That is why “the Cookies table looks empty” is not enough to conclude that no tracking occurs.

Automated scanners are valuable because they can visit more pages consistently and repeat the same checks later. A scanner may also make a first attempt at matching cookie names to known services and purposes.

Manual audit versus automated scan

Method Best at Main limitation
Browser developer tools Explaining exactly when a cookie appears during a known interaction Limited to the path and browser state you test
Browser extension Quick viewing and export during manual work Adds permissions and still depends on your browsing path
Automated scanner Repeatable coverage across multiple public URLs May miss logins, forms, geofenced content, or unusual interactions
Tag or code review Finding intended scripts and conditional logic Deployed behavior may differ from the code or configuration reviewed

Use at least two perspectives: an automated scan for breadth and a manual browser test for timing and consent behavior. For higher-risk or complex sites, add a tag-manager and source-code review.

Do not judge a scanner only by the number of cookies it reports. Check whether it crawls multiple pages, shows where an item was found, distinguishes consent states, reports other storage or trackers, exports results, and lets you correct uncertain classifications. Complex sites may also need authenticated or staging scans. Review how the provider handles scan data.

No scanner can determine every purpose or legal exemption from a cookie name alone. Custom names, changing vendor behavior, dynamic tag rules, and logged-in features need human review. Treat “unknown” as a research task, not a category.

ConsentEase performs an automatic cookie scan when you add a website. You can also use the free scanner for an initial check. Compare any automated report with your own consent-state tests before changing production settings.

How to categorize website cookies

Categorization is often the hardest part of the audit because the same technology can serve different purposes in different configurations. Categorize by what the cookie actually does on your site, not by its name or by what would be convenient.

Strictly necessary

These support a service the visitor explicitly requested and cannot reasonably be omitted while delivering it. Examples include authentication, a shopping cart, security, load balancing, and consent-choice storage. Ask what requested function would fail without the cookie. Business-useful analytics are not therefore technically necessary for showing a page.

Functional or preferences

These remember choices or support optional features such as language, enhanced media, or chat. Some short-lived interface preferences may be exempt in a specific context, while other functional services require consent. Document the feature and duration rather than treating every preference alike.

Analytics or measurement

These measure visits, navigation, performance, or campaigns. Data fields, retention, recipients, cross-site capability, and national rules matter. Some regulators recognize narrow measurement exemptions under strict conditions; there is no universal rule that analytics are necessary. Document any exemption and verify the configuration against current authority guidance.

Marketing or advertising

These support advertising, retargeting, campaign attribution, audience creation, or cross-site profiles. Examples may include ad pixels and conversion tags. In an EU consent model, these should normally remain inactive until the visitor makes the relevant choice.

Unclassified

“Unknown” is not a safe permanent category. Check current vendor documentation, identify the responsible request or script, ask the service owner, and disable the suspected tool in a controlled environment to retest. Remove it if nobody can establish a valid purpose.

A useful inventory lets someone reproduce your conclusion. Keep it in a spreadsheet or internal register with an owner and review date.

Field Example format Where to verify
Cookie or storage key Exact name or documented pattern Browser storage panel
Provider/service Company and product Script, request domain, contract, vendor documentation
Domain, path, and context As observed; identify who creates it Storage and request investigation
Purpose Plain description of actual use Configuration and primary vendor documentation
Trigger Page load, login, video play, checkout Controlled manual test
Consent state Before choice, accepted category, rejected Repeated clean-state tests
Duration Session or observed expiry Expires/Max-Age and vendor documentation
Category Necessary, functional, analytics, marketing Purpose-based assessment
Source and owner URL/template and responsible person Test log and operations records
Verification and status Date; keep, block, remove, or investigate Audit log and remediation plan

Avoid blindly copying generic cookie descriptions from a public database. A database can help identify a likely service, but only your configuration and test can show what happens on your site. Vendor documentation may also describe several possible durations; record what the browser observed and investigate any mismatch.

Keep values out of the inventory unless they are essential to diagnosis. Cookie values and network payloads can contain user or session identifiers. Screenshots and exports should use a clean test account, be redacted where necessary, and be stored with appropriate access controls.

Turn the audit into an action plan

The inventory is the diagnosis. The next step is to make the site, consent controls, and public information agree.

  1. Remove what you do not need. Delete retired pixels, duplicate analytics tags, and unused plugins from site code and tag-manager containers.
  2. Fix timing and controls. Map retained services to banner categories and prevent non-essential storage or transmission before the relevant choice where prior consent is required. Retest from a cleared state using the cookie-blocking guide.
  3. Update public information. Describe purposes, providers, durations, and categories in plain language. Keep banner groups and cookie information aligned. See cookie consent best practices.
  4. Check wider obligations. The inventory does not settle contracts, transfers, server-side retention, opt-out signals, sensitive data, or local exemptions. Seek qualified advice where needed.
  5. Keep evidence. Save the dated inventory, test plan, export, configuration, and decisions. Assign owners and due dates to unresolved items.

Most surprises are ordinary maintenance problems rather than sophisticated tracking:

  • An old campaign still runs. The landing page is gone, but its tag remains in the global tag manager.
  • An embed loads before interaction. A map or video connects to its provider as soon as the page renders.
  • Reject records the choice but does not stop the tags. The visual control works, while the technical trigger ignores it.
  • A third-party script writes a first-party cookie. The domain column alone hides the service responsible.
  • The homepage is clean but another template is not. Checkout, blog, or campaign pages use different code.
  • The policy outlives the implementation. Names, purposes, or durations describe a previous toolset.

For regulator decisions and their practical lessons, see real cookie consent enforcement examples. Verify each case against the linked primary decision.

How often to audit your cookies

There is no universal quarterly rule in the ePrivacy Directive. Choose a cadence based on how often your site changes, and scan after material changes rather than waiting for the calendar.

Useful audit triggers include:

  • installing or updating a plugin, theme, app, SDK, or tag;
  • launching a campaign, experiment, or new analytics setup;
  • adding video, maps, chat, reviews, payment, or booking tools;
  • redesigning templates or changing the consent platform;
  • changing vendors, purposes, data flows, or retention;
  • receiving a scanner alert, visitor complaint, or vendor notice;
  • seeing unexplained requests or cookies during quality assurance.

For a stable small site, a documented quarterly review is a practical baseline, not a legal safe harbour. A site with frequent marketing releases should add cookie checks to every release process. After each audit, compare against the prior inventory so new and changed items stand out.

Review ConsentEase pricing → if you want to compare an automated consent-management workflow with your current manual process. Review the service against your own legal, technical, and operational requirements.

  • List representative pages, embeds, and actions.
  • Record the browser, region, login state, and environment.
  • Clear site data before each consent scenario.
  • Test no choice, accept, reject, granular choice, and withdrawal.
  • Trigger forms, media, chat, cart, account, and checkout features.
  • Inspect cookies, other storage, and network requests.
  • Reconcile an automated scan with the manual test.
  • Record each item's service, purpose, scope, duration, trigger, and category.
  • Investigate unknown items without storing live user identifiers.
  • Remove unused tools and fix scripts that run too early.
  • Align the banner and public information with the inventory.
  • Retest, save dated evidence, and assign owners and review dates.

Sources

Ready to compare this checklist with your live site? Run a free cookie scan →