How a tracking pixel actually works
The image itself carries no information. What does the work is the request: your browser or email client asks the server for that 1x1 image, and the URL it asks for is stuffed with parameters, a recipient ID, a campaign ID, a timestamp. The server reads those parameters, logs them, and only then hands back the image, usually a single transparent GIF so small it renders in under a millisecond. If the request never fires, nothing is logged. That single fact explains almost every limitation of pixel tracking that follows.
This is why a tracking pixel needs a live server on the other end. It is not a passive tag sitting in your HTML. It works as an active round trip, a request goes out, the server writes a log entry, and a response comes back. Compare that to a UTM parameter, which just rides along on a link click and gets read by whatever analytics tool receives the page load. A pixel fires on its own, independent of any click.
Tracking pixel vs cookie tracking
People treat these as competing methods. They are not, they solve different problems and are usually used together. A pixel is the delivery mechanism, a single HTTP request that reports one event happened. A cookie is the memory mechanism, a small file that persists an identifier across visits so a server can recognize the same browser twice. A pixel without a cookie tells you an event happened. A pixel that also drops or reads a cookie tells you that event happened, and it is the fifth time this browser has done something being tracked.
| Mechanism | What it captures | Persists across visits | Typical use |
|---|---|---|---|
| Tracking pixel | A single fire event (page load, email open, ad view) | No, on its own | Conversion logging, open tracking |
| Cookie | An identifier tied to a browser or device | Yes, until it expires or is cleared | Sessions, attribution, first touch vs last touch |
| UTM parameter | Where a click came from, in the URL itself | No, but often written into a cookie on landing | Campaign source and medium reporting |
Most ad platforms combine all three: a pixel fires the event, a cookie (or a device ID, where cookies are blocked) carries identity, and the UTM parameters on the link that started the visit tell the pixel which campaign to credit. UTMs and pixels are not substitutes, they are stages of the same pipeline.
The main types of tracking pixels
Not all pixels do the same job. Four show up constantly.
| Pixel type | Where it lives | What it logs |
|---|---|---|
| Email open pixel | Embedded in the HTML of a marketing or transactional email | That the email client requested images, treated as an open |
| Ad conversion pixel | Placed on a checkout or thank you page (Meta Pixel, Google Ads tag) | That a visitor who came from an ad completed a purchase or signup |
| Retargeting pixel | Placed site wide on a merchant's own site | That a specific visitor browsed a product, so ads can follow them |
| Web analytics beacon | Fired on page load by an analytics script | Page views, on older or simpler analytics setups |
Tracking pixel in email, and why the numbers lie
Email open tracking is the most common place people encounter this term, and it is also where it works worst. An open pixel only fires if the email client actually loads remote images. Since 2021, Apple Mail's Mail Privacy Protection has pre-loaded every image in every email that passes through it, for every user who has the setting on, whether or not the person ever opens the message. That means an open can be recorded before a human ever looks at the inbox. Gmail's image proxying does something similar in a milder form. The practical result: open rate, as a metric, has been unreliable for years and should be read as a rough signal, not a count of people who read your email.
Click tracking inside that same email does not have this problem, because a click requires an actual human to tap a link. That is one reason serious campaign reporting leans on click data instead of open data wherever the two disagree.
Where a pixel cannot help you
A pixel only reports on the page or email where it is placed. It cannot tell you what a visitor does after they leave that page, and it cannot follow them onto a platform that blocks third party requests, which is most of them now. Ad blockers, iOS's App Tracking Transparency, and Safari's Intelligent Tracking Prevention all specifically target pixel and cookie based tracking, which is a large part of why first party click data, logged on infrastructure you control rather than a remote request a browser may or may not honor, has become the more dependable option. Raydar's link analytics work this way: every click on a bio link is logged server side with UTM, referrer, and first touch and last touch cookie data captured at the point the link is actually clicked, not inferred from a request that a privacy setting might silently swallow. That does not replace ad platform pixels, it just answers the one question a pixel cannot when it fails: which link, in which post, actually got the click.
A quick way to tell what you're looking at
If a tool asks you to paste a snippet into your site's head and calls it a pixel, it is asking for a persistent tag that fires on every page load, closer to an analytics script than a single-use image. If it gives you a one-time tracking link or a UTM-tagged URL instead, you are looking at click tracking, which reports differently and, on platforms that restrict third party pixels, more reliably. Knowing which one you are being asked to install is worth thirty seconds before you paste anything into your site.