Global Privacy Control (GPC) is a browser signal through which people exercise applicable rights to opt out of the sale or sharing of personal information and targeted advertising. A website receiving GPC needs to determine which obligations apply and carry the resulting choice into its data processing.
Detecting the signal is the beginning of that process. A useful website test follows the choice from the browser to privacy settings, vendor requests and relevant account records. This guide explains the signal, selected legal requirements and a practical testing approach. For configuration across platforms, use our separate Consent Mode, GPC and GPP integration guide.
What is Global Privacy Control?
GPC expresses a person's privacy choice automatically when they visit websites. It uses the HTTP request header Sec-GPC: 1 and a JavaScript property, navigator.globalPrivacyControl. In supporting browsers, the property reflects the signal associated with the current document's navigation. A missing signal does not communicate permission to sell data.
The W3C GPC specification remains a Working Draft as of this article's review date. Its technical format and the laws recognising the signal are separate: a draft technical specification can already support an enforceable legal right.
A universal opt-out mechanism, or UOOM, is a mechanism through which people can exercise rights across businesses. GPC is one such mechanism. The particular rights, businesses and consumers covered depend on the applicable law.
Where must businesses honour GPC?
Start with the organisation's coverage under each law, the consumer covered and the relevant processing. A website being accessible in a state does not, by itself, establish every obligation under that state's privacy law.
These are selected examples, not a complete state list:
| Jurisdiction | Verified requirement | Primary source |
|---|---|---|
| California | Covered businesses that sell or share personal information must recognise qualifying opt-out preference signals, including GPC. | California Attorney General's GPC guidance |
| Colorado | Since 1 July 2024, controllers within the law's scope must support GPC for opting out of sale or targeted advertising. Colorado recognises GPC on its UOOM list. | Colorado Attorney General's universal opt-out guidance |
| Connecticut | Since 1 January 2025, covered controllers must honour qualifying opt-out preference signals. The Attorney General identifies GPC as an example. | Connecticut Attorney General's CTDPA guidance |
Check signal requirements separately from a law's general commencement date. Thresholds, exemptions, residency and conflict-resolution rules also differ. For broader coverage, see the US state privacy law tracker.
IP geolocation is an implementation input, not a definitive finding of residence. Document how your approach handles travel, VPNs and known account information. A business may choose to honour qualifying signals more broadly, provided its notices accurately describe that practice.
California's scope and confirmation rules
The CCPA regulations, sections 7025 and 7026, establish several important distinctions:
- Scope: section 7025(c)(1) covers the browser or device and associated consumer profiles, including pseudonymous profiles. It also covers the consumer when known.
- No mandatory identification: section 7025(c)(2) prohibits requiring extra information to process the signal.
- Conflicting choices: section 7025(c)(3) requires processing a signal despite a conflicting business-specific setting, with conditions for obtaining subsequent consent. Financial incentives have separate rules in (c)(4).
- Persistence: under (c)(5), a later absent signal is not consent to resume sale or sharing for a known consumer.
- Display: (c)(6) requires displaying whether the signal has been processed. A message saying only that GPC was detected does not establish completion.
- Timing: section 7026(f) requires compliance as soon as feasibly possible, within 15 business days. That ceiling is not a routine waiting period.
The exception from providing a separate opt-out link depends on satisfying all conditions in sections 7025(f) and (g), including frictionless processing. Simply switching on GPC detection does not establish that exception. See our CCPA cookie banner requirements guide.
How to test GPC on a website
Treat this as an engineering review procedure. Agree the expected outcome for each destination before testing, using its purposes, contract and configuration. Our CCPA sale versus sharing guide helps structure that assessment.
1. Establish a controlled browser session
Use a browser or extension that supports GPC and confirm its setting. Record the browser version, test URL, date, relevant region configuration and whether the account is signed in. Keep a separate clean session for comparison so a previous preference does not conceal a fault.
2. Confirm the incoming signal
Reload the page after changing the browser setting. In developer tools, inspect the document request for Sec-GPC: 1. Where supported, inspect navigator.globalPrivacyControl in the console. If the observations differ, investigate the browser, extension and request path before drawing a conclusion about the website.
For systems that make privacy decisions at an edge, application server or tag server, verify that the relevant decision point receives the signal or the resulting privacy state. A response header added by middleware is not proof that downstream request processing received it.
3. Check the resulting privacy state
Inspect the CMP and preference centre. Record the difference between the incoming signal, the stored choice and the status shown to the visitor. An illustrative confirmation is: “Your opt-out of sale and sharing has been processed.” Use that wording only when it describes the actual result.
4. Inspect transfers and vendor behaviour
Exercise representative page views, forms, searches and purchase events. Compare the browser's outgoing requests with the expected treatment of each destination. Then inspect server logs or authorised debugging tools for forwarding that the browser cannot show.
A tag firing is not, by itself, proof of an unlawful sale or sharing. Assess the data sent, destination, purpose, vendor role and applicable restrictions. Conversely, an empty cookie jar does not prove that no personal information left the site.
5. Test account and navigation transitions
Repeat the checks across reloads, client-side navigation and login. If the system associates the browser with an account, inspect the corresponding preference record and relevant downstream services. Use authorised test accounts and test data.
Do not manufacture new identity links merely to make the test pass. Test the associations the business actually holds, including pseudonymous profiles where relevant.
6. Retest persistence and changes
Test a returning visitor, a later session without a signal and an existing conflicting preference. Record the intended conflict rule before implementation. A cookie's expiry is a technical storage setting, not a universal legal expiry date for an opt-out.
For each finding, retain the expected outcome, observed outcome, affected route or destination and the evidence needed to reproduce it. After a correction, repeat the affected case and neighbouring consent states.
How GPC relates to Consent Mode and GPP
Keep the consumer's choice separate from the mechanisms used to communicate it. Your implementation needs an explicit mapping from applicable privacy obligations to platform settings and destination behaviour.
Google Consent Mode manages Google tag behaviour using consent settings. GPC detection does not automatically configure every Google product. IAB Tech Lab's Global Privacy Protocol (GPP), formerly called the Global Privacy Platform, provides a way to communicate privacy choices to participating systems; encoding a choice is not proof that a recipient applies it.
For the platform documentation, mappings and verification steps, continue to the unified implementation guide. Check both browser and server destinations when reviewing that configuration.
Frequently asked questions
Does GPC reject every cookie?
GPC is not a universal cookie-category rejection signal. Its effect follows applicable privacy rights and the site's disclosed handling. Assess the underlying processing rather than assuming every cookie must disappear or every cookie-free request is acceptable.
Does GPC delete personal information?
No. The W3C specification distinguishes GPC from a global deletion request. A business needs a separate process for applicable deletion rights.
Does GPC replace GDPR consent?
Do not treat GPC as affirmative consent. It is a restrictive privacy signal. Its treatment under European law needs separate assessment of the processing and rights involved; the W3C specification's discussion of other jurisdictions does not establish a blanket EU rule or replace a consent-management process.
Does GPC apply only when someone logs in?
No. The California Attorney General describes GPC as a way to exercise an opt-out without submitting an individual request to every participating business. An anonymous visit can carry the signal. Account recognition matters when deciding how far the business can associate that choice with other information. California GPC guidance.
Must every request create a new opt-out record?
No universal requirement demands a new full workflow for each image, script or other resource request. The W3C implementation considerations recognise the cost of that approach. Design consistent enforcement and appropriate records, and test that a cached decision cannot conceal a newly received opt-out.
Related guides and implementation support
- CCPA cookie banner requirements: notices, choices and opt-out routes.
- Consent Mode, GPC and GPP integration: configuring the systems that receive and act on privacy choices.
- US state privacy law tracker: broader state-law coverage.
To review the configuration behind your website's privacy choices, talk to Consenteo or request a free consent audit.
