Cookies vs Tracking Pixels

What a cookie is

A cookie is a small piece of data the browser stores per-domain. When you visit example.com, the server may send a Set-Cookie header with a value like session_id=abc123. The browser stores it. On every subsequent request to example.com, the browser includes Cookie: session_id=abc123. The server uses this to recognize you across page loads.

Cookies have attributes: an expiration date (or session-only), a path scope, a Secure flag (HTTPS-only), an HttpOnly flag (not readable by JavaScript), and a SameSite attribute that controls when they're sent across sites.

First-party vs third-party

Cross-site tracking historically depended on third-party cookies. Browser vendors have spent the last few years restricting them — Safari blocks them by default, Firefox blocks known trackers, Chrome has been rolling out restrictions. Tracking did not stop; it shifted to other mechanisms, including pixels.

What a tracking pixel is

A 1x1 transparent image (or any other resource — a CSS file, a JavaScript file, even an empty HTML iframe) loaded from a third-party domain. The page includes:

<img src="https://tracker.example/p?id=user-abc&event=pageview" width="1" height="1" />

The browser fetches the image. The request to tracker.example carries:

• Your IP address.
• Your user-agent string.
• The Referer header (the page URL where the pixel is embedded).
• Any cookies you have for tracker.example (if third-party cookies are still allowed).
• Query parameters in the pixel URL itself (often a user ID set by the publisher).

The image content is irrelevant. The request is the data point.

Why pixels survive cookie blocking

Even with all third-party cookies blocked, a pixel request still goes out. The publisher embeds the pixel with a unique identifier baked into the URL. That identifier is generated server-side per visit. The tracker sees:

1. Which page embedded the pixel (Referer).
2. The publisher-assigned user ID (in the URL).
3. The user's IP and user agent.

By correlating publisher-assigned IDs across publishers — or by matching IP plus user-agent plus other signals — the tracker can stitch a cross-site profile without ever using a cookie.

The third-party loading model

Tracking pixels piggyback on the standard browser model: any resource loaded by a page can be from a different domain, and the browser sends a request to that domain to fetch it. Ad networks, analytics, embedded social-media widgets, CDN-hosted libraries — all of them are third-party loads. Every one is an opportunity to log.

The mitigations:

• Tracker blocking — extensions and browsers maintain blocklists of known tracker domains and refuse to load resources from them. Effective but a maintenance arms race.
• Container isolation — Firefox containers, Safari's intelligent tracking prevention. Even if a tracker loads, its cookies are isolated per-site, so cross-site correlation fails.
• Referrer policy — sites can set Referrer-Policy: no-referrer to prevent the browser from sending the Referer header on outgoing requests, removing one signal.
• Storage Access API — third-party embeds must explicitly request user consent before accessing their cross-site state.

Other tracking storage mechanisms

Beyond cookies and pixels, browsers expose several other state-holding APIs that have been abused for tracking:

Comprehensive privacy tools (e.g., Tor Browser, Firefox Private Mode, Brave) clear all of these together. Clearing only cookies is no longer sufficient.

Server-side tracking and CNAME cloaking

The most recent evolution of pixel tracking sidesteps third-party blocking entirely. The publisher sets up a CNAME record pointing a subdomain of their own site (e.g., analytics.publisher.com) to the tracker's server. The tracker then loads as a "first-party" resource from the browser's perspective. Third-party cookie blocking and many tracker blocklists don't apply. Detecting this requires DNS-aware mitigation (some browsers and DNS-based blocklists handle it; many do not).

What protects against pixels

The defenses in rough order of impact:

1. A browser with strong default tracker blocking (Firefox, Brave, Safari) plus a maintained blocklist.
2. DNS-based blocking (Pi-hole, NextDNS, AdGuard) that prevents tracker domains from resolving in the first place.
3. Container-based isolation that limits cookie/storage state from carrying across sites.
4. JavaScript-disabling on untrusted sites (drastic but effective).
5. A network-level VPN to obscure your IP, paired with fingerprint-resistant browser settings to obscure other signals.

Frequently Asked Questions

What is a tracking pixel?

A tracking pixel is a tiny image (often 1x1 transparent) loaded from a third-party server. The act of loading the image sends an HTTP request to that server, including the page URL (in the Referer header), the user's IP, the user agent, and any third-party cookies the user has for that server. The image itself is irrelevant — the request is the data collection.

What is the difference between a first-party and a third-party cookie?

A first-party cookie is set by the site you are visiting (the domain in the address bar). A third-party cookie is set by a different domain whose content is embedded in the page — an ad network, an analytics provider, an embedded widget. Third-party cookies are the mechanism behind cross-site tracking because the same third party can set its cookie on every site that embeds it, building a profile of which sites you visit.

Why do tracking pixels work even when cookies are blocked?

Cookies are one identifier; pixels can still send information that doesn't rely on a cookie. The HTTP request to load a pixel always includes the user's IP, user agent, and the Referer header showing which page embedded the pixel. Combined with browser fingerprinting and persistent identifiers carried in the URL itself, pixels can track users without ever setting or reading a cookie.

What is the Storage Access API?

A browser API designed to give embedded third parties (e.g., a single sign-on widget) explicit opt-in access to their own cookies when loaded as a third party. It is the replacement for unrestricted third-party cookie access — the browser blocks third-party cookies by default and requires the embedded service to request access, with the user prompted to approve.

Are first-party cookies a privacy concern?

Less so than third-party cookies. A first-party cookie is set by the site you chose to visit and is sent only back to that site. It can track you across that one site but not across the web. The privacy concern with first-party cookies is mostly the long retention of identifiers — if a site sets a cookie that persists for a year, your identity on that site is stable across that time.