What Is Global Privacy Control (GPC)?

The card above is a model of how GPC works in the browser. Try to get Mark his signal.

Global Privacy Control has become one of the most consequential pieces of plumbing on the web: a signal that, in 12 US states, carries the same legal force as clicking “Do Not Sell or Share My Personal Information” on every site you visit.

What GPC actually is

Global Privacy Control is a browser setting that broadcasts one message, automatically, to every website you visit: don’t sell or share my data. Instead of hunting down the “Do Not Sell” link in a banner or a footer, attempting to opt yourself out of tracking for every site you visit, your browser does it for you automatically.

Note the nuance on cookies: legally, GPC is not a cookie switch. American laws frame it as an opt-out from the sale and sharing of your data, and say nothing about what a site may store in your browser. In practice, though, it becomes a rule about cookies, because cookies are so embedded in the data sale process that honoring the signal means switching off marketing, analytics, and other third-party cookies. (Functional cookies, like logins and carts, are untouched.) As we covered in our last article, sale opt-outs and cookie controls are legally distinct but practically inseparable.

How GPC works on the wire

The entire mechanism is an HTTP header that gets sent with HTTP requests, notifying the recipient of the request that the user has Global Privacy Control turned on and does not want to be tracked:

GET / HTTP/2
Host: example.com
Sec-GPC: 1

In addition to the header signal, there is a JavaScript variable that holds whether the GPC signal was set at the time of page load:

navigator.globalPrivacyControl
// → true, false, or undefined

This is the part to get right, because it shapes everything about how you implement GPC: these are not two control surfaces. There is exactly one GPC signal, the header. The JavaScript property is a record of it, a receipt. The spec defines it that way: the property exists so a script can “determine what Sec-GPC header field value was sent when loading the top-level browsing context’s active document,” and its value “is false if no Sec-GPC header field would be sent; otherwise, the value is true.” The variable holds no state of its own; it is defined in terms of the header. Which is why flipping navigator.globalPrivacyControl to true on a page whose request carried no Sec-GPC header isn’t a clever alternative implementation. It’s out of spec, and it’s incoherent: a receipt for a payment that never happened.

So why keep a JavaScript record at all? Because the two are readable from different places. Your server sees the header the instant the request arrives, before a single line of JavaScript runs. Code running inside the page has no such view: browsers expose no API that lets a script read the HTTP headers of the document that loaded it. So any logic that decides whether to fire a tag, gate a script, or set a cookie has to ask the browser directly, and navigator.globalPrivacyControl is how it asks.

That is not the same as saying the third parties are unaware. Every request the browser makes to them carries the header too, so their servers see the signal arrive alongside the data. The JavaScript property exists for the benefit of code running in the page, not because anyone downstream is in the dark.

A site honoring GPC listens on both, and treats either one alone as a valid opt-out. Real-world senders aren’t always spec-perfect; some extensions deliver only the header. Both channels are communicating the same thing, an opt-out, so it isn’t good enough to watch just the JavaScript or just the header and ignore the other.

That’s it. That’s the whole technology. A boolean header value and a JavaScript variable that tells you whether it was set or not.

A few details that trip people up:

There is no Sec-GPC: 0. When the setting is off, the header simply isn’t sent, and the only legal value is exactly 1. GPC deliberately has no vocabulary for “please do track me.” Absence means nothing asserted, not consent. The signal only ever says one thing, which is exactly why honoring it is unambiguous.

The spec calls that frozen value gpcAtNavigation, and Section 3.2 says it outright:

The preference MUST be cached on each top-level navigation to ensure consistency in communication of the person’s request that their data “not be sold or shared.” This means that if the preference changes during or after a top-level navigation, it will not be reflected until the next navigation.

Read that from the compliance side: the signal is binary and locked in at page load. If a visitor lands with GPC off, adds to cart, and fires a dozen events to your ad partners, then flips GPC on mid-page, nothing changes for that page view. The opt-out takes effect at their next navigation, and you aren’t obligated to it until then.

There are two things to watch here, and both push in the same direction.

Single-page and headless sites rarely navigate. On a SPA or a headless storefront, clicking through the catalog, opening a product, and adding to cart are not top-level navigations. The framework swaps views on the client, so no new page request goes out and no new snapshot is taken. The value captured when the visitor first landed can govern a session that runs twenty minutes or longer, which means “until the next page load” can effectively mean “for the rest of their visit.” It would be unusual for someone to flip the switch in the middle of a session, but it can happen, and on a SPA the consequences last a lot longer than they would elsewhere.

