Skip to main content
Cookie Gate
The state of ai impact assessment
Category: Google Consent Mode

Default Consent State

Also known as: Default Consent Values, Consent Mode Defaults
Simply put

A default consent state is the starting setting that tells tracking and tagging tools whether they may collect or use data before a user has actually made a choice. In consent management setups such as Google Consent Mode, this default is typically configured to "denied" so that no data is gathered until the user has expressed a preference. Once the user responds to a consent banner, an update replaces the default with their actual choice.

Formal definition

The default consent state is the initial value assigned to one or more consent parameters (for example, analytics or advertising storage) that governs how tags and tracking technologies behave before any user consent signal is captured. In frameworks like Google Consent Mode, practitioners are generally advised to set default values to "denied" and to fire an update call immediately after the user interacts with the consent interface; a default that is not set before tags execute can cause errors such as a tag reading consent state before a default was defined. Configuring defaults appropriately is a technical control that supports, but does not by itself guarantee, compliance: under EU and UK rules the ePrivacy regime governs the placing of and access to information on a device (typically requiring prior consent for non-essential cookies and similar technologies), while the GDPR governs any resulting processing of personal data. A default of "denied" is intended to align technical behavior with a prior-consent (opt-in) model common in the EU, but the lawfulness of any given configuration depends on the applicable jurisdiction, the categories of technologies involved, and facts beyond the scope of this definition; US state privacy laws such as the CCPA and CPRA often follow an opt-out model, so appropriate default behavior may differ. The evidence available here addresses the technical configuration of defaults rather than resolving these jurisdiction-specific legal questions.

Why it matters

The default consent state determines how tracking and tagging tools behave in the window before a user has interacted with a consent banner, a period that exists on virtually every page load. Because tags may fire quickly, a misconfigured or absent default can result in data being collected before any user choice is captured. In the EU and UK, where the ePrivacy regime generally requires prior consent for non-essential cookies and similar technologies, and where the GDPR governs any resulting processing of personal data, setting defaults to "denied" is a common technical measure intended to align tool behavior with a prior-consent (opt-in) model.

Getting the default configuration wrong has both technical and compliance implications. On the technical side, a default that is not defined before tags execute can produce errors such as a tag reading consent state before a default was set, which practitioners may encounter in tools like Google Tag Manager preview mode. On the compliance side, allowing collection before a user has expressed a preference can undermine the prior-consent approach expected in many EU jurisdictions. It is important to stress, however, that a default of "denied" is a supporting control rather than a guarantee of compliance; lawfulness depends on the applicable jurisdiction, the categories of technologies involved, and facts beyond the scope of a default setting.

Defaults are not a one-size-fits-all answer across regimes. US state privacy laws such as the CCPA and CPRA often follow an opt-out model, so the appropriate default behavior may differ from the opt-in expectations common in the EU and UK. Organizations operating across multiple jurisdictions therefore need to consider how their default configuration maps to each applicable legal framework rather than assuming a single setting satisfies all of them.

Who it's relevant to

Web developers and tag management practitioners
Those implementing tools like Google Tag Manager and Google Consent Mode are responsible for defining default consent values before tags execute and for firing an update call after the user interacts with the consent interface. Correct configuration helps prevent both premature data collection and technical errors such as a tag reading consent state before a default was set.
Privacy officers and data protection professionals
Default consent settings are one of the technical controls that support a prior-consent model common in the EU and UK. These professionals need to assess whether the chosen defaults align with the applicable ePrivacy and GDPR obligations, while recognizing that a default setting supports rather than guarantees compliance.
Legal counsel and compliance teams operating across jurisdictions
Because EU and UK rules generally follow an opt-in approach while US state laws such as the CCPA and CPRA often follow an opt-out model, counsel should evaluate whether default configurations are appropriate for each jurisdiction in which the organization operates, rather than assuming a single default satisfies every framework.
Marketing and analytics teams
Teams relying on analytics and advertising tags should understand that a default of "denied" prevents data collection until a user responds, which affects the completeness of collected data. This helps them set realistic expectations about measurement while operating within the organization's consent configuration.

Inside Default Consent State

