A tracking pixel is a tiny image or small snippet of code embedded in a website, ad, or email that triggers a request to a tracking server the moment it loads, letting that server log details like your IP address, device type, and timestamp. It records that content loaded and captures metadata about who loaded it. This simple mechanism powers everything from email open tracking to ad retargeting and cross-site analytics.
TL;DR:
- Tracking pixels log IP addresses, device and browser details, referrers, timestamps, and actions; identifiers can link events to people and build profiles across sites.
- The FTC says pixels that send health or financial details to third parties without affirmative express consent can be unfair or deceptive.
- Apple Mail Privacy Protection prefetches email images and hides IP addresses, making opens unreliable; marketers should prioritize clicks, conversions, and verified server events.
- Image pixels are easiest to block because email clients can refuse remote images, while JavaScript captures clicks and server tracking resists browser controls.
- Some research crawls found invisible pixels on over 90% of domains, and filter lists or privacy extensions still miss some tracking requests.
Table of Contents
- Tracking pixels at a glance
- What exactly is a tracking pixel?
- How a tracking pixel actually works, step by step
- What data do tracking pixels actually collect?
- Image pixels, JavaScript pixels, and server-side tracking compared
- Where you actually encounter tracking pixels
- How pixels relate to cookies and browser fingerprinting
- What regulators and Apple have changed about pixel tracking
- How to spot and reduce pixel tracking
- What responsible pixel use looks like for marketers
- Why this technical detail actually matters to you
- A quick way to check a site before you trust it with your data
- FAQ
- Sources
Tracking pixels at a glance
Pixels are easy to overlook because they're designed to be invisible, but they sit behind an enormous share of the web's data collection. A single pixel is often one by one pixel in size or a few lines of JavaScript, yet it can trigger a full server-side log entry every time it loads.
Here's what matters most before we get into the mechanics:
- A tracking pixel creates a server-side request that carries metadata such as IP address, device, and timestamp, according to the FTC's technical description.
- Pixels and cookies are different technologies but frequently work together to link your activity across sites.
- Regulators and platform vendors, including Apple, have changed how reliable certain pixel-based signals are, particularly for email.
- Because pixels are so small, they rarely slow down a page, which is part of why they're so widespread and so easy to miss.
What exactly is a tracking pixel?
At its core, a tracking pixel is a resource, usually an image, sometimes a script, embedded into a webpage, advertisement, or email that your browser or email client automatically requests when the content loads. The FTC describes it as an invisible graphic element, typically one by one pixels in size, or a small piece of JavaScript embedded into websites, ads, or emails. That request, not the image itself, is the point.
There are a few common transports. The classic version is a transparent image, often a GIF, sized at one pixel by one pixel so it's invisible to the human eye. A more modern version uses a small JavaScript snippet that can capture richer behavioral signals, like scroll depth or button clicks, rather than just "this loaded." A third approach, server-side tracking, skips the client-visible request entirely and logs events directly from a company's own servers.
Regardless of the transport, a few components always show up together. There's the embedded tag itself, sitting in the page's HTML or the email's code. There's a tracking URL, pointing to a server operated by an advertiser, analytics provider, or email platform. There's the tracking server, which receives the request and writes it to a log. And often there are identifiers and parameters tacked onto the URL, things like a user ID, campaign code, or session token, that let the server tie this particular request to a specific person or visit.
The size of the pixel has nothing to do with its reach. A one by one pixel image adds no meaningful load time to a page, which is exactly why it's become the default tool for passive tracking: it does its job without you noticing it's there. The FTC notes this directly, pointing out that because of their minimal size, pixels do not impact page load performance, which is precisely what makes them so easy to deploy at scale and so hard for the average reader to spot.
How a tracking pixel actually works, step by step
The lifecycle of a tracking pixel is short, but each step matters for understanding what gets collected and where it goes.
- Embedding: A developer or marketing platform inserts a pixel into a page, ad, or email, typically as an HTML image tag pointing to a tracking URL, or as a JavaScript snippet that fires on page load.
- Request: When you open the page or email, your browser or email client automatically requests that resource from the tracking server, the same way it would request any other image.
- Logging: The server receives the request and records metadata, commonly your IP address, browser or device type (user agent), the referring page, and a timestamp.
- Identifier attachment: If the pixel URL includes a unique identifier or query parameter, the server can tie this specific event to a known user ID, campaign, or session, rather than just an anonymous visit.
- Stitching: Many companies then join this event with other data they hold, through cookie syncing, hashed identifiers, or server-side matching, building a fuller profile of your activity across properties.
This process is quietly massive in scale. Invisible pixels remain deployed on over 90% of domains in some measurement crawls, according to academic research presented alongside FTC materials, which gives a sense of how routine this kind of collection has become across the web rather than being limited to a handful of aggressive advertisers.
What gets logged in that initial request is more detailed than most people expect. Beyond the basics, IP address, user agent, referrer, and timestamp, the request can carry simple action signals: that a page was viewed, an email was opened, or a button was clicked. None of this requires you to type anything or click a consent banner. It happens the instant the resource loads.
Where it gets more involved is in what happens after that log entry is written. Cookie syncing lets two companies match their separate identifiers for the same browser, so a pixel fired by an ad network can be linked to a cookie set by a publisher. Hashed identifiers, often an email address run through a one-way hashing function, let companies match users across datasets without transmitting the raw email address itself, though hashing isn't as airtight a privacy measure as it sounds. Server-side stitching takes this further, joining events logged across multiple touchpoints (a website visit, an email open, an ad click) into a single profile tied to one person.
On the technical side, developers increasingly favor newer browser APIs over the old image-tag approach. The fetch API and navigator.sendBeacon both let a page send tracking data asynchronously, without blocking the page from loading or requiring a visible image element at all. These methods can carry richer payloads, including form data or interaction events, which is part of why modern pixel implementations collect more than the simple "did this load" signal that defined the earliest web beacons.
What data do tracking pixels actually collect?
The data a pixel captures depends on how it's implemented, but a handful of fields show up in nearly every case: your IP address, device and browser information (sometimes detailed enough to function as a fingerprint), the referring page or URL you came from, a timestamp, and a record of the specific action that triggered the pixel, like a page view, an email open, or a completed purchase.
Most of this feels low-stakes in isolation. An IP address and a timestamp don't tell anyone much on their own. The concern the FTC has raised is about context: pixels deployed on health, finance, or shopping sites can transmit sensitive details, what condition you searched for, what medication page you viewed, what financial product you were comparing, to third parties you never knowingly interacted with. Recent FTC enforcement actions against companies including BetterHelp, GoodRx, and Epic Games illustrate exactly this pattern: tracking technologies moving confidential information to advertising or analytics partners without clear disclosure.
A related complication is that hashing doesn't fully solve the privacy problem it's often marketed as solving. Hashed identifiers, like an email address converted into a string of characters, can still be matched across datasets or, in some cases, reversed entirely when combined with other available information. The FTC specifically flags this as a gap: companies may believe hashing anonymizes data when, in practice, it often just obscures it from casual view while leaving it linkable.
Image pixels, JavaScript pixels, and server-side tracking compared
The three main implementations of pixel tracking differ in what they can capture, how easily you can block them, and how much technical effort they require to deploy.
- Image pixels are the simplest and most common form, especially in email. A one by one transparent image loads when you open the message, confirming the email was viewed. Because they rely on your email client fetching a remote image, they're also the easiest to block: many email clients simply don't load remote images by default.
- JavaScript pixels collect richer behavioral data, scroll depth, time on page, specific clicks or form interactions, but require more setup and are more visible to anyone inspecting a page's source or network traffic.
- Server-side tracking moves the tracking logic off the browser entirely, logging events directly from a company's backend. This makes it far more resistant to ad blockers and browser privacy settings, but it also means the data collection happens somewhere you can't easily see or audit, which raises its own transparency questions.
Each approach trades visibility for resilience. Image pixels are blunt but easy to spot and block. JavaScript pixels are more capable but easier to inspect. Server-side tracking is the hardest to block and, correspondingly, the hardest for an everyday reader to even detect.
Where you actually encounter tracking pixels
Three everyday scenarios cover most of how pixels show up in your digital life, and recognizing them makes the abstract mechanics feel a lot more concrete.
Email open tracking is the most familiar example. A marketing email includes a hidden image pixel; when you open the email and your client loads remote images, that request tells the sender you opened it, often down to the time and your approximate location based on IP. This is also the metric most disrupted by recent platform changes: Apple's Mail Privacy Protection now pre-fetches images for many users regardless of whether they actually open the email, which means open-rate data from Apple Mail users is no longer a reliable signal of genuine engagement.
Ad retargeting relies on pixels placed across a network of websites. When you visit a product page, a pixel fires and adds you to an audience segment; later, when you visit an unrelated site that shows ads from the same network, you see an ad for that exact product. This is the mechanism behind the uncanny feeling of being followed around the internet by something you looked at once.
Conversion tracking uses a pixel placed on a confirmation or purchase page. When it fires, it tells the advertising platform that a specific campaign or ad click led to a sale, letting marketers attribute revenue back to the spend that generated it. This is less visible to you as a browsing experience but is one of the most common reasons pixels exist on commercial sites in the first place.
How pixels relate to cookies and browser fingerprinting
Pixels, cookies, and fingerprinting are often lumped together as "tracking," but they work differently and that difference matters for understanding why pixels have stuck around even as cookie restrictions tighten.
A cookie is a small file stored locally on your device, readable by the site that set it (and, for third-party cookies, by other sites too). A pixel, by contrast, doesn't store anything on your device at all. It simply triggers a request, and the resulting log lives entirely on the tracking server. In practice, the two are frequently used together: a cookie identifies your browser, and a pixel fires an event that gets tagged with that cookie's ID, linking a specific action to a specific identity.
Fingerprinting takes a different approach entirely, gathering a combination of client-side signals (screen resolution, installed fonts, browser version, and dozens of other small details) to build a unique profile of your device without needing to store anything locally. Pixels don't do this kind of broad signal collection on their own, but the data they log, like IP address and user agent, can feed into a fingerprinting system as additional inputs.
As browsers increasingly restrict third-party cookies, companies have leaned harder on server-side techniques, like cookie syncing and server-side stitching, to preserve the cross-site linkage that cookies used to provide. Pixels remain a central piece of that shift precisely because the event-logging they do happens on the server, outside the reach of most browser-level privacy controls.
What regulators and Apple have changed about pixel tracking
The legal and platform landscape around pixels has shifted meaningfully, and it's worth understanding both halves: what regulators are scrutinizing and what Apple has technically changed.
On the regulatory side, the FTC has been explicit that tracking pixels can collect sensitive personal information, health conditions, financial details, shopping habits, often without the person involved having any real awareness it's happening. The agency's position is that using pixels to collect, analyze, or transfer this kind of information from a confidential context without affirmative express consent can qualify as an unfair or deceptive practice under the FTC Act. That's not a hypothetical: recent enforcement actions have targeted exactly this pattern, undisclosed data flows from sensitive contexts to third-party advertising and analytics platforms.
Using tracking technologies to amass, analyze, infer, or transfer information collected in a Confidential Context without affirmative express consent can be unfair or deceptive, and obtaining consent through interfaces that subvert user autonomy does not constitute valid consent.
That framing comes from FTC staff guidance on confidential contexts, and it draws a clear line: a consent checkbox buried in a dark pattern doesn't satisfy the standard the agency expects.
On the platform side, Apple's Mail Privacy Protection changed the mechanics of email tracking specifically. Rather than loading remote content, including pixels, directly from the sender's server, Apple routes those requests through its own proxy servers and pre-fetches the images regardless of whether you actually open the email or not. The practical effect is twofold: your real IP address is hidden from the sender, and open-tracking pixels fire whether or not a genuine open occurred, which makes open-rate metrics unreliable for a large share of the email audience. Apple's own support documentation confirms this is by design, intended to prevent senders from knowing when a message was actually opened.
Together, these developments point in the same direction: less tolerance for silent, undisclosed collection, and less confidence that a pixel firing tells you what you think it tells you. If you work with any form of digital marketing, both of these facts should shape how you design and interpret tracking.
How to spot and reduce pixel tracking
You don't need to be a developer to get a sense of how much pixel tracking is happening around you, though it's worth being realistic about the limits of what blocking tools can actually catch.
- Open your browser's developer tools and check the network tab; third-party image or script requests, often with long query strings containing identifiers, are a strong sign of pixel tracking in action.
- Adjust your email client's settings to block remote images by default, which stops many basic image-based email pixels from ever firing.
- Keep in mind that Apple Mail Privacy Protection now pre-fetches images automatically, so even with remote images "blocked" from your perspective, a pixel may still register a request on Apple's relay servers.
- Install a reputable privacy extension or rely on browser-level tracker blocking, understanding that these tools reduce exposure but don't eliminate it entirely.
That last point deserves a closer look. Research into invisible pixels found that filter lists and privacy extensions miss a significant share of tracking requests, meaning blockers are a genuinely useful layer of defense, not a complete solution. Trackers evolve their domains and techniques faster than filter lists can always keep up.
Pro Tip: When checking a page's network requests, look for small image or script calls going to a domain you don't recognize, especially ones with query strings full of numbers and letters; that's almost always a tracking pixel at work.
If you want a more structured way to work through a site's trackers and data practices, a website vetting checklist can help you build the habit of checking before you click or compare the signal a tool like this gives against a page's own privacy claims. For a step further, reviewing your browser safety settings can meaningfully cut down how many trackers, pixels included, ever get a chance to fire in the first place. For a related angle on device-level tracking, the way connected devices like home security cameras handle data and remote access raises similar transparency questions once you're outside the browser entirely.
What responsible pixel use looks like for marketers
If you're the one deploying pixels rather than the one being tracked, the regulatory and platform shifts above translate into a fairly clear set of practices worth building into your workflow.
Start with consent that actually means something: obtain affirmative, documented consent before activating marketing pixels where that's required, and make sure the pixel doesn't fire until consent is actually given, not just requested. A banner that technically asks permission but loads the tracker regardless doesn't meet the standard regulators have described.
Collect only what you need. It's tempting to let a JavaScript pixel capture every field a visitor types into a form, but doing so without explicit, specific permission is exactly the kind of undisclosed collection that draws scrutiny. If you don't have a clear use for a data point, don't capture it by default.
Given how Apple Mail Privacy Protection has undermined open-rate reliability, it's worth shifting measurement weight toward clicks, conversions, and server-side verified events, metrics that aren't distorted by automatic image pre-fetching. Open rate can still be one input, but treating it as a primary success metric for email campaigns no longer reflects how a large share of recipients actually interact with your messages.
Finally, keep an actual inventory of every tracker running on your properties, and reflect that inventory honestly in your privacy notices. A privacy policy that doesn't mention the pixels you're running isn't just a compliance risk, it's the specific gap regulators have pointed to.
Why this technical detail actually matters to you
Tracking pixels sit at an uncomfortable intersection: they're genuinely useful for the businesses that rely on them, letting them measure what's working without guessing, and they're genuinely opaque to the people being measured. Neither side of that is going away soon, which is exactly why understanding the mechanics matters more than picking a side.
What strikes me most, working through how pixels, cookie syncing, and server-side stitching interact, is how little of this requires any action from you at all. You don't click anything. You don't agree to anything beyond opening an email or loading a page. That's not necessarily sinister, plenty of measurement is genuinely benign, but it does mean the burden of figuring out what's happening falls almost entirely on you if you want to know.
That's really the practical takeaway: you don't need to understand every technical layer to make better decisions, you just need a few reliable habits, checking network requests occasionally, adjusting your email and browser settings, and taking a second look at unfamiliar sites before you hand over any information. Small, consistent checks do more for your privacy than any single tool ever will.
— Nick
A quick way to check a site before you trust it with your data
Understanding how pixels work is useful, but it doesn't tell you whether a specific site deploying them is otherwise trustworthy, and that's a separate question we built our free website trust checker to answer. We analyze a range of security, ownership, reputation, infrastructure, transparency, and compliance signals, pulling from sources like Google Safe Browsing, VirusTotal, and WHOIS data, and turn that into a straightforward trust score, along with a categorized verdict: dangerous, suspicious, caution, mostly safe, or trusted.
It's a useful second step right after you notice something off, an unfamiliar tracker domain, a pixel pointed at a server you don't recognize, or a checkout page that feels less polished than it should. Paste the URL in, and we show you a full breakdown instead of a vague gut feeling. If you run a site yourself, our trust badge gives visitors a visible signal that you've been independently checked. Our verdicts aren't for sale: we don't accept payment for a better score. Try our free website trust checker before you enter any personal or payment information on a site you're not sure about.
FAQ
Are tracking pixels illegal?
Tracking pixels themselves are not illegal, but the FTC has stated that using them to collect or share sensitive information from confidential contexts without affirmative express consent can be treated as an unfair or deceptive practice. The legality depends heavily on what data is collected, where, and whether people were clearly informed.
How can I tell if an email has a tracking pixel?
You can check an email's source code or headers for a small, often one by one, image tag pointing to an unfamiliar domain, which is the classic sign of an open-tracking pixel. Blocking remote images in your email client prevents many of these from firing, though Apple Mail Privacy Protection now pre-fetches images automatically, which changes what an open actually signals.
Can you give me an example of a tracking pixel?
A common example is a one by one transparent image embedded in a marketing email; when you open the email and your client loads remote images, your device requests that image from the sender's tracking server, logging your IP address, device type, and the exact time you opened it. The same basic mechanism appears on websites for analytics and on ad networks for retargeting.
Do tracking pixels still work?
Yes, pixels remain widely deployed, showing up on over 90% of domains in some research crawls, but their reliability has shifted. Email open-tracking pixels in particular are less accurate following Apple's Mail Privacy Protection rollout, which pre-fetches images regardless of genuine opens.
Sources
- Lurking Beneath the Surface: Hidden Impacts of Pixel Tracking | Federal Trade Commission
- Legal - Mail Privacy Protection & Privacy- Apple