How to Tell if a Website Uses the Meta (Facebook) Pixel

To tell if a website uses the Meta (Facebook) Pixel, open the DevTools Network tab, filter for tr?, and reload: the pixel sends its tracking beacons to facebook.com/tr, and watching those fire is close to definitive. Confirm it in the source — search for fbevents.js (the pixel loads connect.facebook.net/en_US/fbevents.js) and the fbq('init', PIXEL_ID) call that initialises it. A _fbp cookie under Application > Cookies is strong, independent confirmation. This guide walks through every signal, shows how to capture the pixel ID, and covers the privacy and consent context that surrounds advertising trackers like this one.

It is a focused companion to how to find out what analytics a website uses and connects to how to check if a website uses Google Tag Manager, since the Meta Pixel is very often loaded through GTM.

What the Meta Pixel is

The Meta Pixel — formerly the Facebook Pixel — is the tracking code that powers Facebook and Instagram advertising. A business installs it on its site so Meta can measure ad-driven conversions (purchases, sign-ups, leads), build retargeting audiences from visitors, and optimise ad delivery. For detection, the important consequence is that the pixel has a stable, well-documented install pattern: a specific script (fbevents.js), a specific initialisation function (fbq), a specific data endpoint (facebook.com/tr) and a specific cookie (_fbp). Each of these carries a recognisable Meta domain or name, which makes the pixel one of the more reliably identifiable trackers on the web. It is also extremely widely deployed across ecommerce and lead-generation sites, so it is a common find wherever a company runs paid social.

Signal 1: the fbevents.js script and fbq init

The primary fingerprint is the loading script paired with its initialisation call. The Meta Pixel loads its library, fbevents.js, from connect.facebook.net (the standard path is connect.facebook.net/en_US/fbevents.js). The install snippet then defines the fbq function and calls fbq('init', 'PIXEL_ID') followed by fbq('track', 'PageView'). The combination is the definitive marker: connect.facebook.net/en_US/fbevents.js is Meta's pixel library, and the fbq('init', ...) call carries the numeric pixel ID. So finding the fbevents.js request in the Network tab, or the fbq('init', ...) call in the page source, is essentially proof the Meta Pixel is present — and the ID in the init call identifies the advertiser account at the same time.

Signal 2: the tr beacons to facebook.com

The Meta Pixel sends the events it captures as small tracking beacons to facebook.com/tr, and watching them is a great live confirmation. Open DevTools (F12), go to the Network tab, type tr? into the filter box, and reload: you will see requests to facebook.com/tr?... fire as the pixel records a PageView and any other events (such as ViewContent, AddToCart or Purchase on an ecommerce site). Inspecting one of these beacons shows the pixel ID (id=...), the event name (ev=PageView) and other parameters being sent to Meta. The /tr endpoint is pixel-specific, so filtering for tr? is one of the cleanest single checks you can run — and it confirms the pixel is actively sending data, not merely referenced.

Signal 3: the _fbp cookie (and _fbc)

The Meta Pixel sets a recognisable first-party cookie, readable under Application > Cookies. The headline one is _fbp — the pixel's browser identifier, which it sets to recognise a browser and attribute activity to Meta advertising. Closely related is _fbc, which stores the click identifier (fbclid) when a visitor arrives from a Meta ad, used for click attribution. Finding _fbp is strong, independent confirmation that the Meta Pixel is installed and active, and because it is set client-side by the pixel itself, it corroborates the script and network signals neatly. If you see _fbc too, it means someone reached the site via a Facebook or Instagram ad — a small bonus insight into their acquisition.

Signal 4: the pixel ID and multiple pixels

