The _fbp cookie (and _fbc) explained: what it is, lifetime and GDPR consent

What are the _fbp and _fbc cookies?

If you run a cookie scan on a site that uses Meta advertising, two names almost always show up: _fbp and _fbc. Both come from the Meta Pixel, the JavaScript snippet (fbevents.js) that advertisers install to measure conversions and build audiences for Facebook and Instagram campaigns. They are the building blocks Meta uses to connect what happens on your website with what happened on its platforms.

_fbp cookie description

According to Meta's own documentation, when the Pixel is installed and uses first-party cookies, it automatically saves a unique identifier to the _fbp cookie. Meta describes _fbp as a cookie that identifies browsers in order to provide advertising and site analytics services. In practice it lets Meta recognise the same browser across several visits to your site, even when the visitor never clicked an ad.

_fbc cookie description

_fbc only appears when someone arrives from a Meta ad. When a user clicks an ad on Facebook or Instagram, Meta appends a fbclid parameter (the ClickID) to your landing page URL. The Pixel reads that parameter and stores it in the _fbc cookie, so that a purchase or sign-up made later can be attributed to that specific click.

What do _fbp and _fbc actually contain?

Meta's Conversions API documentation on fbp and fbc gives the exact format of both values. They share the same four-part structure:

• _fbp: version.subdomainIndex.creationTime.randomnumber, for example fb.1.1596403881668.1116446470. The random number is generated by Meta's code to make the value unique.
• _fbc: version.subdomainIndex.creationTime.fbclid, for example fb.1.1554763741205.IwAR2F4-.... The last part is the click ID copied from the URL.
• version is always fb, subdomainIndex tells which domain level the cookie was set on (com = 0, example.com = 1, www.example.com = 2) and creationTime is a UNIX timestamp in milliseconds.

Neither value contains a name or an email address. That does not make them anonymous: a unique, persistent identifier attached to a browser is an online identifier, and the GDPR treats it as personal data as soon as it can be used to single out a person, which is exactly its purpose here.

How long do _fbp and _fbc last?

Meta states in its cookie information for Meta Quest that the _fbp cookie has a lifespan of 90 days. For _fbc, Meta's developer documentation recommends a 90-day expiration when you create the cookie yourself from the fbclid parameter. Browsers can shorten this: Safari, for example, limits the lifetime of some cookies set through JavaScript, which is one reason advertisers turn to server-side sending.

Ninety days is well within what most regulators consider reasonable for an advertising cookie. If you want to go further into durations and the 13-month guidance, see our article on cookie retention duration under GDPR.

First-party cookies, but still Meta's cookies

A frequent misunderstanding is that _fbp and _fbc are "safe" because they are first-party. They are first-party only in a technical sense: the Pixel script runs on your page and writes the cookies on your domain, so the browser treats them as yours and third-party cookie blocking does not stop them. The data, however, is sent to Meta with every Pixel event and used for Meta's advertising products.

Meta also uses its own cookies on its domains (such as facebook.com), which are third-party cookies from the point of view of your website. Whether the cookie is first-party or third-party changes how browsers handle it. It does not change the legal analysis: what matters is the purpose, and here the purpose is advertising.

Why _fbp and _fbc require prior consent

Article 5(3) of the ePrivacy Directive (2002/58/EC), as transposed in each member state, 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 are never strictly necessary for showing your website. In the UK, the ICO guidance on cookies applies the same logic under PECR: advertising cookies are not among the exemptions, and consent requires a clear positive action.

The Court of Justice of the EU has also addressed Facebook tools directly. In Fashion ID (C-40/17), decided on 29 July 2019, it held that a website embedding a Facebook plugin is a joint controller for the collection and transmission of visitors' data, and that it is for the website operator, not Facebook, to obtain consent beforehand. The same reasoning applies to the Pixel: you decide to install it, so you are responsible for asking first.

Consequences in practice:

• No _fbp or _fbc cookie, and no request to Meta, before the visitor clicks "Accept" (or enables the marketing category).
• Refusing must be as easy as accepting, and silence or scrolling is not consent.
• Withdrawing consent must stop the Pixel on the following pages.
• You need to be able to prove the consent you rely on.

For the full compliance picture of the Pixel itself (Limited Data Use, Advanced Matching, data transfers), read our Meta Pixel and GDPR compliance guide.

_fbp, _fbc, fbclid and the Conversions API

The Conversions API (CAPI) lets your server send events to Meta directly. To match those server events with browsers and ad clicks, Meta asks for two parameters called fbp and fbc, in exactly the same format as the cookies. Most implementations simply read the _fbp and _fbc cookies from the incoming request and forward them. If no _fbc cookie exists, Meta explains that you can still build the fbc value from the fbclid parameter in the URL.

This is where many setups go wrong. Moving tracking to the server does not move it outside the law:

• If your server or tag manager creates its own _fbc cookie from fbclid, that is still storage on the user's device and still needs consent.
• Forwarding fbp, fbc, IP address and user agent to Meta is a transfer of personal data for advertising, so it needs a legal basis, and for advertising that is in practice consent.
• Server events should therefore follow the same consent state as the browser Pixel, otherwise you are tracking refusers through the back door.

Our article on server-side tagging and consent explains how to pass the consent signal to the server.

How to block _fbp and _fbc until consent

The only reliable way to prevent these cookies is to stop the Pixel base code from running before consent. Here is a practical sequence:

1. Inventory every place the Pixel is loaded: theme code, a Shopify or WordPress plugin, Google Tag Manager, a partner integration. A duplicate installation is the most common reason _fbp appears before consent.
2. Gate the base code behind the marketing category of your consent banner, so that fbevents.js is only injected after acceptance. With FlowConsent, this is done by prior blocking of the script, without needing Google Tag Manager.
3. If you must keep the snippet in the page, Meta's GDPR implementation guide for the Pixel offers fbq('consent', 'revoke') before init, then fbq('consent', 'grant') once the user accepts. Meta documents this as pausing the sending of Pixel events; it does not document it as preventing cookie writes, so loading nothing before consent remains the safer choice.
4. Align your Conversions API with the same consent decision and do not forward fbp or fbc for visitors who refused.
5. Handle withdrawal: when consent is withdrawn, stop loading the Pixel and consider deleting the existing _fbp and _fbc cookies, which you can do because they sit on your domain.
6. Document it in your cookie policy and keep consent records as proof.

How to verify that it works

1. Open your site in a private window and do not interact with the banner.
2. In Chrome DevTools, go to Application > Cookies and check that neither _fbp nor _fbc exists.
3. In the Network tab, filter on facebook and confirm that neither fbevents.js nor requests to facebook.com/tr are sent.
4. Add ?fbclid=test123 to the URL and reload: still no _fbc before consent.
5. Click Accept: _fbp should appear, and _fbc if the URL carries a fbclid.
6. Start again and click Reject: nothing should be set, even after browsing several pages.

Repeat the test after each theme update or new plugin. An automated cookie audit helps you catch a Pixel that slips back in.

Conclusion

_fbp and _fbc are small, but they are the core of Meta's attribution: a browser ID and a click ID, both kept for around 90 days and both sent to Meta. Being first-party does not exempt them from consent, and neither does moving them to the Conversions API. Block the Pixel until the visitor accepts, mirror that choice on the server and test it regularly. To see whether _fbp or _fbc is set before consent on your own site, run a free scan: FlowConsent detects cookies automatically, blocks scripts until consent and keeps consent records for 13 months.