What should a GDPR cookie table include?

Cookie name, the domain that set it, first or third party, purpose, recipient, retention period, and ideally whether it is set before or after consent. Accuracy matters more than format; no specific layout is mandated.

Where do I get the cookie list for my site?

From a scan of the live site in a clean browser session, not from a template. A scan here returns name, host, vendor, category and first-seen timing for both the pre-consent and post-consent states.

How often should the cookie table be updated?

Whenever the site's tags change, which is why re-scanning on a schedule beats a calendar reminder. Most tables go stale because a marketing tag was added, not because a developer shipped a release.

Published 2026-09-02

Cookie Table for GDPR — How to Build One From a Real Scan

ConsentProof is a cookie consent checker that scans any website with a real browser and records which cookies and third-party trackers fire before the visitor consents.

The columns that matter

Name, the host that set it, first or third party, purpose category, who receives the data, retention, and whether it is set before or after consent. The last column is the one templates never have, and the one that makes the table useful to you rather than only to a reader.

Categories should come from a source you can cite. We classify against the Open Cookie Database, a public dataset, and keep the entry id so any row can be traced back.

Unclassified is a legitimate value

Some cookies have no public classification, particularly first-party ones set by your own application. Writing 'Unclassified' and then finding out is honest; guessing 'Functional' because it sounds harmless is how a cookie table becomes a document nobody can defend.

For your own first-party cookies, the answer is usually a five-minute question to a developer, and then the table is right permanently.

Keeping it true

A cookie table is accurate on the day it is written. Re-scan on a schedule and compare; the only cheap way to keep the document true is to be told when the site diverges from it.

That is the difference between a scan and monitoring, and it is the reason the paid plans exist at all.

Frequently asked

What should a GDPR cookie table include?: Cookie name, the domain that set it, first or third party, purpose, recipient, retention period, and ideally whether it is set before or after consent. Accuracy matters more than format; no specific layout is mandated.
Where do I get the cookie list for my site?: From a scan of the live site in a clean browser session, not from a template. A scan here returns name, host, vendor, category and first-seen timing for both the pre-consent and post-consent states.
How often should the cookie table be updated?: Whenever the site's tags change, which is why re-scanning on a schedule beats a calendar reminder. Most tables go stale because a marketing tag was added, not because a developer shipped a release.

Try ConsentProof

Free public scan, no account needed.

Start free Pricing