This document defines a signal, transmitted over HTTP and through the DOM, that conveys a user's request to websites and services to not sell or share their personal information with third parties. This standard is intended to work with existing and upcoming legal frameworks that render such requests enforceable.


Building websites today often requires relying on services provided by businesses other than the one which the user choses to interact with. This result is a natural consequence of the increasing complexity of Web technology and of the division of labor between different services. While this architecture can be used in the service of better Web experiences, it can also be abused to violate user privacy.

Several legal frameworks exist — and more are on the way — within which users have the right to request that their privacy be protected, including requests that their data not be sold or shared beyond the business with which they intend to interact. Requiring that users express their rights for each and every site they visit is, however, impractical.

Given the ease and frequency by which personal information is collected and sold when a consumer visits a website, consumers should have a similarly easy ability to request to opt-out globally. This regulation offers consumers a global choice to opt-out of the sale of personal information, as opposed to going website by website to make individual requests with each business each time they use a new browser or a new device. [[CCPA-AG-FINAL-STATEMENT]]

This specification addresses the issue by providing a way to signal, through an HTTP header or the DOM, a user's assertion of their applicable rights to prevent selling their data to third parties or sharing data with them. This signal is equivalent, for example, to the "global privacy control" in the CCPA [[CCPA-REGULATIONS]].


The terms effective script origin, top-level browsing context, document.domain, responsible document, and active document are defined in [[HTML]], as is the Navigator interface.

The term target resource is defined in HTTP/1.1 syntax [[RFC7230]] and semantics [[RFC7231]].

A do-not-sell-or-share interaction is an interaction with a website in which the user is requesting that their data not be sold to or shared with any party other than the one the user intends to interact with, except as permitted by law.

Expressing a Do Not Sell Or Share Preference

Expression Format

If a user has requested that their data "not be sold or shared" via setting a Global Privacy Control preference, that preference needs to be expressed to all mechanisms that might collect data from or share data with third parties.

If set, this preference is expressed as a single value of 1 or equivalently true according to context, which conveys the fact that a user is requesting a do-not-sell-or-share interaction.

In the absence of regulatory, legal, or other requirements, servers MAY interpret an expressed Global Privacy Control preference as they find most appropriate for the given user, particularly as considered in light of the user's privacy expectations, context, and cultural circumstances. Likewise, servers might make use of other preference information outside the scope of this protocol, such as site-specific user preferences or third-party registration services, to inform or adjust their behavior when no explicit preference is expressed via this protocol.

User agents are expected to convey user preferences as accurately as they can. User agents SHOULD strive to represent what the user agent best believes to be the user's preference for the Global Privacy Control value.

The Sec-GPC Header Field for HTTP Requests

The Sec-GPC header field is a mechanism for expressing the user's preference for a do-not-sell-or-share interaction in an HTTP request. At most one Sec-GPC header field can be present in a valid request.

          Sec-GPC-field-name  = "Sec-GPC"
          Sec-GPC-field-value = "1"

A user agent MUST NOT generate a Sec-GPC header field if the user's Global Privacy Control preference is not enabled.

A user agent MUST generate a Sec-GPC header field with a field-value that is exactly the numeric character "1" if the user's Global Privacy Control preference is set.

Extensibility of the Sec-GPC Field Value

The Sec-GPC is deliberately defined without an extension mechanism. Experience with previous similar headers shows that people tend to rely on string equality instead of parsing the value when testing for their presence, especially when extensions do not yet exist. Such checks would of course fail in the presence of extension content, which would in turn render the mechanism moot. Should extensions prove necessary to this standard, they will need to be implemented through other headers, which may in time supersede this one.

JavaScript Property to Detect Preference

The Navigator.globalPrivacyControl property enables a client-side script to determine what Sec-GPC header field value would be sent to the effective script origin when referenced by the active document's top-level browsing context.

          partial interface Navigator {
            readonly attribute boolean globalPrivacyControl;

The value is false if no Sec-GPC header field would be sent; otherwise, the value is true.

Specifically, the value of Navigator.globalPrivacyControl for a given script is true if a Sec-GPC header set to 1 is sent in a request to a target resource at the effective script origin (the current document.domain of the script's responsible document) when that request is due to an embedded reference from this site (the document.domain of the top-level browsing context's active document). Otherwise, it is false.

Ideally, the value of Navigator.globalPrivacyControl ought to reflect the preference of the user when the attribute is read. In practice, however, the value might only reflect the value that was in effect when the script was initiated.

GPC Support Resource

A site MAY produce a resource at a .well-known URL in order for a site to represent the fact that it abides by GPC.

A GPC Support Resource has the well-known identifier /.well-known/gpc.json relative to the origin server's URL [[RFC5785]].

An origin server that receives a valid GET request targeting its GPC support status resource MUST send either a successful response containing a machine-readable representation of the site-wide tracking status, as defined below, or a sequence of redirects that leads to such a representation (possibly provided by a server at another origin).

GPC Support Representation

The origin server MUST return the GPC support resource as a valid representation using the application/json media type [[RFC8259]].

The GPC support representation MUST be an JSON object. The JSON object MUST have a the following members (all other values MUST be ignored):

Legal Effects

During the initial experimental phase, the GPC signal is not intended to convey legally binding requests; it is instead intended as way to test effective protocols for communicating and complying with user requests to stop the sale or sharing of their personal information.

After the experimental phase, receiving a GPC signal may have legal effects, depending on factors such as the location of the individual sending the signal, the scope of the applicable law, as well as any separate agreement between the recipient of the signal and the individual.

For example, the use of the GPC signal by an individual will be intended to communicate the individual's intention to invoke the following rights, as applicable:

Given the complexities of existing consent frameworks, publishers who accept the GPC signal should disclose how they treat the GPC signal in that jurisdiction and how they deal with conflicts between the signal and other specific privacy choices that the user has already made directly with the publisher, including instances where third party sharing may be permitted such as sharing to service providers/processors, sharing at law or at the direction of the individual.

User Interface Language

Studies have shown that users do not want their data sold or shared. However, in some jurisdictions they can only avail themselves of that preference by explicitly asserting control.

User agents are expected, where required, to present all the appropriate notices to users to ensure that the rights they wish to avail themselves of are effectively binding.

Implementation Considerations

It is worth considering that a GPC signal will be attached to every HTTP request made to a given site. Rendering a page on the Web often requires making dozens such requests. As such it can prove impractical for GPC signals to trigger full-blown opt-out procedures with costly audit trails for every single GPC interaction as that will cause a large amount of processing, including for resources served from a content delivery network (CDN) that must be executed as efficiently as possible.

Regulations that intend to support GPC are encouraged to consider such implementation difficulties. One way of addressing them is to differentiate between user interface affordances given to users for the purpose of requesting a do-not-sell-or-share interaction preference to persist on the site, and the provision of a do-not-sell-or-share interaction signal the state of which is maintained with the user agent. In the latter case, the interaction can be processed as if the user had previously requested such a do-not-sell-or-share interaction preference and were interacting with that preference already active.


This specification relies on concepts developed in large part by the Tracking Protection Working Group and others who contributed to Tracking Preference Expression (DNT).