A browser can expose a privacy preference without showing what a website does with it. Global Privacy Control and Do Not Track are signals sent or made available to sites. Reading either signal tells you about the current browser context. It does not independently verify a company's data handling or establish that every request stopped.
That distinction matters when a privacy setting appears enabled but a site still loads advertising or analytics code. A preference, the presence of a request and the service's treatment of data are separate observations. Investigate each with the evidence appropriate to it instead of turning one browser field into a universal verdict.
Read the exposed Global Privacy Control value
The privacy preferences inspector reads navigator.globalPrivacyControl when the browser exposes it. A true value indicates that the current context exposes the GPC preference. A false value and a missing property should be recorded separately, because absence may reflect lack of implementation rather than a deliberate choice.
GPC also has an HTTP expression through the Sec-GPC request header. A JavaScript property and a captured request header are observations at different interfaces. If your goal is to check what a particular service received, inspect a request to that service in the browser's network tools or in an authorised server log.
The tool does not send a test request to every site you use. Its local result cannot confirm that a proxy, embedded context or application made the same signal available elsewhere. Keep the exact browser profile and destination in the record when investigating a discrepancy.
Keep Do Not Track separate from GPC
Do Not Track is an older mechanism with limited adoption and deprecated browser interfaces. Depending on implementation, a browser can expose a string such as 1, 0 or an unspecified value. Do not use a loose truthiness check: the string 0 is truthy in JavaScript even though it is not the same preference as 1.
The inspector reports the exposed value rather than treating every nonempty value as enabled. DNT and GPC are distinct signals with different histories and uses. Enabling one does not prove the other is enabled, and an application should not silently substitute one for the other in a diagnostic report.
If you maintain a site, review the current documentation for the signal you intend to support. Avoid building a new privacy flow around a deprecated property simply because a browser still exposes it. Preserve compatibility information and explicit unknown states so a future browser change does not turn missing data into assumed consent.
| Result | Supported conclusion | Evidence still needed |
|---|---|---|
| GPC is true | This context exposes the preference | The service's handling of the signal |
| GPC is not exposed | The property is unavailable here | Browser support and relevant request headers |
| DNT reports 1 | The older preference is exposed | Whether the destination acts on it |
| Reduced motion matches | The page sees a motion preference | Whether its animations respect that preference |
| A media query is false | That query did not match | Whether the feature is supported at all |
Check a preference from setting to request
Begin with a fresh record of the browser version, profile and privacy setting. Run the inspector, save the relevant fields and then reload the page after changing the setting. Some browser or extension settings apply at navigation boundaries, so comparing an old document with a new setting can create an avoidable mismatch.
Next open the developer tools network panel on a site you are authorised to inspect. Reload and select the main document request. Review its request headers, then compare a relevant subresource or API request. Do not assume that a screenshot of the settings page is evidence of the exact request that reached the service.
If you operate the receiving service, use a test account and confirm how your application records and applies the preference. A raw header in an edge log proves receipt at that layer. It does not show that a downstream consent service, analytics pipeline or account setting applied the intended behaviour.
Write the result as a chain: setting enabled, local property true, header observed on a named request, application behaviour checked through a named test. If one step is missing, leave it missing. This makes the report useful to the person who owns that layer.
Investigate a site that still makes requests
Suppose a test profile exposes GPC and a page still contacts an analytics endpoint. The request's existence alone does not tell you its purpose, payload, retention or downstream use. It could carry a preference update, a limited operational event or data that should have been suppressed. Inspect the actual request and the implementation before deciding which explanation fits.
For a site you maintain, create a test plan with the preference off and on. Compare payload fields, identifiers, storage writes and server-side treatment. Use synthetic events rather than real customer activity. Ensure the same account state and region settings apply in both runs, since those can alter the consent flow independently.
For a third-party site, you may be able to observe requests and read its privacy information, but you generally cannot verify internal retention from the browser alone. State that boundary. A useful report can identify a concrete inconsistency without claiming visibility into systems you did not inspect.
Understand the other preferences in the report
The inspector also reports preferences such as colour scheme, reduced motion, increased contrast, forced colours and reduced transparency. These describe presentation needs or choices. They are not interchangeable with GPC, and enabling a dark theme does not express a data-sharing decision.
For accessibility testing, compare the exposed media-query result with the page's actual response. A reduced-motion setting should lead developers to review moving backgrounds, scroll effects and animation timing. The query returning true does not modify an application's JavaScript animation automatically.
A false result can be ambiguous when a feature is unsupported. Use feature documentation and a controlled setting change to investigate. Avoid inferring that the user actively prefers more motion, less contrast or transparency merely because the corresponding reduction query did not match.
Handle preferences without creating a new identifier
A site can often apply a preference during the current request or page session without storing a detailed browser profile. Collect only the fields needed for the behaviour. Combining presentation preferences, device traits and persistent identifiers in a long-lived log can create unnecessary identifying data.
When testing changes, use a clear expected result for each setting. For example, a preference may suppress a particular data flow while preserving a necessary login cookie. The test should examine that behaviour directly. Counting cookies or requests without classifying their role can make both good and bad implementations look the same.
Legal obligations associated with privacy signals depend on the applicable rules and service context. This browser diagnostic does not determine jurisdiction or certify compliance. Operators should connect their technical implementation to their own documented policy and applicable requirements, then keep evidence of the actual behaviour they tested.
Preserve an unknown value in application code
For a diagnostic field, use three explicit states: exposed and enabled, exposed and disabled, or not exposed. Checking whether globalPrivacyControl is present before reading its boolean value preserves that distinction. A default expression that turns every missing value into false discards information that support may need.
Apply the same discipline to stored test results. Keep the raw observation and the browser build alongside any human-readable label. If support for the property changes in a later release, you can then understand why an older report used an unknown state.
Do not translate unknown into a business decision without considering the rest of the service's consent and privacy rules. The diagnostic reports evidence; the application must apply its documented policy to the complete context.
Frequently asked questions
Does GPC block advertisements?
GPC is a preference signal, not a general content blocker. A browser extension may combine signalling with blocking features, but those are separate functions. To understand a page's behaviour, inspect which setting controls each function and test it independently. A visible advertisement does not by itself reveal how the preference was handled.
Why does the tool say not exposed?
The JavaScript property is unavailable in the current context. Check browser support, version and profile settings. If an extension adds a request header without exposing a matching property, the network observation may differ from the local property check. Report both results with their source instead of forcing them into one yes-or-no field.
Can a website change my browser's GPC setting?
A normal page does not use this read-only property as a control for the browser's global preference. It can read the value that is exposed to it and choose its own application behaviour. Change the preference through the browser or relevant extension settings, then reload and verify the result in the intended profile.
Is Do Not Track enough for a new implementation?
Do not assume that an older, deprecated signal covers current requirements or browser behaviour. Review the specific signals and policies relevant to your service. Test missing and unsupported values as well as enabled values, and make sure the absence of an obsolete property does not silently bypass a user's separately expressed choice.
Does reduced motion hide fingerprinting information?
It communicates a presentation preference. Although any exposed field can contribute to a broader set of browser observations, its purpose is to help applications adapt their interface. Use it to reduce unnecessary animation and respect user needs. Do not treat accessibility settings as suspicious or penalise users for enabling them.