Is my Meta pixel working? How to check it in two minutes

Your Meta pixel works if the browser sends a request to facebook.com/tr with your pixel ID and an event name (ev=PageView on every page, ev=Purchase on the order confirmation). Seeing fbevents.js load is not enough: the script can load and still send nothing, or send it twice.

Skip the DevTools: the free scan loads your page in a real browser, accepts and rejects the cookie banner, and shows what the Meta pixel actually sent.

At a glance

Tag script: connect.facebook.net/…/fbevents.js, plus a per-pixel config file from /signals/config/<pixel ID>
Event request: www.facebook.com/tr/?id=<pixel ID>&ev=PageView (GET, or POST for larger payloads)
Pixel ID: A number, usually 15 or 16 digits
Click ID: fbclid, stored by the pixel in the _fbc cookie
Consent: fbq('consent', 'revoke') before init, fbq('consent', 'grant') on accept

Check it yourself in two minutes

Open your site in a private window, open DevTools (F12 or Cmd+Option+I) and go to the Network tab.
Type facebook.com/tr in the filter box, accept the cookie banner and reload.
Click the first request. Under Payload (or the query string), check id is your pixel ID and ev is PageView. One request per pixel ID per page view is right; two with the same ID means the pixel is installed twice.
Place a test order (or open your order confirmation page in a test order) and look for ev=Purchase. Its parameters should include cd[value], cd[currency] and an eid (the event ID).
In Meta Events Manager, open your dataset and use Test events with your site URL to see the same events arrive in real time.

The Meta Pixel Helper extension for Chrome shows the same thing in a popup, but the Network tab is the ground truth: it shows what actually left the browser, including requests the extension does not label.

Why the Meta pixel breaks, and how to fix it

The pixel is installed twice

The most common Meta problem on stores: the theme or a developer added the base code, and later a Shopify or WooCommerce integration added it again. Every PageView and Purchase is then counted twice, which inflates reported ROAS and confuses bidding. In the Network tab you see two /tr requests with the same ev. Keep one install, usually the platform integration, and remove the other.

A second, different pixel ID is a related case: often an old agency's pixel that still receives your data. Check every ID belongs to an ad account you control.

Purchase has no value or currency

Without value and currency, Meta cannot report revenue or optimise for value. The call should look like this, with the order total and an ISO 4217 currency code:

fbq('track', 'Purchase', { value: 129.90, currency: 'EUR' }, { eventID: 'order-10045' });

Watch for values sent as text with a currency symbol ("€129,90") or with thousands separators: Meta expects a number.

Pixel and Conversions API are not deduplicated

If you also send events from your server (the Conversions API, often through a Shopify or tag manager integration), Meta counts the browser and server event as one only when both carry the same event name and event ID. The browser side passes it as eventID in the fourth argument (it appears as eid in the request); the server side sends event_id. A Purchase without eid next to a working Conversions API means double counting.

The pixel fires before consent

In the EU and the UK, the pixel may only set cookies and send events after the visitor accepts marketing cookies. Pixels added by an app or hard-coded in the theme often bypass the consent tool. The fix is to load the pixel through the consent tool, or call fbq('consent', 'revoke') before fbq('init', …) and grant it on accept. See Ad pixel fires before consent or after "reject".

Single-page apps send one PageView

On sites built with React, Vue or a headless storefront, the page does not reload when the visitor moves on, so the base code's single fbq('track', 'PageView') runs once. Fire a PageView on each route change, or check that your integration does it, otherwise retargeting audiences built on URL rules stay empty.

Email addresses in the request

Advanced matching should send customer data hashed. A plain email address in a /tr request usually comes from the page URL (a thank-you page with ?email= in it) or a custom parameter. Meta may then restrict the data, and it is a privacy problem in its own right. Remove personal data from URLs and let the pixel hash what it sends.

What the free scan checks

Meta pixel loads, and sends at least a page view
Only one Meta ID, or a warning if there are more
Meta pixel waits until the visitor accepts cookies
Meta pixel stops after the visitor clicks "reject all"
No email addresses in plain text in Meta pixel requests
On an order confirmation page: the purchase carries a value, a currency and an event ID
The fbclid click ID survives your redirects

Server-side events (Conversions APIs, server-side tagging) are invisible to a public scan, so the report never marks them as working or broken.

Sources

Updated 2026-10-27. Based on the platforms' public documentation and the requests their public tags make; menus and names change, so check the linked pages if a step looks different.