How to test Global Privacy Control (GPC) on a website

A website can recognize the Global Privacy Control signal and still fail to enforce the intended restriction. A useful audit verifies the browser signal, application decisions, network requests and downstream behavior—not just a checkbox in the consent platform.

Global Privacy Control is a browser-level way to express a preference not to have personal information sold or shared. It does not replace every legal analysis or all forms of consent: the relevant obligation depends on the applicable jurisdiction, processing purpose, party and technology. California guidance says that covered businesses must recognize valid GPC signals as requests to stop sale or sharing of personal information. Review the current legal and technical requirements before making a compliance conclusion.

1. Verify the signal before evaluating the website

Use a browser or profile that supports GPC and has it enabled. Open developer tools and inspect the initial document request in the Network panel. For a supported implementation, the request can include the HTTP header Sec-GPC: 1. In supporting browsers, the JavaScript expression navigator.globalPrivacyControl may evaluate to true.

A network inspection should distinguish the browser's request from simulated headers inserted by developer tools or a proxy. The Sec-GPC header is controlled by the user agent; a page's JavaScript cannot reliably set it as an ordinary request header. For a test, use a real supported browser profile rather than assuming a manually edited request reproduces the visitor experience.

2. Trace the preference through the consent architecture

The presence of the GPC signal is only the beginning. Identify which component reads it, how the CMP or application represents it, and whether relevant tags, APIs or destinations observe the resulting restrictions. A banner might say "opted out" while a separate marketing script fires before the CMP has initialized.

Start with a clean browser profile. Preserve a record of the URL, jurisdiction or geolocation configuration, browser, relevant app build, timestamp and whether consent storage was cleared. Observe requests before any interaction and again after the site processes the signal. Repeat the same approach after the visitor makes an explicit choice through the preference interface.

3. Run a repeatable GPC QA matrix

The following matrix is a general training example, not a universal legal answer key or a substitute for testing a specific deployment. Copy these scenarios into your own test procedure and expand them for the site's actual vendors, destinations and regional requirements.

4. Check actual network and storage outcomes

Inspect the Network panel for requests to analytics, advertising, measurement or data-sharing destinations relevant to the defined restrictions. Look at the request timing, initiator, payload and response. Review cookies and other persistent browser storage. A request existing in the log does not by itself prove a violation; you need to understand the processing purpose, whether it carries personal information, the legal context and the site's configuration.

Check whether any tag fires before the GPC decision is applied, whether scripts are conditionally loaded, and whether consent changes propagate to tag managers, application backends and downstream processors. Repeat the test with previously saved preferences and a fresh session: those are different states, and both may matter.

5. Turn findings into an engineering handoff

A strong bug report should describe the expected policy outcome, observed traffic or storage behavior, reproduction steps, evidence, scope, and a proposed owner. Distinguish a configuration defect from a missing integration or an unsupported requirement. After remediation, test the original issue and nearby journeys such as banner acceptance, rejection, GPC-enabled visits, and repeat visits.