Extensions introduce a race condition. A native browser has the value ready before any script on the page can run, so there is nothing to race. An extension has to inject the property with a content script, and that script can land after your tags have already read it. The failure mode is specific: your tag checks the variable, gets false or undefined, concludes there is no opt-out, and fires. A moment later the extension sets the value to true. You have now tracked someone whose browser was about to tell you not to, and whether that leaves you liable is a question nobody has answered. Many extensions also update the value live when the user toggles the setting, with no navigation involved, so the value your tag reads a second after page load can differ from the one it read at page load. None of that is sanctioned. The value is meant to be frozen at page load, so an extension overwriting it, or any other hack that sets it to true with no header behind it, is out of spec for the reason given earlier: it is a record of something that never happened.

For the most part you can assume the value is set before any JavaScript reads it, because that is what the spec requires and what native implementations deliver. However, after watching how the extensions we tested behave, we were a little bit concerned about how this may play out. We would not bet a compliance program on it.

Both cases point to the same fix: poll. Re-check the value as you go, and if it changes, update your tag behavior on the spot. It costs nothing, and you will never be wrong for honoring an opt-out early.

What American laws say about GPC

Legally, GPC is not a suggestion. In the states that recognize it, a GPC signal is the equivalent of the visitor clicking your “Do Not Sell or Share” link, an automated exercise of a statutory right.

As of mid-2026, twelve states require businesses to honor it: California, Colorado, Connecticut, Delaware, Maryland, Minnesota, Montana, Nebraska, New Hampshire, New Jersey, Oregon, and Texas, with Maryland and Minnesota having joined just this month. And regulators check. California’s first CCPA enforcement action, the $1.2M Sephora settlement, specifically cited GPC signals that had no effect on the site. The California Privacy Protection Agency’s first settlement, $632,500 from Honda, ordered the company to honor GPC as part of the fix.

One nuance worth knowing, because it explains a lot of design decisions ahead: the signal’s legal force rests on it expressing a choice. Colorado’s rules spell it out: a default baked into software that came pre-installed on your device doesn’t count as your intent, but deliberately installing a tool that’s marketed as exercising your opt-out rights absolutely does. The law cares less about the bit being set than about who set it.

GPC is the “Do Not Sell” link, automated: pressed once, asserted everywhere, backed by the same law.

You have to show that you honored it

There is one more American requirement that catches people out, and it is the rare compliance obligation your visitors can actually see. California’s regulations used to say a business may display whether it had processed an opt-out preference signal. As of January 1, 2026, that became must.

The rule is not prescriptive about how. The regulation’s own examples are text reading “Opt-Out Preference Signal Honored,” or a toggle or radio button showing that the visitor has opted out of the sale of their personal information. The simplest version is a line in your footer that appears only when the signal is present, something like: You have been opted out of data sale by the Global Privacy Control signal your browser sent.

It is worth doing properly, because it doubles as evidence. Anyone auditing you, whether that is a regulator, a plaintiff’s lawyer, or a journalist writing about your industry, can load your site with GPC turned on and see at a glance whether you are honoring it.

What global laws say about GPC

Most other regions that regulate tracking heavily, Europe above all, run the opposite model. There, tracking is opt-in: nothing fires until the visitor affirmatively says yes. A signal that announces “do not sell my data” doesn’t map neatly onto a regime where the default answer is already no.

Here is why this may still matter, and it is not the same risk at all. In the US, GPC automates a footer link that almost nobody clicks. In an opt-in region, a browser-level signal could replace the banner itself. It is very likely that the banner shouldn’t render at all once the signal has been sent, and a banner that never renders is an opt-in you never get to ask for. You don’t get any opt-ins at all from those visitors. Whatever rate you normally see, ten or twenty or fifty percent, becomes zero, because you never get the at-bat. For any site with real European traffic, that is a very different order of impact.

European lawmakers have already started writing signals like this into draft law, and it is reasonable to expect versions of it to keep landing in other regions. The US is simply out in front.

GPC is landing in Chrome right now

