How to check if your Meta Pixel is working

• Meta Ads Data Advisor (formerly Meta Pixel Helper): Meta’s free Chrome extension. It shows which pixels and events a page sends.
• Events Manager: the Test events tab shows what Meta receives while you browse, Diagnostics lists problems Meta has detected, and Settings holds your pixel ID.
• Your browser’s developer tools: the Network tab shows every request the pixel sends, the Application or Storage tab shows its cookies.
• Google Tag Manager’s Preview mode (Tag Assistant), if the pixel is a GTM tag: it shows whether the tag fired.
• Shopify Pixel Helper, if your Meta events come from a Shopify custom pixel: Shopify’s own tool for testing custom pixels.

Every check compares what the page sends with one number, your pixel ID. In Events Manager, open Data sources in the left menu and select your pixel (Meta also calls it a dataset). The ID is on the Settings tab. If you have several pixels, note which one your ad sets use in their conversion settings. That is the one that has to receive your events.

Install Meta Ads Data Advisor in Chrome, turn off any ad blocker for your site (Meta asks for this, since blockers stop the extension from detecting the pixel), open your landing page and click the extension’s icon. It lists every pixel ID on the page, its status, and the events each one sent with their parameters.

Meta describes the pixel statuses like this: Active means it works correctly, Warning means it is not set up correctly, Inactive means it is not sending events correctly. Events get similar statuses, plus Error for a critical configuration issue.

Look for:

• A pixel ID that is not yours, or more than one. Compare it with the ID from Events Manager. A second ID is often a leftover from an old agency or a second plugin. Unless you run two ad accounts on purpose, one of them is noise.
• The same event twice, for example two PageView events for one page load. That doubles your counts.
• Warnings about missing parameters, such as a Purchase without value or currency.

What the extension does not show: what happens before cookie consent, how the page behaves for a visitor from an ad, and anything your server sends. It only sees your own browser, with your own cookies and your own earlier consent choices. Meta also notes that custom conversions and some button-click events may not appear in it.

In Events Manager, open your pixel, go to Test events, enter your page URL and click Open website. Browse the page in the window that opens. Events appear in Events Manager within seconds, as long as the Test events tab stays open.

This is the only place that shows what Meta actually received, including events from your server (Conversions API). It is also how you check that the pixel fires correctly on specific pages: keep clicking through the site in the test window. If your setup tracks them, a product page should add ViewContent, adding to cart should add AddToCart, starting checkout InitiateCheckout, and so on. Check:

• every event you expect shows up once, with the parameters you expect;
• browser and server copies of the same event are marked Deduplicated. If they are not, Meta counts both. Deduplication needs an event ID on both copies (see check 6).

Then open the Diagnostics tab. It lists problems Meta has detected with your events.

Open your page in a private window, so you have no earlier consent stored. If your banner only shows to EU visitors, you need to be in the EU or use an EU VPN. Before you touch the banner:

1. Open developer tools (F12) and go to the Network tab.
2. Type facebook.com/tr in the filter box.
3. Reload the page and wait a few seconds without clicking anything.

Any request in the list means the pixel sent data before the visitor answered the banner. The ev= part of each request shows the event, usually PageView, and id= shows the pixel ID. Common causes are a pixel pasted straight into the site’s header or theme, or a Tag Manager tag that fires on all pages without a consent condition. Our guide on wiring the pixel to your consent setup goes through the fixes.

Keep the same window and filter, and click Accept all on the banner. Within a couple of seconds you should see a PageView request. If nothing appears, the consent tool never releases the pixel, and Meta gets almost no data from consenting visitors. That is worse than firing too early, because ad delivery runs nearly blind. See the pixel does not fire after consent.

When someone clicks a Meta ad, the landing URL gets an fbclid parameter. The pixel stores it in a first-party cookie called _fbc and sends it with later events. That is how Meta ties a sale three pages later to the ad click.

To test it, open your page with a made-up click ID, for example https://your-site.com/landing?fbclid=test123, and accept cookies. Then in developer tools go to Application (Chrome) or Storage (Firefox), open Cookies for your domain and find _fbc. It should look like fb.1.1733312345678.test123, ending with your test value.

