Skip to main content
Cookie Gate
Dark green background, "Weak Application Security Can Cost You Millions," 3 slanted images of fingers pointing to digital locks, and a "Learn the Basics" button
Category: Consumer Privacy Rights

Sec-GPC Header

Also known as: Sec-GPC, Sec-GPC request header, GPC header field
Simply put

The Sec-GPC header is a small piece of information sent by a web browser or extension with a user's web requests to tell a website that the user does not want their personal information sold or shared. It is one part of the broader Global Privacy Control (GPC) mechanism, which is designed to let people express a privacy preference automatically rather than site by site. Whether a website is legally required to honor this signal depends on the applicable law and jurisdiction.

Formal definition

The Sec-GPC header field is an HTTP request header that forms part of the Global Privacy Control (GPC) mechanism for expressing a person's general, universal preference regarding a do-not-sell-or-share interaction. When enabled at the browser or extension level, the header communicates the user's opt-out preference to servers as part of outgoing HTTP requests, allowing the preference to be signaled without per-site interaction. GPC is described in the referenced sources as a proposed specification and set of web technologies; the legal effect of receiving the Sec-GPC signal is not established by the header itself but by applicable privacy regimes. Notably, several US state privacy frameworks operate on an opt-out model under which such signals may be relevant, whereas the technical presence of the header does not, on its own, determine obligations under any particular jurisdiction. This definition covers the header as a signaling mechanism; the specific enforcement obligations, the scope of covered businesses, and the required server-side response are governed by law and applicable regulatory guidance not detailed in the evidence provided.

Why it matters

The Sec-GPC header addresses a practical problem in privacy compliance: without an automated mechanism, users would need to express their preferences site by site, which is impractical across the number of websites a person visits. As part of the broader Global Privacy Control mechanism, the header allows a do-not-sell-or-share preference to travel with a user's web requests, so that a single browser or extension setting can communicate that preference to many sites at once. For businesses, this shifts part of the compliance burden from asking users repeatedly to detecting and responding to a signal already present in incoming requests.

The legal significance of the signal varies by jurisdiction, and this distinction is central to understanding its relevance. Several US state privacy frameworks operate on an opt-out model under which a signal such as GPC may be relevant to a business's obligations, but the presence of the Sec-GPC header does not, on its own, determine what any particular law requires. Whether a business must honor the signal, which businesses are covered, and what the required server-side response looks like are questions governed by applicable law and regulatory guidance rather than by the header itself. Organizations should treat detection of the signal as one input into a compliance program, not as a self-contained legal answer.

Because GPC is described in its underlying sources as a proposed specification and a set of web technologies, its technical form and its adoption continue to evolve. Teams evaluating how to respond to the Sec-GPC header should confirm the obligations that apply in each jurisdiction where they operate, since enforcement positions and guidance can differ and may change over time. Relying solely on the technical presence or absence of the header to assess legal exposure risks conflating a signaling mechanism with a legal determination.

Who it's relevant to

Privacy officers and data protection professionals
Those responsible for privacy programs need to understand where GPC signals may factor into their obligations, particularly under US state frameworks that operate on an opt-out model. Because the legal effect of receiving the signal is set by applicable law rather than by the header itself, privacy teams should treat signal detection as one component of a compliance program and confirm the requirements that apply in each relevant jurisdiction.
Web developers and engineering teams
Developers may need to detect the Sec-GPC header in incoming HTTP requests and route that information into systems that manage user preferences. Understanding that the header is a signaling mechanism, not a definition of required behavior, helps engineering teams build detection and response logic in coordination with legal guidance on what the response should be.
Legal counsel and compliance teams
Counsel advising on whether and how a business must honor GPC signals need to distinguish the technical presence of the header from the obligations imposed by particular privacy laws. Since covered-business definitions, required responses, and enforcement positions are governed by law and regulatory guidance that vary by jurisdiction and may evolve, legal judgment remains essential to interpreting the signal's effect.
Marketing and adtech compliance teams
Because GPC is designed to express a do-not-sell-or-share preference, teams managing advertising and data-sharing arrangements should understand how an incoming signal may affect the sale or sharing of personal information where applicable law makes it relevant, and coordinate with legal and engineering colleagues on the appropriate treatment.

Inside Sec-GPC Header

HTTP request header
The Sec-GPC header is an HTTP request header transmitted by a user's browser or extension to a web server, signaling the user's preference not to have their personal data sold or shared.
Binary value
The header typically carries a value of '1' to indicate that Global Privacy Control is enabled, communicating the user's opt-out preference. The absence of the header generally means no such signal is being expressed rather than an affirmative choice to permit sale or sharing.
Secure ('Sec-') prefix
The 'Sec-' prefix designates the header as a forbidden header name that cannot be set programmatically via client-side scripts, meaning it is controlled by the browser or user agent rather than arbitrary web page code.
Transport mechanism for Global Privacy Control
The header is the technical means by which the Global Privacy Control (GPC) signal is conveyed. GPC may also be exposed to web pages through a corresponding JavaScript property, but the Sec-GPC header is the server-facing component.
Opt-out signal in scope
The signal is oriented toward opt-out privacy frameworks, most notably certain US state privacy laws such as California's regime under the CCPA/CPRA, where it may be treated as a request to opt out of sale or sharing. Its legal effect depends on the applicable jurisdiction.

Common questions

Answers to the questions practitioners most commonly ask about Sec-GPC Header.

