UX Patterns Guide

Application · lesson 7 of 21 · Trust, Safety, And Privacy

Cookie consent

Underlying principle: Trust grows when purpose, consequence, status, and control are visible at the point of decision. Sensitive tasks also need a safe route for correction and exit.

Build a cookie consent flow that separates essential and optional purposes, blocks optional storage before consent, provides equal accept and reject routes, records purpose-level evidence, handles region and browser signals, supports withdrawal and renewal, and verifies runtime tags against the stored consent state.

Start with the decision

Does this fit your task?

The service needs purpose-level runtime enforcement and an evidence record for optional storage choices.

Review the boundary: Compare the task with the alternatives in the decision section.

Review the decision →
Try the live example →Compare alternatives →
Study the interaction

Follow the task before choosing the component

Trust grows when purpose, consequence, status, and control are visible at the point of decision. Sensitive tasks also need a safe route for correction and exit.

01 / Recognize the need

What the person is doing

Cookie consent applies to cookies and similar technologies such as local storage, pixels, tags, analytics SDKs, advertising identifiers, personalization storage, service-worker storage, and device access for tracking purposes.

02 / Design the response

What the interface must communicate

Build a cookie consent flow that separates essential and optional purposes, blocks optional storage before consent, provides equal accept and reject routes, records purpose-level evidence, handles region and browser signals, supports withdrawal and renewal, and verifies runtime tags against the stored consent state.

Pre-consent state with optional storage blocked.

03 / Judge the outcome

What to look for

Which cookies, storage APIs, tags, SDKs, and server identifiers are strictly necessary versus optional?

Optional cookies, pixels, local storage, analytics tags, advertising tags, and similar technologies remain blocked until the matching purpose is accepted.

Practice this pattern: Sketch cookie consent for this situation: The service needs purpose-level runtime enforcement and an evidence record for optional storage choices. Include this state: Pre-consent state with optional storage blocked. Review your sketch with this question: Which cookies, storage APIs, tags, SDKs, and server identifiers are strictly necessary versus optional?

Study the Trust, Safety, And Privacy family →Read the underlying principle →
Decision first

Choose this pattern when the problem matches

Use when

  • The service needs purpose-level runtime enforcement and an evidence record for optional storage choices.
  • Users must be able to accept, reject, manage, renew, and withdraw cookie choices.

Avoid when

  • The product only needs to show the first-layer cookie notice; use cookie banner.
  • The decision is optional data use unrelated to cookies or similar technologies; use consent prompt.
  • The user is managing all account privacy controls; use privacy settings.
  • The user is accepting terms or policies; use legal acceptance.

Problem it prevents

Cookie consent applies to cookies and similar technologies such as local storage, pixels, tags, analytics SDKs, advertising identifiers, personalization storage, service-worker storage, and device access for tracking purposes.

Test the behavior

Try strong and weak versions of the interaction

Open the working example, try its controls, and compare the behavior against the decision guidance.

In the lab you can
  • switch between strong UI, weak UI, strong UX, and weak UX;
  • trigger required, empty, loading, error, and recovery states;
  • inspect keyboard and accessibility expectations beside the demo.
Launch Cookie consent in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

Cookie consent applies to cookies and similar technologies such as local storage, pixels, tags, analytics SDKs, advertising identifiers, personalization storage, service-worker storage, and device access for tracking purposes.

Pattern promise

Build a cookie consent flow that separates essential and optional purposes, blocks optional storage before consent, provides equal accept and reject routes, records purpose-level evidence, handles region and browser signals, supports withdrawal and renewal, and verifies runtime tags against the stored consent state.

Required state

Pre-consent state with optional storage blocked.

Failure to inspect

Optional storage runs before consent.

Access contract

Use native buttons and form controls for accept, reject, save, and purpose choices.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A cookie settings page shows essential cookies locked on, analytics, personalization, and advertising off by default, plus Accept all, Reject all, Save choices, and a vendor details panel.
  • A runtime consent inspector shows analytics tags blocked until the analytics purpose is saved and advertising tags blocked because a browser privacy signal is active.
  • A user rejects all optional cookies, continues using the service, later opens Cookie settings, enables analytics only, receives a saved confirmation, and can withdraw again.
  • A new advertising purpose is added, so the service treats the prior consent as stale and asks again before loading advertising tags.
Weak implementation

Vague, hidden, hard to recover from

  • A second-layer settings panel has all optional cookie categories preselected and a prominent Save button.
  • The user closes the banner and the product treats inactivity as consent to advertising cookies.
  • Optional storage runs before consent.
  • Consent is inferred from inactivity, scrolling, swiping, or closing.
