Why the Facebook pixel is still loading when your tags are blocked

All posts

The Facebook pixel usually loads for one of three reasons: its base code runs in your page head before the banner, its tag fires before your consent defaults are set, or the tag never required advertising consent. If all three are clean, another vendor’s script is probably injecting the pixel at runtime, and your container cannot gate a request it never made.

Rule out the ordinary causes first

Most of the time it is one of these.

• The pixel base code sits in your page head with no fbq('consent', 'revoke') above it, so it initialises before your banner renders.
• The tag fires on a trigger that runs before your consent defaults are set, so it reads no choice at all.
• The tag was never set to require advertising consent, so it fires whatever happens around it.
• A social embed, a like button or a comment widget is setting cookies of its own.

Check each on a live page, not in the container: how to know if a tag is really setting cookies before consent has the method. If those are clean and the requests persist, the cause sits outside your container.

A consent tool gates what your container controls

An advertising pixel reaches a page by one of three common routes, and a consent tool reaches each differently. Most published answers assume the first two.

The first is a tag in your container, which fires when the consent state says it may. The second is a script in your page source, which a consent tool can usually hold too, by recognising it before the browser runs it.

The third is the one most guides skip. A script that is already running, and that you legitimately allowed, loads its own advertising module at runtime and injects the pixel. Your container never made that request, so nothing you change inside it will stop it.

Here is what the third route looked like on a live estate we audited in August. Meta and LinkedIn cookies were being written before consent, and the internal diagnosis blamed the container tags. On a fresh session with the banner up and nothing clicked, both tags carried an advertising storage condition and neither fired. The cookies appeared anyway, with the same pixel IDs, because an allowed marketing platform tag loaded its own advertising pixel file, which loaded the Meta and LinkedIn libraries. Nothing was misconfigured; the boundary was not where anyone assumed.

How to tell which one you have

A few minutes, without opening the container.

1. Open the site on a fresh profile and decline everything

   No stored consent, the network panel open before the first paint, and a deliberate reject.

2. Filter for the pixel's own hosts

   For Meta that is connect.facebook.net for the library and facebook.com/tr for the event. Look in the application panel too: an _fbp cookie appearing on your own domain in that fresh session usually means the library loaded. No requests and no cookie means you do not have this problem.

3. Expand the initiator chain, and do not read only the top line

   This is the step most easily got wrong. Your tag manager often appears in the chain because it loaded the vendor script much earlier, which is not evidence that a tag manager tag made this request. What you want is the entry immediately above the pixel call: it names the script that owns it.

4. Check the container against what you just saw

   Open preview and check whether the advertising tags fired. A tag in the not fired list while the request still shows is not a contradiction: the two tools describe two different layers.

5. Follow the owning script back to its platform

   Find the vendor behind it, then its advertising integration setting. That setting, not your consent configuration, is putting the pixel on the page.

Why gating harder in the container cannot work

It feels like progress, which is why it is expensive. The team adds a consent condition to the advertising tags, then a blocking trigger, then an exception, and concludes the consent tool is broken, when every change went to a tag that was already not firing.

Separate this from the fault it is confused with. Your own tags firing before the banner registers its defaults is a timing problem, genuinely fixable in the container, and we covered it in why tags fire before the cookie banner loads. This is scope rather than timing: your tags behaved correctly and something outside their scope did the thing you were preventing.

Where the fix actually lives

Four levers. The right one depends on what the vendor script does before consent, and on which category the script should have been in to begin with: which consent category each third party script belongs in covers that decision.

• The vendor's own portal. Most platforms that inject advertising pixels expose a setting for it. Turning that integration off is cleanest: the script keeps doing its legitimate work and stops carrying somebody else's pixel.
• An early consent revoke call. fbq('consent', 'revoke'), running before anything can initialise the pixel, tells the Meta library to hold its events whoever loaded it. Meta’s own consent documentation describes the revoke and grant calls. A backstop rather than a full answer: the library still loads, and it only helps if your call truly runs first.
• The vendor's tag in your container. If a tag you own loads the vendor script, gate that tag on advertising consent. Blunt: you also lose whatever else that script does for visitors who decline, such as forms or chat.
• Category blocking at the consent tool. If the vendor script loads outside your container, categorise the script itself as advertising so the tool holds it back before it runs. Same trade off.

Then re run the same test: fresh profile, decline, filter, confirm nothing reaches the pixel hosts. One limit: this reads the browser only, so anything your servers send through a conversions API has to be checked at the source. Verifying at the destination rather than on the banner is the general habit, described in how to check your banner is really sending the consent signal.

Velo holds the scripts you mark with a consent category until that category is granted; a pixel another vendor injects without that mark still needs tracing back to the vendor.