# Meta Pixel and cookie consent: a setup that respects the choice

> How to run the Meta Pixel and Conversions API with cookie consent: blocking before consent, fbq consent calls, the _fbp and _fbc cookies, Limited Data Use and GPC.

Source: https://www.cookiesh.eu/blog/meta-pixel-and-consent  
Published: 2026-10-29

## Key takeaways

- The Meta Pixel sets the first-party _fbp cookie, can set _fbc from ad clicks and sends browsing events to Meta, so in the EU and UK it needs consent before it loads.
- Meta's consent API, fbq('consent', 'revoke') and fbq('consent', 'grant'), holds back Pixel events, but the safest setup also blocks the Pixel script itself until consent.
- Google Consent Mode does not control the Meta Pixel; you need a separate consent check in your tag manager or code.
- The Conversions API sends events from your server, but those events still need a lawful basis, so gate them on the same consent as the browser Pixel.
- For US state privacy laws, use Meta's Limited Data Use option and honor opt-out signals such as Global Privacy Control.

The Meta Pixel sets first-party cookies and sends browsing events to Meta, so EU and UK visitors have to consent before it runs. The safest setup blocks the Pixel script until the visitor accepts marketing cookies, uses Meta's consent API as a second safeguard and gates the Conversions API on the same choice. In the US, add Limited Data Use and honor Global Privacy Control.

## What does the Meta Pixel do with visitor data?

The Pixel is a JavaScript library, `fbevents.js`, loaded from Meta's servers. Once initialized, it sends events such as `PageView`, `AddToCart` and `Purchase` to Meta, together with the page URL, browser details and identifiers that help Meta match the visitor to an account.

It uses two first-party cookies on your domain:

- **`_fbp`** identifies the browser across visits, so Meta can connect events from the same visitor.
- **`_fbc`** stores the click ID when a visitor arrives from a Meta ad with an `fbclid` parameter in the URL, so conversions can be attributed to the ad.

If you enable automatic advanced matching, the Pixel also hashes information visitors enter in forms, such as email addresses, and sends it to Meta for matching. All of this is advertising tracking and needs consent under EU and UK rules. For why the website shares responsibility, see the CJEU's *Fashion ID* ruling, which treated a site embedding a Facebook plugin as a joint controller.

## How do I block the Pixel until consent?

Do not let the browser download `fbevents.js` until the visitor has accepted marketing cookies. Mark the Pixel snippet as inert and activate it only after consent:

```html
<!-- Inert until the marketing category is granted -->
<script type="text/plain" data-consent="marketing">
  !function(f,b,e,v,n,t,s){/* Meta's standard base code */}(window, document,
    'script', 'https://connect.facebook.net/en_US/fbevents.js');
  fbq('consent', 'grant');
  fbq('init', 'YOUR_PIXEL_ID');
  fbq('track', 'PageView');
</script>
```

Your consent layer swaps `type="text/plain"` for a real script when consent is granted, as described in [how to block third-party scripts until consent](/blog/block-scripts-until-consent). If you use Google Tag Manager, set the Meta tag's consent settings to require additional consent for `ad_storage`, or trigger it only from a consent event; Meta's tag does not read Google Consent Mode on its own.

## How does Meta's consent API work?

Meta provides two calls for sites that load the Pixel before a choice is made. Call `fbq('consent', 'revoke')` before `fbq('init')` on every page, and the Pixel will not send events to Meta. When the visitor consents, call `fbq('consent', 'grant')` and events start flowing.

```js
fbq('consent', 'revoke'); // on every page, before init
fbq('init', 'YOUR_PIXEL_ID');
fbq('track', 'PageView');

// Later, from your banner's accept handler:
onConsent('marketing', () => fbq('consent', 'grant'));
```

This is useful as a safeguard, but it is weaker than blocking. With revoke in place, the browser still downloads `fbevents.js` from Meta, which sends the visitor's IP address and browser details to Meta before any choice. For EU and UK traffic, block the script and keep the consent calls as a second line of defense, for example when a visitor later withdraws consent on a page where the Pixel already loaded.

## What about the Conversions API?

The Conversions API (CAPI) sends events from your server to Meta instead of from the browser. It is often presented as a fix for ad blockers and browser restrictions, and sometimes, wrongly, as a way around consent.