UI guidance
  • Present strictly necessary storage separately from optional cookie purposes such as analytics, advertising, personalization, functional enhancements, pixels, SDKs, and similar technologies.
  • Use off-by-default optional controls, comparable accept and reject routes, purpose details, vendor or tag visibility where relevant, and a clear save or withdraw action tied to the runtime state.
UX guidance
  • Use cookie consent when the user must decide which non-essential storage or tracking purposes can run before optional cookies, tags, pixels, local storage, or SDKs are activated.
  • Make the consent durable and reversible by recording purpose, version, region, timestamp, source surface, browser signal, and withdrawal state, then enforcing that record before optional scripts run.
Implementation contract

What the implementation must handle

States

  • Pre-consent state with optional storage blocked.
  • Strictly necessary explanation state.
  • Accept all optional purposes state.
  • Reject all optional purposes state.

Interaction

  • Optional cookies, pixels, local storage, analytics tags, advertising tags, and similar technologies remain blocked until the matching purpose is accepted.
  • Accept all and reject all actions are reachable with comparable effort, prominence, keyboard access, and language clarity.
  • Granular choices start off unless a current valid consent record already exists for the same purpose, version, and region.
  • Saving consent writes a purpose-level record with version, timestamp, region, source surface, browser signal state, and withdrawal route.

Accessibility

  • Use native buttons and form controls for accept, reject, save, and purpose choices.
  • Associate each purpose toggle with a concise purpose explanation and optional details.
  • Keep purpose tables, vendor details, and controls readable at high zoom and compact widths.
  • Tab reaches Accept all, Reject all, Manage, purpose toggles, vendor details, Save choices, and withdrawal routes in a predictable order.

Review

  • Which cookies, storage APIs, tags, SDKs, and server identifiers are strictly necessary versus optional?
  • What proves optional storage is blocked before consent and after withdrawal?
  • Can users reject all optional purposes with comparable effort to accepting all?
  • Are optional purposes off by default and saved separately?
Evidence trail

Source-backed claims behind this guidance

ICO cookies and similar technologies guidance

Information Commissioner's Office - checked

Supports clear information, active consent, no optional cookies before consent, strictly necessary exemptions, user controls, and consent records.

EDPB Cookie Banner Taskforce report

European Data Protection Board - checked

Supports reject-option, pre-ticked-box, deceptive-link, contrast, essential-cookie, and withdrawal rules for cookie consent interfaces.

CNIL cookies and tracking devices guidelines

Commission Nationale de l'Informatique et des Libertes - checked

Supports no tracking before consent, no scroll or swipe consent, continued access after refusal, proof of consent, and easy withdrawal.

GOV.UK cookie banner component

GOV.UK Design System - checked

Supports the relationship between the cookie banner entry surface and the saved cookie preference.

Full agent/debug reference

Problem Context

  • Cookie consent applies to cookies and similar technologies such as local storage, pixels, tags, analytics SDKs, advertising identifiers, personalization storage, service-worker storage, and device access for tracking purposes.
  • The consent mechanism may be launched from a cookie banner, cookies page, privacy settings, preference center, footer link, first-run flow, or regional compliance surface.
  • Strictly necessary storage is handled differently from optional analytics, advertising, personalization, functional, social media, and measurement purposes.
  • Cookie consent is a runtime contract: the UI, consent record, tag manager, server rendering, and client storage must all agree before optional technologies run.

Selection Rules

  • Choose cookie consent when the decision controls cookies, pixels, local storage, tags, SDKs, or similar storage and access on the user's device.
  • Use cookie banner for the first-layer notice that introduces cookie choices, not for the entire consent management model.
  • Use consent prompt for optional data use that is not specifically cookie or similar device storage.
  • Use preference center when the user returns to a durable hub that includes cookies alongside communication, topic, language, and privacy preferences.
  • Use privacy settings for broader account, device, data-sharing, and product privacy controls.
  • Use legal acceptance for terms or policy agreement; do not bundle legal acceptance with cookie consent.
  • Refresh cookie consent when purposes, vendors, region rules, storage types, controller, or consequences materially change.
  • Treat browser privacy signals and regional requirements as inputs to consent enforcement, not as decorative status text.

