Global Privacy Control (GPC): How to Detect It Server-Side

The choice in plain words

For about a decade, the consent banner was the public face of web privacy. Every site asked the same question, every user clicked through it without reading. It did not work very well for anyone, and the dark patterns that newspapers built into those banners made the experience even worse.

Global Privacy Control, usually shortened to GPC, takes the opposite approach. The user sets their preference once in their browser. The browser sends that preference to every site, on every request. The site reads it and acts on it. There is no banner involved.

This is the part that surprises people: GPC is not new and it is not theoretical. It is shipped today in Brave, Firefox, DuckDuckGo, and the Privacy Badger extension. Several US states already treat it as a legally valid opt-out. The pieces are in place. What is missing is server-side code that listens for it.

What the GPC signal actually is

GPC is a single HTTP request header. When a user has it enabled, every request their browser makes carries this line:

Sec-GPC: 1

That is the entire signal. It means “I do not want my personal data sold or shared”. One header, one value, no ceremony.

There is also a JavaScript property for client-side detection:

// Read the user's GPC preference in the browser
function userOptedOut() {
  return navigator.globalPrivacyControl === true;
}

Both come from the same source: the user’s browser setting. The header is the one that matters most because it arrives before any JavaScript runs, which means you can decide what to send back before the page is rendered.

How it differs from the cookie banner

A cookie banner asks for consent. GPC expresses a refusal that was set earlier, in the browser, once. The user is not asked again on your site.

If you respect the GPC signal, you do not need a banner for marketing or analytics opt-out on those visits. The user already opted out. Your job is to read the header and behave accordingly.

You may still need a banner for other purposes (functional cookies that genuinely require consent in your jurisdiction, for example), but the loud “Accept all / Reject all” theatre becomes unnecessary for users who have already spoken through their browser.

Where GPC is legally enforceable

This is the part that turned GPC from a nice idea into a compliance question.

In California, the California Consumer Privacy Act and its update, the California Privacy Rights Act (together usually written as CCPA/CPRA), recognize GPC as a valid opt-out signal. Ignoring it has triggered enforcement actions. Sephora settled one of the early cases.

Colorado and Connecticut have followed with similar recognition under their own state privacy laws. Other US states are moving in the same direction at different speeds.

Europe is less direct about GPC by name, but the General Data Protection Regulation already requires that opt-out be as easy as opt-in. Several regulators have indicated that a browser signal qualifies. Spain’s data protection authority, the AEPD, has published guidance leaning in this direction.

The practical reading: in 2026, ignoring a GPC header on a site that serves users in California is risky. Honoring it is cheap.

Detecting GPC on the server

Reading the header is straightforward in any web framework. A few examples.

In a Node Express handler:

app.use((req, res, next) => {
  req.userOptedOut = req.get('Sec-GPC') === '1';
  next();
});

In Astro middleware:

// src/middleware.ts
export const onRequest = async (context, next) => {
  const optedOut = context.request.headers.get('sec-gpc') === '1';
  context.locals.userOptedOut = optedOut;
  return next();
};

In a PHP project:

$userOptedOut = ($_SERVER['HTTP_SEC_GPC'] ?? '') === '1';

Once you have that boolean, the rule is simple. If the user opted out, do not include third-party tracking scripts in the response, do not set advertising cookies, do not pass identifiers to analytics that involve data sharing. Server-side rendering is the right place to make this decision because by the time JavaScript runs, the tracking script is often already loaded.

CHIPS in plain words

CHIPS stands for Cookies Having Independent Partitioned State. The mechanism is simpler than the name.

When an embedded widget (a chat bubble, an embedded video, a payment iframe) sets a cookie, that cookie used to be the same across every site the widget appeared on. That is how cross-site tracking worked. The same widget on site A and site B could read the same cookie and connect the two visits.

With CHIPS, the cookie is partitioned by the top-level site. The widget on site A gets one cookie jar. The same widget on site B gets a separate cookie jar. The widget still works (it can remember you within a single site), but the cross-site link is gone.

Browsers are rolling this out as the default for third-party cookies. As a developer, you mark cookies that should work in embedded contexts with the Partitioned attribute. Cookies that need to remain shared across sites (which is most legitimate cross-site state) need a different design.

Privacy Sandbox in plain words

Privacy Sandbox is Google’s ongoing effort to replace third-party cookies with privacy-preserving alternatives in Chrome. It is a collection of APIs, not a single feature.

The two most discussed pieces:

• Topics API: the browser observes the categories of sites the user visits and exposes a small list of broad interest topics (like “Travel” or “Cooking”) to advertisers. The browsing history itself never leaves the device.
• Protected Audience API (formerly FLEDGE): allows on-device ad auctions for retargeting, without sending the user’s profile to a server.

The intent is to keep some advertising functionality alive while removing the universal third-party cookie. Whether it succeeds, and whether regulators consider it sufficient, is still being argued. Treat it as one option in the post-cookie toolkit, not as a replacement for asking honest questions about what data your site actually needs.

For consent UX patterns and what banners still need to do for cookies that are not advertising-related, see Cookie Banner Best Practices. For the broader data protection picture, see GDPR Technical Security.

Practical takeaways

A short list, in priority order.

1. Read Sec-GPC: 1 on every server request. Make it a single property on your request object.
2. If it is set, treat the user as opted out of any data sharing or sale. Do not load third-party advertising scripts. Do not pass identifiers to analytics that share data with third parties.
3. Mark embedded cookies with Partitioned if they only need to work within a single top-level site.
4. Stop assuming consent will always be set per-site. Build for a world where the user expresses a preference once, in the browser, and every site honors it.
5. Keep banners for the things they are still genuinely needed for, and remove the dark patterns. Reject should be as easy as Accept, the AEPD rule we covered in detail.

GPC will not solve every privacy question on its own. It does cover the most common case (the user does not want their data sold) without the friction that made banners so unloved. Reading one header is a small price for being on the right side of that shift.

If you want help auditing how a site handles GPC, partitioned cookies, and consent signals end to end, that is something we do.