Running through every other signal is the pixel ID — the numeric identifier that appears in the fbq('init', 'PIXEL_ID') call and as the id parameter in the /tr beacons. Capturing it both confirms the pixel and names the advertiser account it reports to, which is valuable for verifying that two properties belong to the same business or for spotting an agency's pixel. Note that a site can run more than one pixel: a business with several brands, an agency managing campaigns, or a testing setup may include multiple fbq('init', ...) calls with different IDs, each firing its own /tr beacons. So capture every ID you see rather than assuming a single pixel — the set can reveal agency relationships or multiple business units behind one site.

The signal table

Signal	Where to find it	What it means
connect.facebook.net/en_US/fbevents.js	Network tab, View Source	Meta Pixel library loading — strong
fbq('init', 'PIXEL_ID') + fbq('track','PageView')	View Source	Pixel initialising — strongest single signal
facebook.com/tr?... beacons	Network tab (filter tr?)	Pixel actively sending events — concrete confirmation
_fbp cookie (and _fbc)	Application > Cookies	Meta Pixel browser ID — strong, independent confirmation
Numeric pixel ID (id= in /tr, init call)	Network tab, View Source	Identifies the specific advertiser account
Multiple fbq('init', ...) calls	View Source, Network tab	More than one pixel — agency or multi-brand setup

Any single row is a strong signal; the fbq init plus the /tr beacons are conclusive.

Method 1: the Network tab (filter "tr?")

The most reliable check is to watch what fires. Open DevTools (F12), go to the Network tab, type tr? into the filter, and reload. The facebook.com/tr?... beacons are the pixel's data hits; clicking one reveals the pixel ID, the event name and the parameters sent to Meta. Clear the filter and you can also see the connect.facebook.net/en_US/fbevents.js library load and any googletagmanager.com/gtm.js request. Interacting with the page (adding to cart, submitting a form) often triggers additional /tr beacons for events like AddToCart or Lead, which shows what the advertiser is optimising for. This method is the most thorough because it captures the pixel firing even when it is injected dynamically through a tag manager.

Method 2: View Source

A static source check is quick and catches the standard install. Open the page, press Ctrl/Cmd + U, and search for fbevents.js, fbq or connect.facebook.net. The pixel's base-code snippet — the one that defines fbq and calls fbq('init', 'PIXEL_ID') — is usually placed in the HTML head, so a source search surfaces it along with the pixel ID. Searching for multiple fbq('init' occurrences reveals whether more than one pixel is present. The caveat is the usual one: when the pixel is loaded through Google Tag Manager, the fbq init may live inside the GTM container rather than the page source, so if the source comes up empty but you suspect a pixel, fall back to the Network tab.

Method 3: cookies and Console

Two quick confirmations round things out. In Application > Cookies, find the _fbp cookie (and _fbc if present) to confirm the pixel is active in your session. In the Console, the pixel exposes the fbq function, so typing typeof fbq and seeing "function" is a supporting signal; you can also inspect fbq.instance or the pixel's queue for the configured IDs. The cookie check is especially useful because it confirms the pixel actually fired and set its identifier, not merely that a script was referenced — the same "did it actually fire?" discipline that makes analytics detection reliable.

The Meta Pixel and Google Tag Manager

An important nuance: the Meta Pixel is very often loaded through Google Tag Manager rather than hardcoded. When that is the case, the fbq('init', ...) call lives inside a GTM tag rather than the page source, but the pixel still loads fbevents.js and fires /tr beacons exactly the same way — so the Network-tab method detects it regardless. The practical check: confirm the pixel via the /tr beacons and fbevents.js, then look for a googletagmanager.com/gtm.js request. If GTM is present, it is likely orchestrating the pixel alongside other tags (such as GA4 and ad pixels); if there is a direct fbq snippet in the source and no GTM, the pixel is hardcoded. This is the same container/tag relationship covered in how to check if a website uses Google Tag Manager — detect the pixel first, then note how it is loaded.

Privacy, consent and the Conversions API

