Why the Facebook pixel is still loading when your tags are blocked
A consent tool can only hold what your site loads: the tags in your container and the scripts in your page source. If the pixel arrives from a script another vendor runs on the page, loading its own advertising module at runtime, your container never made that request, and gating it harder cannot stop it.
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 is fully yours: it fires when the consent state you set says it may. The second is a script written into your page source, which a consent tool can usually hold too, because automatic blocking recognises a known script before the browser executes it and defers it until a category is granted.
The third is the one nobody writes about. 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.
Rule out the ordinary causes first
Most of the time it is one of these, all fixable where you have already been looking. Clear them first.
- 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 runs on an All Pages trigger rather than a consent aware one, so it fires regardless of the choice.
- 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.
If those are clean and the requests persist, keep reading.
Here is what the third route looked like on a live estate we audited this month. Meta and LinkedIn cookies were being written before consent, and the internal diagnosis blamed the container tags. Measured on a fresh session with the banner up and nothing clicked, both tags carried an advertising storage condition and neither fired: the defaults were present, all denied, and the denied signal was on the wire. 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
Two minutes, and the container never has to be opened.
Open the site on a fresh profile and decline everything
No stored consent, the network panel open from before the first paint, and a deliberate reject. If a previous choice is remembered, you are testing nothing.
Filter for the pixel's own hosts
For Meta that is
connect.facebook.netfor the library andfacebook.com/trfor the event. No requests at all means you do not have this problem.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.
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 network panel shows the request is not a contradiction. It is the confirmation: two tools telling you the truth about two different layers.
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
The failure mode here is expensive because it feels like progress. The team adds a consent condition to the advertising tags. Nothing changes. They add a blocking trigger, then an exception, then a second opinion, and conclude the consent tool is broken, when every change was applied 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.
- 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. 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 but effective: you also lose whatever else that script does for visitors who decline, which can include forms and 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 blocks by category before anything runs and shows what actually fired, the reading that separates a tag you control from a script that was never yours.
Common questions
What people ask about this topic.
Why is the Facebook pixel still loading when my tags are blocked?
Rule out the ordinary causes first: the pixel base code in your page head with no fbq consent revoke call above it, a tag on an All Pages trigger rather than a consent aware one, a tag never set to require advertising consent, and a social embed setting cookies of its own. If those are clean, the likely answer is that your tag manager is not what loads the pixel. A script from another vendor, already running and legitimately allowed, can load its own advertising module at runtime and inject the pixel from there. Your container never made that request, so no setting inside it can stop it.
How do I find out what is loading the Meta pixel on my site?
Load the site on a fresh browser profile, decline everything, and open the network panel before the first paint. Filter for connect.facebook.net and facebook.com/tr. When a request appears, expand its initiator chain rather than reading only the top line. A tag manager frequently appears somewhere in that chain because it loaded the vendor script much earlier, and that does not mean a tag manager tag made this request. What you want is the script immediately above the pixel call, because that is the thing that owns it.
Can a consent management platform block a pixel that another vendor's script injects?
Not by targeting the pixel, but usually by targeting the script that creates it. Automatic blocking recognises a script before the browser executes it, so a pixel created later at runtime by an already allowed script is not something it can see in advance. The workable options are to switch the advertising integration off in the vendor's own portal, to gate the vendor's tag on advertising consent, to categorise the vendor script itself as advertising, or to call fbq consent revoke early enough that the pixel holds its events whoever loaded it.
My Meta tag shows as not fired in preview but the pixel request still happens. What does that mean?
It usually means the container is behaving and something else is loading the pixel. The two readings are not contradictory: preview tells you the truth about your tag, the network panel tells you the truth about the page. When they disagree, expand the initiator chain and find the script immediately above the request. Adding further consent conditions to a tag that was already not firing changes nothing.
Your banner, your consent,
your data — all in one place.