Required States

  • Pre-consent state with optional storage blocked.
  • Strictly necessary explanation state.
  • Accept all optional purposes state.
  • Reject all optional purposes state.
  • Granular purpose choices state.
  • Vendor or tag details state.
  • Saved consent record state.
  • Return visit state with stored preferences applied.
  • Withdrawal or change preferences state.
  • Renewal after version or purpose change state.
  • Expired consent state.
  • Browser privacy signal or Global Privacy Control state.
  • No-JavaScript server-side preference state.
  • Runtime mismatch or tag blocked state.
  • Mobile compact consent state.

Interaction Contract

  • Optional cookies, pixels, local storage, analytics tags, advertising tags, and similar technologies remain blocked until the matching purpose is accepted.
  • Strictly necessary storage is identified separately and is not represented as optional consent.
  • Accept all and reject all actions are reachable with comparable effort, prominence, keyboard access, and language clarity.
  • Granular choices start off unless a current valid consent record already exists for the same purpose, version, and region.
  • Saving consent writes a purpose-level record with version, timestamp, region, source surface, browser signal state, and withdrawal route.
  • Withdrawal or reject-all stops future optional storage and updates the consent record rather than only hiding the interface.
  • Adding or changing optional purposes triggers a renewal flow before new tags run.
  • Runtime enforcement reports blocked, allowed, stale, unknown, failed-write, and signal-conflict states.

Implementation Checklist

  • Inventory all cookies, pixels, tags, SDKs, local storage, service-worker storage, and server-set identifiers before designing the UI.
  • Classify each item as strictly necessary or optional with purpose, vendor, lifetime, region, source, and runtime owner.
  • Block optional technologies before consent in both server-rendered and client-rendered paths.
  • Provide accept all, reject all, granular save, purpose details, vendor details, and withdrawal routes with comparable effort.
  • Record purpose-level consent version, timestamp, region, controller, source surface, browser signal, and withdrawal state.
  • Handle return visits, stale versions, new purposes, browser privacy signals, no-JavaScript submission, failed record writes, and tag-manager mismatches.
  • Verify with network or tag inspection that optional storage does not run before consent and stops after withdrawal.
  • Keep cookie consent separate from legal acceptance, marketing email opt-in, notification preferences, and broad privacy settings.

Common Generated-UI Mistakes

  • Firing analytics or advertising tags before the user chooses.
  • Using one accepted flag instead of purpose-level consent records.
  • Preselecting optional categories in the settings layer.
  • Making Accept all much easier to find than Reject all.
  • Treating scrolling, swiping, closing, inactivity, or continued browsing as consent.
  • Hiding withdrawal after the banner disappears.
  • Claiming advertising cookies are strictly necessary without a defensible classification.
  • Letting tag-manager configuration drift away from saved consent choices.

Critique Questions

  • Which cookies, storage APIs, tags, SDKs, and server identifiers are strictly necessary versus optional?
  • What proves optional storage is blocked before consent and after withdrawal?
  • Can users reject all optional purposes with comparable effort to accepting all?
  • Are optional purposes off by default and saved separately?
  • What consent version, region, timestamp, source surface, and browser signal are recorded?
  • How does the product handle new purposes, expired consent, no-JavaScript users, and failed record writes?
  • Where can users later withdraw or change cookie consent after the banner is gone?
Accessibility
  • Use native buttons and form controls for accept, reject, save, and purpose choices.
  • Do not rely on color, size, or link styling to make reject harder to perceive.
  • Associate each purpose toggle with a concise purpose explanation and optional details.
  • Expose saved, blocked, stale, and failed consent states through status text without forcing focus jumps.
  • Keep purpose tables, vendor details, and controls readable at high zoom and compact widths.
  • Preserve keyboard order across first layer, details, save, reject, withdrawal, and no-JavaScript fallback.
Keyboard Behavior
  • Tab reaches Accept all, Reject all, Manage, purpose toggles, vendor details, Save choices, and withdrawal routes in a predictable order.
  • Space toggles checkbox or switch controls according to native behavior.
  • Enter activates buttons and links without treating page scroll or dismissal as consent.
  • After saving, focus moves to confirmation or remains near the saved controls with status announced.
  • After withdrawal, focus moves to the updated consent status and runtime-blocking confirmation.
  • No optional storage should depend on a keyboard shortcut, hover-only reveal, or pointer-only gesture.
Variants
  • Purpose-level cookie consent
  • Cookie settings page
  • Cookie preference center
  • Accept all and reject all
  • Granular purpose toggles
  • Vendor details
  • Consent evidence record
  • Withdrawal route
  • Consent renewal
  • Browser privacy signal handling
  • No-JavaScript consent form
  • Runtime tag audit

Verification

Source trail checked:

Saved items