For years the GPC story had a hole in it: the browsers most people actually use didn’t send it. Brave and DuckDuckGo enable it by default, Firefox offers it in settings, and extensions like Privacy Badger add it. But Chrome, with two-thirds of the market, stayed silent.

That changed this month. Google added GPC support to Chrome Canary, the nightly experimental build, in late July 2026. Testers report the browser sending the Sec-GPC: 1 header, exposing navigator.globalPrivacyControl, and lighting up the official test page at globalprivacycontrol.org.

We went looking ourselves. In our build we were able to turn the flag on and watch requests leave the browser carrying Sec-GPC: 1, on every request, the same way Brave and Firefox do it. Google is still rolling this out gradually, so two people on the same version can see different things. We’ll update this article with screenshots as the rollout widens.

Why Chrome, why now: AB 566

Chrome’s timing isn’t a change of heart. It’s California’s AB 566, the “Opt Me Out Act,” signed in October 2025. Starting January 1, 2027, anyone who ships a browser to Californians must include opt-out-signal functionality, and the statute pre-empts the obvious dodge, requiring that it be “easy for a reasonable person to locate and configure.” A setting buried in an experimental flags page doesn’t qualify; what’s in Canary today is engineering preview, not the finished posture.

Two things about the law are worth being precise about. First, it does not require the signal to be on by default. Browsers have to offer the setting and make it easy to find, but they are allowed to ship it switched off. Second, browser makers are not liable for what websites do with the signal. That obligation stays with the sites receiving it, which removed the last real objection to shipping the feature at all.

What is still unsettled is how prominent “easy to locate and configure” actually has to be. California’s privacy agency will decide that through rulemaking, and the browser vendors with advertising businesses would prefer the answer to be three menus deep.

Where this is heading

When Apple made app tracking a one-tap, plain-language question in 2021, only about a quarter of users worldwide said yes, and Meta told investors the change would cost it around $10 billion in a single year. That’s what happens when the choice stops being buried: most people, given a clear question, say no.

Today that switch is buried everywhere it exists. In Chrome it sits behind an experimental flag. In Firefox it is real but tucked away where most people will never find it. This is exactly what AB 566 is written against, because a control hidden in a flags page is not one a reasonable person can locate and configure. The likely endpoint is that browsers stop making people hunt for it and simply ask, in plain language, during setup, before you visit a single site.

That would be a sea change, not a tweak. Today most sites measure something close to their whole audience, with only the slice running blockers or privacy browsers going dark. Put the question in front of everyone during setup and, if app tracking is any guide, most people say no. Going from measuring ninety percent of your traffic to measuring a quarter of it is not a reporting inconvenience. It changes what optimization even means: conversion signals thin out, attribution loses the inputs it depends on, and the models the ad platforms run on get a fraction of the training data they have today. Nearly every number a marketing team looks at sits on top of that foundation.

Seen from here, GPC gives the opt-out real legal weight in twelve states, and AB 566 moves the switch into the browser itself. The difference from every earlier attempt at this is the one that matters: on the web, ignoring the answer isn’t rude, it’s illegal.

There is a second-order consequence here. Today the obligation is framed as the website’s problem: the signal arrives at your server, and you are expected to act on it. But when GPC is implemented properly and rides every request, the third parties on the other end receive it too. The ad platform’s own logs contain the header, attached to the very payload the visitor objected to. Everyone in the chain can see it.

That is where responsibility is likely to drift. It is a hard thing to defend, receiving a legally mandated signal not to track someone and processing the data anyway, and the larger the recipient the less credible it gets. Expect the burden to be shared over time rather than resting entirely on whoever happened to own the page the visitor was on.

What this means for your site

If visitors from those twelve states reach your site, and they do, the signal is already arriving. The work is straightforward:

• Read the signal from wherever you are standing, and treat what you see as an opt-out. On the server, that means the Sec-GPC header. In tag logic running inside the page, it means navigator.globalPrivacyControl. A JavaScript true with no header behind it is out of spec, but honor it anyway. Requiring both before you act is the one clearly wrong posture.
• Wire it to the same switch as your “Do Not Sell” link. It’s the same right, exercised a different way. One switch should control every flow of visitor data to third parties, as we argued in the last article.
• Confirm visibly that the signal was received, with a line in your footer that appears when GPC is present, to comply with the updated California regulations.

FAQ