Server events still contain personal data: the `_fbp` and `_fbc` values, IP addresses, user agents and often hashed email addresses or phone numbers. Sending them to Meta for advertising needs a lawful basis, and for EU and UK visitors that is normally the same consent you need for the browser Pixel. The values from `_fbp` and `_fbc` also come from cookies the visitor had to consent to in the first place.

Gate both channels on the same choice:

| Scenario | Browser Pixel | Conversions API |
| --- | --- | --- |
| EU or UK visitor accepted marketing | Load and track | Send, with the same `event_id` for deduplication |
| EU or UK visitor refused or has not chosen | Do not load | Do not send |
| US visitor, no opt-out | Load and track | Send |
| US visitor opted out or sent GPC | Do not load, or load with Limited Data Use | Do not send, or send with Limited Data Use |

Pass the consent state to your server with each request, or read it from the consent record, and check it before calling the API. See [server-side tagging and consent](/blog/server-side-tagging-and-consent) for the general pattern.

## How do I handle US privacy laws?

US state laws such as California's are mostly opt-out regimes: you can run the Pixel by default, but you must stop "selling" or "sharing" data when a visitor opts out. Meta's Limited Data Use (LDU) option tells Meta to restrict how it processes events from those visitors.

```js
// Let Meta apply Limited Data Use based on the visitor's location
fbq('dataProcessingOptions', ['LDU'], 0, 0);
fbq('init', 'YOUR_PIXEL_ID');
```

Call it before `init`. The Conversions API accepts the same data processing options per event. If a visitor sends [Global Privacy Control](/blog/global-privacy-control) or opts out through your banner, either stop loading the Pixel for them or apply LDU, and do the same on the server.

## How do I check that it works?

Open your site in a private window with an EU location or VPN, and before clicking anything:

1. In the browser's network panel, filter for `facebook`. There should be no requests to `connect.facebook.net` or `facebook.com/tr`.
2. In the storage panel, check that no `_fbp` or `_fbc` cookie exists.
3. Accept marketing cookies and confirm that the Pixel loads, the cookies appear and events show in Meta's Events Manager.
4. Withdraw consent and confirm the Pixel stops after the next page load.

Repeat with a refusal to confirm nothing loads, and with a `?fbclid=test` URL to confirm `_fbc` is only set after consent. A [cookie audit](/blog/how-to-run-a-cookie-audit) should include these checks on a schedule, because Pixel snippets have a way of reappearing in templates and plugins.

## Bottom line

Treat the Meta Pixel as advertising tracking, because it is. Block the script until consent, use `fbq('consent')` as a safeguard, gate the Conversions API on the same choice and use Limited Data Use and GPC for US opt-outs. Tools like Cookiesh block known trackers such as the Pixel until visitors consent, and scheduled scans flag new scripts, so a stray snippet does not slip through.

*This article is general information, not legal advice. For decisions about your specific situation, consult a qualified privacy professional.*

## FAQ

### Can I load the Meta Pixel with consent revoked and grant it later?

Meta supports this pattern, and it stops events from being sent until you grant consent. Loading the library still connects the visitor's browser to Meta, though, so for EU and UK visitors it is safer to block the script entirely until consent and use the consent API as a second safeguard.

### Does the Conversions API avoid the need for cookie consent?

No. Server events usually include identifiers taken from cookies, such as _fbp and _fbc, or hashed contact details, which are personal data. Sending them to Meta needs a lawful basis under GDPR, which for advertising is normally consent.

### Is the Meta Pixel covered by Google Consent Mode?

No. Consent Mode only adjusts the behavior of Google tags. The Meta Pixel ignores it, so you need to gate it through your consent tool, your tag manager's consent settings or your own code.

### Am I responsible for what Meta does with Pixel data?

Partly. In Fashion ID, the CJEU held that a site embedding a Facebook plugin is a joint controller with Facebook for collecting and transmitting visitor data. That reasoning is widely applied to the Pixel, so you are responsible for getting consent and informing visitors.

## Sources

- [General Data Protection Regulation and the Meta Pixel, Meta for Developers](https://developers.facebook.com/docs/meta-pixel/implementation/gdpr)
- [Data Processing Options for US users, Meta for Developers](https://developers.facebook.com/docs/marketing-apis/data-processing-options)
- [Case C-40/17, Fashion ID, CJEU](https://curia.europa.eu/juris/liste.jsf?num=C-40/17)