Does receiving the Sec-GPC header mean a user has withdrawn consent to all cookies?
No. The Sec-GPC header communicates a specific privacy preference rather than a blanket withdrawal of all cookie consent. In practice, it signals a user's intent to opt out of certain processing, most notably the sale or sharing of personal data as those terms are defined under some US state privacy laws such as California's CPRA. It is not designed as, and should not be treated as, a general revocation of consent for all cookie categories under EU-style opt-in regimes. Under the ePrivacy rules and GDPR consent standard applicable in most EU jurisdictions, valid consent generally requires a clear affirmative action, and the absence or presence of this header does not by itself establish or remove that consent. Its exact legal effect depends on the applicable jurisdiction and how the relevant law treats browser-based opt-out signals.
Is honoring the Sec-GPC header legally required everywhere?
No. Obligations to recognize browser-based opt-out signals are not universal and vary by jurisdiction. Certain US state privacy frameworks, such as those in California, have taken the position that opt-out preference signals must be honored as valid requests to opt out of sale or sharing, but the specifics differ between states and continue to evolve. In the EU and UK, the primary consent model is generally opt-in under the ePrivacy rules and GDPR, and there is no established, harmonized requirement that a Sec-GPC signal alone satisfies or replaces the applicable consent or objection mechanisms. Because enforcement positions and regulatory guidance continue to develop, you should confirm the current requirements for each jurisdiction in which you operate rather than assume a single global rule.
How does a website detect the Sec-GPC signal?
The signal can be observed either as the Sec-GPC HTTP request header, typically carrying a value indicating the preference is set, or client-side through the navigator.globalPrivacyControl property in the browser. Server-side detection allows the preference to be evaluated before or as content is served, while client-side detection is often used by consent management scripts and tag managers. Because implementations and browser support can differ, many organizations check for the signal in more than one way. This entry describes the detection mechanism only; whether and how you must act on the detected signal depends on the applicable law and your own compliance analysis, which are outside the scope of this description.
How should the Sec-GPC signal interact with a consent management platform (CMP)?
Many CMPs can be configured to read the signal and map it to a corresponding preference state, for example applying an opt-out of sale or sharing where that concept applies under the relevant law. The signal is one input into the consent or preference state a CMP maintains; it does not, on its own, guarantee compliance, and CMP configuration should reflect legal advice about which processing activities the signal is intended to affect in each jurisdiction. Where a user's explicit choices in the CMP interface and the browser signal appear to conflict, you should define and document a defensible reconciliation approach. The correct handling depends on facts and legal interpretation not resolved by the header itself.
What should be logged when a Sec-GPC signal is received?
As with other preference and consent-related events, organizations commonly maintain records that support their ability to demonstrate how a signal was received and acted upon, which can be relevant to record-keeping and accountability expectations under various frameworks. Records may include that a signal was detected, the resulting preference state applied, and the time it took effect, consistent with data minimization. The precise record-keeping obligations differ by jurisdiction and are not fully settled for browser-based opt-out signals specifically, so log design should be reviewed against the applicable legal requirements rather than assumed from this general description.
How does the Sec-GPC signal relate to other technologies like pixels, SDKs, and local storage?
Where the applicable law treats the relevant activity as a sale or sharing, or otherwise within scope of an opt-out, the signal's effect is generally about the processing activity rather than the specific technology used, so it can be relevant to pixels, tags, software development kits, local storage, and similar non-cookie technologies as well as cookies. In practice this means an opt-out preference may need to propagate across the various tracking technologies your site uses, not only conventional cookies. How far the obligation extends depends on the definitions in the governing law and on facts about how each technology processes personal data, which fall outside this definition.

Common misconceptions

The Sec-GPC header satisfies EU cookie consent requirements.
The header expresses an opt-out preference designed primarily for opt-out regimes such as certain US state laws. Consent under the EU ePrivacy rules and the GDPR must generally be freely given, specific, informed, and unambiguous through a clear affirmative action, so an opt-out signal does not by itself constitute valid opt-in consent in most EU jurisdictions. Whether and how the signal is relevant in the EU is not settled.
Honoring the Sec-GPC header automatically makes an organization compliant with applicable privacy law.
The header is a technical signal that supports compliance workflows but does not replace legal judgment. Its enforceability and required treatment vary by jurisdiction, and organizations must still assess their specific obligations. A tool or signal alone does not guarantee compliance.
The absence of the Sec-GPC header means the user has agreed to the sale or sharing of their data.
Absence of the header generally indicates only that no GPC signal is present, not an affirmative permission. Under opt-in regimes, silence or inaction cannot be treated as consent, and under opt-out regimes the lack of an opt-out signal does not remove other applicable obligations.

Best practices

Detect and log the Sec-GPC header on incoming requests, and treat its presence as a potential opt-out request where applicable law recognizes such signals, such as certain US state privacy frameworks.
Map how the header should be honored to the specific jurisdictions where you operate, rather than applying one interpretation universally, since obligations differ between US states, the UK, the EU, and other regimes.
Do not rely on the Sec-GPC header as a substitute for obtaining valid consent under EU ePrivacy and GDPR rules, where a clear affirmative opt-in is generally required.
Coordinate the header's handling with your consent management platform and cookie categorization so that opt-out signals are reflected consistently across analytics, advertising, and other non-essential technologies.
Maintain records of how GPC signals are received and acted upon to support consent and preference record-keeping obligations, while recognizing that logging alone does not establish compliance.
Consult legal counsel on the header's evolving regulatory treatment, and monitor guidance from relevant data protection authorities, since enforcement positions may change over time.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide