# Cookie declaration: the list your visitors actually see

How FlowConsent generates the cookie list from active services, how to add custom cookies, and how the undeclared-cookie alert keeps it honest.

> Canonical: https://www.flowconsent.com/en/doc/cookie-declaration
> Last updated: 2026-07-30
The cookie list shown to visitors is generated, not hand-written: the **Cookie list** tab of the Builder derives it from your active services, and you only add by hand the cookies no catalog service can know about. The Compliance page then closes the loop — if a scan observes a cookie your banner doesn't declare, you get an alert with a one-click fix.

## Auto-generated from your services

For every active service, the catalog contributes its cookies to the matching category — essential, analytics, marketing or preferences. Each entry carries the fields a declaration needs:

- **name** — e.g. `_GRECAPTCHA`, `ph_phc_*`
- **purpose** — what the cookie is for, in visitor-readable words
- **provider** — who sets it (defaults to the service name)
- **duration** — as it must be displayed to visitors, e.g. "6 months"
- **type** — first-party or third-party

Auto-generated entries are read-only: they update with the catalog, so you never maintain Google's cookie lifetimes by hand. The tab shows the total and how many entries are auto-generated.

> [!NOTE]
> The cookie data lives in the FlowConsent database catalog, which is enriched over time (reCAPTCHA, PostHog, Sentry, Intercom…). Picking the canonical service matters: an alias entry would contribute no cookies — see [canonical IDs](/en/doc/services-and-legal-basis).

## Custom cookies

Your own first-party cookies — a cart session, an attribution cookie set by your backend — come from no catalog service. Add them per category with **Add a cookie**, filling the same five fields (name, purpose, provider, duration, type first-party/third-party). Custom entries are merged with the auto-generated list in the banner.

## The undeclared-cookie alert

Declaring what you *think* you set is not enough; the list must reflect what is **actually** set. On the [Compliance page](/en/doc/compliance-verification), FlowConsent compares the cookies observed by your latest scan against everything your banner declares — active services plus custom cookies, matched by name, case-insensitively. Anything observed but undeclared triggers an alert listing each cookie with its domain and whether it is first-party or third-party.

One click on **Declare these cookies in the banner** adds them all to your custom cookies:

- the **category is guessed** from the name: known analytics prefixes (`_ga`, `_pk_`, `_hj`, `ph_`, `mp_`, `amplitude`…) go to analytics; everything else goes to **marketing**, the most demanding category — better to over-ask consent than the reverse;
- the observed **domain, duration and type** are carried over;
- the **purpose is left empty** — no scanner can know why your cookie exists.

> [!IMPORTANT]
> After declaring, finish the job: open the Builder's Cookie list tab, write a purpose for each new entry, re-categorize if the guess was wrong, then **republish the banner** — the declaration only reaches visitors on the next deployment.

## Next steps

- [Services and legal bases](/en/doc/services-and-legal-basis)
- [Run a compliance verification](/en/doc/compliance-verification)
- [Customize how the banner presents it all](/en/doc/banner-customization)