How a Tracking Pixel Works and What It Cannot See

What is a tracking pixel?

Marketers embed a tracking pixel, a 1x1 image referenced by a URL that identifies the campaign, so that rendering the page or the email forces a request to a server that logs it. The image is incidental. The request is the product.

Meta ships the pattern in its own documented base code, as the fallback for visitors whose browser will not run the JavaScript version:

<noscript>
  <img height="1" width="1" style="display:none"
       src="https://www.facebook.com/tr?id={your-pixel-id-goes-here}&ev=PageView&noscript=1"/>
</noscript>

Everything a pixel reports is in that URL or in the headers the client attaches. id names the account, ev=PageView names the event, noscript=1 records that this was the fallback path. The response body is irrelevant to the sender, which is why endpoints return a transparent 1x1 GIF or an empty 204 No Content and why the element is hidden with display:none.

What does the server actually receive?

Five things arrive with a pixel request, and only one of them is chosen by whoever placed the pixel.

Notice what is missing. There is no page title, no screen size, no scroll position and no time on page, because none of those exist at the moment an image is requested. A pixel hit is one line in an access log, and every field in it was either attached by the client automatically or written into the URL by the sender weeks earlier. Analysts routinely credit pixel data with detail it cannot hold, then explain the resulting gaps as ad blocking.

The Referer line is the one most people still get wrong. Browsers default to strict-origin-when-cross-origin, which MDN describes as sending "the origin, path, and query string when performing a same-origin request" but for cross-origin requests sending "the origin (only) when the protocol security level stays same (HTTPS to HTTPS)." A third-party pixel therefore learns the site, not the page, unless the page owner passed the path in the query string deliberately.

What can a pixel not do that a script can?

A pixel cannot read the page it sits on. It fires once, carries only what the URL already contained, and then the request is over.

Meta's documentation shows the gap inside one product. The JavaScript pixel, it says, "will track URLs visited, domains visited, and the devices your visitors use." The noscript image below it reports a single PageView with the parameters already written into the src. Same account, same event name, a fraction of the detail.

This is also why a pixel is the wrong tool and the wrong worry in most web analytics arguments. Script based measurement is what reads the page; the pixel is the degraded fallback. For the broader question of what a third-party request can join up across sites, cross-site tracking and the difference between first-party and third-party cookies matter far more than the size of the image.

Why do email open rates overstate opens?

Email open tracking is the classic pixel use case, and it is the one that broke first. There is no open event in email. There is only a remote image that the mail client may or may not fetch, so the entire metric rests on the client behaving the way it did in 2010.

Apple's Protect Mail Activity, the setting behind Mail Privacy Protection, breaks the inference in two places. Apple states that it "helps protect your privacy by preventing email senders, including Apple, from learning information about your Mail activity," and describes the mechanism without ambiguity: it "downloads remote content in the background by default", regardless of whether the recipient engages with the email. That single sentence converts an open rate into a delivery rate for every recipient with the setting on. On the network side Apple "routes all remote content downloaded by Mail through two separate relays operated by different entities", so the IP address that reaches the sender is not the recipient's, and "senders can't use your IP address as a unique identifier to connect your activity across websites or apps to build a profile about you."

Gmail attacks the same signal from a different angle by scanning and serving images itself. Google's help page states that "senders can't use image loading to get information about your computer or location" and that "senders can't use the image to set or read cookies in your browser." It also concedes the limit of that protection in one line: "sometimes, senders may know whether you've opened an email that has an image."

Read the consequence carefully before you report on a campaign. Open rate is now an upper bound made mostly of automated fetches, and the counts inflate for the segments with the most Apple Mail users, which means comparing open rates between segments compares mail clients. Clicks still require a human, which is why click-through rate, and revenue attributed to the click, survive the change. The same reasoning applies to server-side tracking on the web: the closer the measurement sits to an action a person had to take, the less it depends on a rendering quirk.

Is a tracking pixel the same as a web beacon or a spy pixel?

Yes, those are three names for one mechanism with different connotations. "Web beacon" is the older neutral term, "tracking pixel" is the vendor term, and "spy pixel" is the term that took hold once journalists started counting how many marketing emails carry one. The HTML is identical in all three cases.

Spotting one takes a network panel and no tooling. Filter requests by image type, sort by size, and look for responses of a few hundred bytes or fewer whose URL carries an identifier and an event name. In an email, viewing the raw message and searching the HTML for img tags with a width or height of 1 finds the same thing before the client renders it.

What varies is disclosure and jurisdiction, not technology. A pixel that reports a purchase to an advertising platform, one that measures whether a newsletter was delivered, and one that fingerprints a reader across sites all look the same in the markup and are treated very differently by privacy law. The element tells you nothing about the intent; the destination domain and the parameters in the URL do.

Frequently asked questions

Why is a tracking pixel 1x1?

Because it has to be requested without being seen. One pixel is the smallest valid image, and it is usually hidden with display:none or matched to the background so nothing in the layout shifts.

Can a tracking pixel read my email address?

Only the one already encoded in its URL. Senders add a recipient identifier to the query string before sending, so the pixel returns the identity they already had, not one it discovered.

Do ad blockers stop tracking pixels?

Blocklists match the request URL, so a pixel pointing at a known advertising domain is blocked like any other request from that domain. A pixel served from the site's own domain is harder for a list to classify.

Does Apple Mail Privacy Protection block pixels?

It does not block the fetch. Apple downloads remote content in the background by default whether or not the message is engaged with, and routes it through two relays, so the request still arrives but the open, the timing and the IP address stop meaning what the sender assumes.

Can a pixel set a cookie?

Its response can send Set-Cookie for its own domain, which is a third-party cookie when the pixel sits on someone else's page. Whether the browser stores and later returns it depends on that browser's third-party cookie rules.

Is a tracking pixel personal data under GDPR?

The image is not, the data it collects can be. An IP address plus a recipient identifier in a query string identifies a person, which is the test that matters rather than the file format.

Does a tracking pixel work if JavaScript is disabled?

A pixel needs no JavaScript to work. Meta ships a <noscript> fallback built from a bare <img> tag for exactly this case, since loading any image forces the browser to make the request regardless of script support. That is the whole mechanism: request the URL, log the hit.

Why do tracking pixels return a blank image or a 204 response?

The sender never reads what comes back. All that matters is that the request reached the server and got logged, so endpoints reply with a transparent 1x1 GIF or an empty 204 No Content instead of anything meaningful. The display:none styling on the element follows the same logic, since nothing about the image itself is meant to be seen.

Can a tracking pixel tell how many times someone opened an email?

Not reliably. Apple's Protect Mail Activity fires on every background download regardless of engagement, so repeat opens are not distinguishable from the first fetch. Gmail caches the proxied image, so a second open can go unrecorded entirely.

Does a tracking pixel know what page someone is on?

Usually not beyond the domain. Browsers default to strict-origin-when-cross-origin, which sends the full path only on same-origin requests and trims cross-origin requests down to the origin. A third-party pixel therefore learns the domain that embedded it, not the page itself, unless the page owner wrote the path into the query string.