Pre-consent cookie behavior
The default consent state defines what happens to non-essential cookies and similar technologies (such as pixels, SDKs, and local storage) before a user makes an active choice. In most EU jurisdictions, under the ePrivacy Directive and GDPR, these should not be set or accessed until the user has given valid prior consent.
Opt-in versus opt-out defaults
The default state reflects the underlying legal model. EU and UK frameworks generally require an opt-in default, meaning non-essential cookies remain off until consent is given, whereas several US state regimes (such as California's CCPA/CPRA) typically operate on an opt-out basis, where certain processing may occur until the user objects.
Treatment of exempt categories
Strictly necessary or essential cookies are generally exempt from consent and may load in the default state, while analytics, advertising, and functional cookies typically require prior consent under EU law and should be disabled by default there.
CMP configuration
A consent management platform enforces the default state by determining which categories are active before interaction. Correct configuration is what translates a chosen legal position into actual technical behavior, though it does not by itself guarantee compliance.
Signal-driven defaults
The default state may respond to automated preference signals such as Global Privacy Control, which some regimes treat as a valid opt-out. Whether and how such signals must alter the default varies by jurisdiction and evolving guidance.

Common questions

Answers to the questions practitioners most commonly ask about Default Consent State.

Does setting a 'default consent' state mean users have already consented to non-essential cookies?
No. A default consent state that treats users as having consented before they take any action is generally incompatible with EU requirements. Valid consent under the GDPR must be freely given, specific, informed, and unambiguous, and it requires a clear affirmative action. Pre-ticked boxes and implied consent inferred from continued browsing are widely considered non-compliant in most EU jurisdictions. A pre-consent default should therefore typically be set so that non-essential cookies are not placed or accessed until the user makes an affirmative choice. Note that opt-out-based frameworks, such as certain US state privacy laws, may approach defaults differently, so the geographic scope matters.
If our default state blocks non-essential cookies until a choice is made, does that guarantee we are compliant?
Not on its own. A privacy-protective default is an important component, but it does not by itself guarantee compliance. Compliance also depends on factors such as the clarity and accuracy of the information provided, how strictly necessary cookies are categorized, whether consent is genuinely freely given, how consent is logged and honored, and whether the design avoids manipulative patterns. Configuration tools and consent management platforms support these obligations but do not replace legal judgment. Requirements and enforcement positions also vary between the EU, the UK, and individual US states, so a single default setting cannot be treated as universally sufficient.
What should the default state be before a user interacts with a consent banner?
In most EU jurisdictions, the pre-interaction default should be that non-essential cookies and similar technologies (such as pixels, SDKs, local storage, and fingerprinting techniques) are not placed or read until the user provides consent through a clear affirmative action. Strictly necessary or essential cookies are generally exempt and may load by default. The precise line between essential and non-essential can be contested and fact-dependent, so categorization should be reviewed carefully. Under opt-out-oriented US state frameworks, the appropriate default may differ, so scope should be confirmed for each audience.
How do we handle the default state for returning users who have not yet made a choice?
Where a user has not previously expressed a valid choice, or where a prior record cannot be reliably associated with the user, the default should generally remain the pre-consent state in EU-facing contexts, meaning non-essential technologies are not activated until an affirmative choice is made. This depends on your ability to store and retrieve a consent record, which itself may rely on a cookie or similar identifier. The specifics, including how long a prior choice should be relied upon before re-prompting, can depend on guidance that varies by jurisdiction and evolves over time.
Should the default state apply differently across cookie categories?
Yes. It is common to treat categories differently based on their consent status. Strictly necessary cookies are generally exempt from consent and can be treated as active by default. Analytics, advertising, and functional cookies typically require prior consent under EU law and should default to inactive until the user opts in. This category-by-category approach helps ensure that only exempt technologies operate before a choice is made. Where a technology is not literally a cookie but performs a comparable function, it generally falls within the same rules and should be handled under the corresponding category default.
How should the default state interact with signals such as Global Privacy Control?
Where a user's browser or device transmits a preference signal, such as Global Privacy Control, the default state may need to reflect that signal rather than a generic setting. In frameworks that recognize such signals, an incoming opt-out or preference can indicate the applicable default before any banner interaction. Whether and how a given signal must be honored depends on the applicable legal regime and evolving regulatory expectations, which differ between the EU, the UK, and individual US states. Because recognition and enforcement of these signals continue to develop, the handling of signal-driven defaults should be reviewed against current guidance for each relevant jurisdiction.

Common misconceptions

Setting cookies by default and letting users opt out is compliant everywhere.
This reflects an opt-out model that may be workable under some US state laws, but in most EU jurisdictions non-essential cookies must remain off by default until the user gives a clear affirmative consent. The lawful default depends on the applicable jurisdiction.
A default state of pre-ticked or pre-enabled non-essential categories counts as consent once the user proceeds.
Under the GDPR, consent must be freely given, specific, informed, and unambiguous through a clear affirmative action. Pre-ticked boxes and implied consent from continued browsing are widely considered non-compliant in the EU, so such defaults do not establish valid consent.
Configuring a CMP's default state correctly makes a site compliant.
A CMP supports compliance by enforcing the chosen default, but it does not replace legal judgment. The appropriate default depends on jurisdiction, cookie categorization, and current regulatory positions, all of which require assessment beyond the tool itself.

Best practices

Default all non-essential cookies and similar technologies (pixels, SDKs, local storage) to off in EU and UK contexts, allowing them to load only after valid prior consent.
Map your default state to each applicable jurisdiction rather than applying one configuration globally, recognizing that EU/UK opt-in expectations differ from opt-out models under several US state laws.
Carefully categorize cookies so that only genuinely strictly necessary items load in the default state, and keep analytics, advertising, and functional cookies disabled until consent where required.
Avoid pre-ticked boxes or defaults that treat continued browsing as consent, since these are widely regarded as non-compliant in the EU.
Configure and test your CMP to confirm the intended default behavior actually occurs, while treating the tool as support for, not a substitute for, legal review.
Assess how automated signals such as Global Privacy Control should affect your default state in relevant jurisdictions, and document the reasoning, noting that requirements in this area continue to evolve.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide