Website Cookie Inventory Scanner Guide: List Every Cookie Your Site Sets

Cookies are small pieces of data a website stores in a visitor's browser, and a typical site sets far more of them than its owner realises. Analytics tools, video embeds, social buttons, advertising partners, chat widgets, and the site's own login and preference systems each add their own. The result is an inventory that grows silently with every new feature, while the site's privacy page still describes the handful of cookies the site had when it launched. That gap between what a site says and what it does is where trust and compliance problems begin.

The Website Cookie Inventory Scanner tool scans a website's cookie behaviour and produces an inventory of the cookies it sets. It reports what it observes from the site's pages and embedded content, organised so you can review each entry. It does not give legal advice, decide whether a cookie needs consent in your jurisdiction, or rewrite your privacy policy. What it gives you is the factual foundation those decisions need: a list of what is actually set, by whom, and for how long, replacing guesses with observations.

Understanding a cookie means understanding four things about it. The name identifies it. The owner, or domain, tells you who set it and who can read it. The purpose tells you why it exists: keeping a visitor logged in, remembering a preference, measuring visits, or targeting advertising. The duration tells you how long it persists: a session cookie disappears when the browser closes, while a persistent cookie can last months or years. A cookie with a long duration and an advertising purpose is a different matter from a session cookie that keeps a shopping basket intact, and an inventory that records all four attributes lets you tell the difference at a glance.

What to know before you start

Begin by separating first-party cookies from third-party cookies. First-party cookies are set by the site the visitor is actually visiting, and they usually serve the site's own functions: login sessions, security tokens, language preferences, and basket contents. Third-party cookies are set by other domains through embedded content, and they usually serve the embed provider's purposes: analytics, advertising, or cross-site tracking. The distinction matters because the site owner directly controls the first group and only indirectly influences the second, by choosing which embeds to keep. An inventory that mixes the two hides the decisions that matter most, which are usually about embeds.

Next, sort by purpose into a small set of plain categories: strictly necessary, preferences, analytics, and marketing. Strictly necessary cookies keep the site working: login, security, and load balancing. Preference cookies remember choices like language or region. Analytics cookies measure visits and behaviour in aggregate. Marketing cookies track visitors across sites for advertising. The categories are not always clean, and a single service can set cookies in more than one category, but sorting forces the question that an unsorted list avoids: for each cookie, what does the visitor get in return for it being set? Cookies with no good answer are candidates for removal.

Duration deserves its own pass through the list. A preference cookie lasting a year is reasonable; an analytics cookie lasting two years deserves a question; a marketing cookie lasting several years deserves a challenge. Long durations are often defaults inherited from a provider's standard settings, not deliberate choices by the site owner. Shortening a duration where the purpose does not require a long one is a simple, defensible improvement, and it is the kind of change an inventory makes possible, because you cannot shorten what you have not listed.

A worked example you can follow

Take a sample site whose scan returns 24 cookies. Suppose 8 are first-party and 16 are third-party, so third-party cookies are two-thirds of the total, because 16 divided by 24 equals roughly 67 percent. Of the 16 third-party cookies, suppose 6 come from an analytics service, 6 from a video embed, and 4 from a social sharing widget. The picture is immediately actionable: the site's own cookies are a minority, and three embeds account for all of its third-party exposure. Removing the social widget, if sharing buttons are rarely used, would cut the total from 24 to 20, a reduction of about 17 percent, and removing the video embed's tracking cookies by using a privacy-enhanced embed could cut it further.

Now sort the same 24 by purpose. Suppose 5 are strictly necessary, 3 are preferences, 8 are analytics, and 8 are marketing. The marketing cookies, at 8 of 24, are one-third of the inventory, and if the site's privacy page mentions only necessary and analytics cookies, the disclosure is missing a third of what visitors actually receive. The fix is not to hide the cookies but to disclose them accurately, and then to decide whether all 8 marketing cookies are worth keeping. A site that earns nothing from a marketing cookie has no reason to carry it, and the inventory is the evidence that makes removal an easy decision rather than a debate.

Check durations in the same sample. If 10 of the 24 cookies last longer than a year, that is 10 divided by 24, or about 42 percent, persisting for more than twelve months. For each of those ten, ask whether the purpose genuinely needs that duration. A login cookie that lasts a year on a personal device may be fine; an analytics identifier that lasts two years on a site visited twice a year is harder to justify. Record the decision for each long-lived cookie, so the next inventory can check whether the durations changed as intended.

Common mistakes to avoid

The first mistake is scanning only the home page. Cookies differ by page: a video page sets video cookies, a checkout page sets payment cookies, and a blog page with social buttons sets sharing cookies. Scan the pages visitors actually use, including the ones with embeds, or the inventory will miss exactly the cookies that matter. The second mistake is treating the inventory as a one-off project. Every new plugin, embed, or analytics tool changes the list, so re-scan after changes and on a schedule, not just when a complaint arrives.

The third mistake is copying cookie descriptions from a provider's marketing page instead of describing what the cookie does in plain language. Visitors and regulators alike are better served by a short, honest description: what is stored, why, and for how long. The fourth mistake is confusing a scanner's observation with permission: the fact that a cookie is listed does not mean it is allowed, and the fact that it is common does not mean it is appropriate for your site. The inventory informs the decision; it does not make it.

Checking the result before you finish

After the scan, work through the inventory in three passes: remove what is not needed, shorten what lasts too long, and disclose what remains accurately. Update the privacy and cookie pages to match the final list, naming the categories and purposes in plain language, and keep the inventory itself as an internal record with dates. Then re-scan to confirm the removals took effect, because removing a plugin does not always remove its cookies, and an embed can set cookies through a chain of further embeds that survive the first cleanup.

For companion checks, the Cookie Security Checker Guide explains the security side of cookie settings, the SSL Certificate Checker tool covers the encrypted connection cookies travel over, and the Ads.txt Checker tool covers a related site-declaration file. A dated inventory, refreshed after every site change, is a small discipline that keeps disclosures honest and surprises rare.