The Meta Pixel sits squarely in privacy-sensitive territory, so a few points of context matter. Because the pixel shares behavioural data with Meta, many sites gate it behind a consent banner under regulations like GDPR — meaning the /tr beacons and _fbp cookie may not fire until you accept cookies. So if you see no pixel activity, interact with the consent prompt before concluding it is absent; the pixel may simply be waiting for consent. Separately, some businesses now send conversion data to Meta server-side via the Conversions API (CAPI) in addition to, or instead of, the browser pixel. Server-side data is not visible from the front end, so a site using CAPI only would not show the usual /tr beacons — an honest limit of client-side detection. When you detect the browser pixel, report it confidently; when you do not, note that a server-side integration could still exist beyond what the browser reveals.

A worked example

You want to know whether a competitor runs paid social. You load their store, open the Network tab, type tr? into the filter, and reload — and a facebook.com/tr?id=998877665544&ev=PageView beacon fires. The Meta Pixel is active, ID 998877665544 captured. You clear the filter and see connect.facebook.net/en_US/fbevents.js loading, and Application > Cookies shows _fbp. Adding a product to the cart triggers a second /tr beacon with ev=AddToCart, so they track ecommerce events for ad optimisation. You also notice a googletagmanager.com/gtm.js request and a gtag/js?id=G- load, so GTM is orchestrating the pixel alongside GA4. The read: an active Meta advertiser tracking conversions through GTM, with GA4 for analytics — a paid-social, data-driven operation. A minute's work yields the pixel, its ID, the events it tracks and the surrounding stack.

What the Meta Pixel reveals about a company

Finding the Meta Pixel tells you the company runs Facebook and Instagram advertising with conversion tracking — a clear signal it invests in paid social as an acquisition channel. The events it fires refine the read: a pixel tracking only PageView is a basic install, while one firing ViewContent, AddToCart, InitiateCheckout and Purchase indicates a mature ecommerce advertiser optimising for the full funnel. Multiple pixels can reveal an agency relationship or several brands under one roof. And the pixel rarely travels alone: alongside GA4, a tag manager and perhaps other ad pixels (Google Ads, TikTok, LinkedIn), it helps map which channels a company invests in and how data-driven its marketing is. For advertising and martech sellers this identifies an active advertiser; for competitive research it shows a rival's paid-social commitment; for a privacy review it is one of the main third-party trackers to account for. It is exactly the kind of signal that feeds technographic qualification.

How accurate is Meta Pixel detection?

Very accurate for the browser pixel. The fbevents.js script, the fbq('init', ...) call, the facebook.com/tr beacons and the _fbp cookie are intrinsic to how the pixel installs and are not used by unrelated tools, so confirming the pixel is reliable. The two things to watch are consent and server-side tracking. Consent banners may hold the pixel until you accept cookies, so interact with the prompt before concluding it is absent. And the Conversions API sends data to Meta server-side, invisible to the browser — so a site could share conversion data with Meta without a visible browser pixel, which front-end detection cannot see. So "does this site run the browser Meta Pixel?" is answerable with confidence; "does this company send any data to Meta at all?" occasionally is not, because some of it may flow server-side. Catch the consent gate, capture the pixel ID, and be honest about the server-side boundary.

The workflow

1. Filter the Network tab for tr? and reload to watch facebook.com/tr beacons fire.
2. View Source and search fbevents.js/fbq for the init call and pixel ID.
3. Check Application > Cookies for _fbp (and _fbc).
4. Capture every pixel ID from the init calls and /tr requests, noting multiple pixels.
5. Handle consent and check for GTM, and accept that server-side CAPI data is invisible.

Go deeper

• The measurement layer beside it: how to find out what analytics a website uses.
• The analytics it often rides with: how to tell if a website uses Google Analytics 4.
• The tag hub that often loads it: how to check if a website uses Google Tag Manager.
• Turn the signal into qualification: what is technographics?

Want the Meta Pixel, the ad and analytics stack, and full technology picture in one report? Analyse any site with StackOptic — free, no sign-up.