The Meta Pixel is one of the most widely installed marketing tools on the web, and one of the most closely watched by European data protection authorities: cross-site tracking, transfers to the United States and an advertising purpose make it a high-risk case. This guide covers the cookies it sets, the legal reasons consent is required, three ways to block it, its relationship with Google Consent Mode and the Conversions API, the impact on your campaigns, and a final checklist.
What is the Meta Pixel and why does it raise GDPR issues?
The Meta Pixel is a JavaScript snippet supplied by Meta (Facebook, Instagram) that advertisers place on their site to measure the effectiveness of their ads and build audiences. As soon as it loads, it writes cookies in the visitor's browser and sends events (page views, add to cart, purchases) to Meta.
The cookies set by the Meta Pixel
The Pixel relies on two main cookies:
_fbpidentifies the browser with a random identifier. Meta uses it to recognize the same visitor across visits and attribute conversions. According to Meta, it lasts 90 days._fbcstores the ad click identifier (fbclid) when the visitor arrives from a Facebook or Instagram ad. It only exists when the landing URL containsfbclid, and Meta recommends a 90-day expiry.
Both are first-party cookies, written on your domain, but they serve Meta's advertising. They belong in the "marketing" category: they are not needed for your site to work and qualify for no exemption. For a detailed look at their content and lifetime, read our article on the _fbp and _fbc cookies.
Why consent is mandatory
Article 5(3) of the ePrivacy Directive only allows storing or reading information on a user's device with consent, unless it is strictly necessary for a service the user explicitly requested. Ad measurement and retargeting never are. The data collected also feeds Meta's targeting, including on other sites and platforms: for this cross-site advertising purpose, legitimate interest is not a defensible basis.
European authorities have repeatedly stated that advertising trackers, Meta's included, may only be set after free, specific, informed and unambiguous consent, and several enforcement actions have targeted sites that loaded advertising scripts before consent.
You are joint controller with Meta
In its Fashion ID judgment (C-40/17, 29 July 2019), the Court of Justice of the EU held that a website embedding a Facebook plugin is joint controller with Meta for the collection and transmission of its visitors' data, and that it is up to the website, not Facebook, to obtain consent beforehand. The same reasoning applies to the Pixel: you chose to install it, so you are responsible for asking first. Record this processing and the joint controllership in your register of processing activities.
Data transfers to the United States
Data collected by the Pixel can be transferred to Meta Platforms Inc. in the United States. After the Privacy Shield was struck down (Schrems II, July 2020), these transfers had to rely on standard contractual clauses with supplementary measures, and in May 2023 the Irish Data Protection Commission fined Meta 1.2 billion euros over its EU-US transfers. The EU-US Data Privacy Framework, adopted in July 2023, now covers transfers to certified companies and was upheld by the EU General Court in September 2025, but it is still being challenged. Mention these transfers in your privacy policy and keep an eye on developments.
How to block the Meta Pixel before consent
The principle is simple: the Pixel script must not run until the visitor has accepted marketing cookies. Three methods exist depending on your setup.
Method 1: blocking through your CMP
The most reliable solution is a CMP that blocks scripts by category. With FlowConsent, you declare the Meta Pixel in Builder > Services: the service comes from a maintained catalog with its cookies and detection patterns, it is classified as marketing, and the banner only loads it after consent. Until the visitor accepts, the script does not run and no _fbp cookie is written. The services and legal bases documentation explains how the catalog works.
The same principle applies to Google Analytics or any other third-party tracker. Watch out for pixels injected outside your code: Shopify's Facebook & Instagram channel, Meta for WooCommerce or Wix Marketing Integrations add the Pixel on their own. Turn off their pixel and declare the service in your CMP instead; the Shopify installation guide shows how for that platform.
Method 2: conditional loading through Google Tag Manager
If the Pixel lives in Google Tag Manager, remember that GTM has no built-in consent check for non-Google tags. Open the tag, go to Advanced Settings > Consent Settings, select Require additional consent for tag to fire and add ad_storage. The tag then only fires if that signal is granted when its trigger occurs. A Meta tag left on "Not set" fires without any check, which is the most common cause of a Pixel that still fires after a refusal. The GTM installation guide and our GTM and Consent Mode guide detail this setup.
Method 3: native JavaScript blocking
Without a CMP or GTM, you can condition the loading yourself: give the Pixel's <script> tag the type text/plain and only activate it once consent is confirmed. Meta also offers fbq('consent', 'revoke') before initialization, then fbq('consent', 'grant') once the visitor accepts. Meta documents this as pausing event sending, not as preventing cookie writes, so loading nothing before consent remains the safer choice. This approach works but is fragile: every site update or new script requires a manual check. That is why a CMP remains the recommended solution.
Meta Pixel and Google Consent Mode v2
Google Consent Mode v2 introduces the ad_storage and ad_user_data signals that govern Google's advertising tags. The Meta Pixel is not a Google product, but in GTM you can use the same signals to control it: as long as ad_storage is denied, the Meta tag does not fire; once the visitor accepts marketing cookies, it loads normally. This is the most common setup for advertisers running both Google Ads and Meta Ads.
One important difference: Google's advanced mode sends cookieless pings to Google even without consent, but only for Google tags. The Meta Pixel has no equivalent mechanism. Without consent, it simply must not load. To choose your Google setup, see our comparison of basic and advanced Consent Mode.
Meta's Conversions API: an alternative to the Pixel?
The Conversions API (CAPI) sends conversion events directly from your server to Meta, without going through the visitor's browser. It writes no cookie in the browser and is not affected by ad blockers, which is why it is often used alongside the Pixel to recover conversions.
It does not exempt you from consent. The data sent (hashed email address, IP address, user identifiers, fbp and fbc values) remains personal data under the GDPR, and the legal basis for ad retargeting is consent: legitimate interest is rarely defensible here. Never use CAPI to get around a refusal.
The right approach is to combine the Pixel and the Conversions API and make both depend on the same marketing consent. Your server must therefore know the visitor's choice: FlowConsent's server SDK reads the decision stored by the banner, denied by default, so your backend only sends events for visitors who accepted. Our article on server-side tagging and consent goes further.
Transparency: banner, cookie policy and register
Blocking is not enough; the visitor must also know what they are accepting:
- In the banner, name Meta or the "advertising and targeting" purpose in the list of purposes subject to consent.
- In the cookie policy, list the Meta Pixel, the
_fbpand_fbccookies, their duration and the cross-site advertising purpose. - In your privacy policy and register, describe the processing, the joint controllership with Meta and the transfers outside the EU.
- Keep proof of consent. You must be able to show that the visitor agreed to marketing cookies: your CMP should store this proof with a timestamp, an identifier and the accepted categories.
The impact of blocking on your Meta Ads campaigns
Blocking the Pixel before consent reduces the volume of data collected; that is a fact. If 40% of your visitors refuse marketing cookies, roughly that share of conversions will no longer be measured by the Pixel.
What you lose
Retargeting is hit directly: visitors who did not consent are not added to your custom audiences. Meta's algorithm receives fewer signals to optimize campaigns, which can weigh on automated bidding. Conversion tracking becomes partial.
What you can do
Improving your consent rate is the first lever: a compliant, clear and non-manipulative banner usually achieves better acceptance than a poorly designed one or one using dark patterns, which also exposes you to sanctions. The Conversions API, combined with the Pixel and conditioned on consent, recovers part of the conversions lost to browsers and ad blockers. Finally, cookieless analytics can supplement your audience data without relying on advertising identifiers.
Common mistakes with the Meta Pixel and the GDPR
- Loading the Pixel in the `<head>` without blocking. The standard code from Meta Events Manager runs as soon as the page loads. Pasted as is, it tracks every visitor before they can refuse. This is the most frequent and most sanctioned violation.
- Letting a platform inject the Pixel. E-commerce extensions, sales channels and site-builder integrations add the Pixel outside your code and bypass your banner.
- Classifying the Pixel as "functional" or "statistics". The Pixel does not measure your site's performance for you: it sends data to Meta for ad targeting. It is marketing.
- Blocking the script but not every source of `_fbp`. Check that no other script, plugin or GTM tag recreates the cookie in the background. A regular cookie audit catches these leaks.
- Forgetting `_fbc` in the audit. It only appears when the URL contains
fbclid: test the landing pages of your Meta campaigns with that parameter. - Using CAPI to get around a refusal. Server-side sending does not remove the consent requirement when the data identifies a person.
- Confusing your CMP's consent with Meta's terms. The consent collected on your site covers cookies and the related processing; Meta's own terms are separate, and both must coexist.
- Treating Meta as sole controller. You are joint controller for the collection on your site, with the obligations that come with it.
- Not keeping proof of consent. Without a timestamped record, you cannot demonstrate that the visitor accepted.
Checklist: a GDPR-compliant Meta Pixel
- Classify the Meta Pixel as "marketing" in your CMP.
- Remove any hard-coded Pixel and turn off pixels injected by extensions or sales channels.
- Block loading until consent through your CMP, a GTM additional consent check on
ad_storage, or a conditional script. - In private browsing, check that the Pixel does not load before any click on the banner.
- Make the Conversions API depend on the same consent, and never send identifying data for visitors who refused.
- Name Meta in the banner, list
_fbpand_fbcwith their duration in the cookie policy, and update your privacy policy. - Document the joint controllership and the transfers in your register.
- Check that your CMP records proof of consent.
- Run a scan of your site to confirm that
_fbpand_fbcdo not appear before consent, including on campaign landing pages withfbclid. - Audit regularly: a Pixel update or a new plugin can reintroduce loading without consent. Continuous monitoring is described in the compliance verification documentation.
Conclusion
The Meta Pixel is a powerful tool for your Meta Ads campaigns, but it writes marketing cookies that require prior consent in Europe and makes you jointly responsible for what it collects. Compliance comes down to blocking the script until consent, informing visitors clearly, making the Conversions API follow the same choice and checking regularly that nothing slips through. Run a free scan of your site to see whether the Meta Pixel sets cookies before consent.