If there is no _fbc, or it does not contain your value, check for redirects that drop URL parameters (for example from http to https, or to a language version of the page) and for consent settings that block the cookie. Details in the click ID guide and in our post on fbclid and the _fbc cookie.

If you use the Conversions API, or a tool that sends events from your server, every browser event needs an event ID that matches its server copy. In the Network tab, click a facebook.com/tr request and look at its parameters for eid. If eid is missing, Meta cannot match browser and server copies, and you get double counting. See how to add event IDs.

These steps work on any site, not only your own:

1. Data Advisor. Open the site and click the extension. It lists every pixel ID it finds.
2. Page source. Right-click, choose View page source and search for fbevents.js or fbq('init'. The number inside fbq('init', ...) is the pixel ID.
3. Network tab. If the source shows nothing, the pixel may be loaded by Google Tag Manager or another script, or only after consent. Filter the Network tab by facebook.com/tr, accept the cookie banner and watch. Each request’s id is a pixel ID.

No requests even after you accept means no working pixel on that page, as far as a browser can tell. Server events never show up in a browser, so a site can still send data through the Conversions API.

A pixel that fires is not automatically a pixel that reports the right things. Check four points:

• The ID. The id in each request, or the ID in Data Advisor, matches the pixel your ad sets use.
• The event names. Meta has 17 standard events (a standard event is one Meta recognizes and can optimize for), such as ViewContent, AddToCart, InitiateCheckout, Purchase, Lead, CompleteRegistration, Contact and Schedule. Use the standard name for any action you optimize for. A self-made name like order_completed is a custom event, and Meta does not treat it as a purchase.
• The parameters. Meta lists value and currency as required for Purchase. In the Network tab they appear in the request as cd[value] and cd[currency].
• The moment. A Lead should fire when the form is actually sent, not when someone clicks into it, and a Purchase once per order on the confirmation step. If your custom conversions use URL rules (for example “URL contains /thank-you”), check that the rule still matches your real confirmation page after every site change.

• Test events: within seconds, while the Test events tab stays open.
• Events Manager overview: Meta’s developer documentation says a new PageView should show up there, and to wait a few minutes and refresh if it does not.
• Server events: Meta says these should appear within about 20 minutes.
• Automatic advanced matching: Meta says results can take up to 48 hours to show after you turn it on.
• Ads Manager: attributed results lag further. For some iOS conversions Meta uses statistical modeling, and it says modeled conversions can be reported up to three days late.

If nothing shows up in Test events while you browse, waiting will not help. Something is broken.

If Data Advisor finds no pixel, Test events stays empty, or events are missing, troubleshoot in this order:

• An ad blocker or privacy extension in your own browser. Turn them off for your site, or test in a separate browser profile without extensions.
• Consent. The pixel waits for consent you have not given yet, or never fires after you accept (checks 3 and 4).
• Pixel code missing on some pages. Meta says to put the pixel base code inside the <head> of every page you track. Landing page builders, separate templates and checkout pages often miss it.
• The wrong pixel ID: a typo, an old pixel, or a plugin connected to another pixel. Events then arrive, just in the wrong place.
• Google Tag Manager: the container version with the Meta tag was never published, the tag is paused, or its trigger never runs. Preview mode shows which.
• Traffic permissions. In the pixel’s Settings in Events Manager, an allow list or block list controls which domains may send events. If your domain is not allowed, its events are blocked, and Meta says events lost that way cannot be recovered.
• Caching. A page cache or CDN still serves the old page without your change. Clear it after every change.
• The pixel installed twice. See duplicate Meta Pixel events.

Checks 1 and 3 to 6 are what IsPixelWorking runs automatically. A browser in the EU opens your page twice, once without touching the banner and once arriving from a Meta ad with consent accepted, then clicks your main buttons. The report shows every event, when it fired against the moment of consent, and how to fix what is wrong. It is free and usually takes under a minute. Check 2 still needs your Events Manager, because only Meta can see what Meta received.