Tracking pixels — what they are and why consent still applies
'We don't use cookies, just pixels' is one of the most common compliance misconceptions. A plain-language guide to what pixels do and why they're in scope.
Some marketers and developers believe that tracking pixels bypass consent requirements because “they’re not cookies.” This is wrong. Unlike strictly necessary cookies, pixels are not exempt. Here’s why.
What a tracking pixel actually is
A tracking pixel is a 1×1 transparent image, usually a GIF or PNG, loaded from a third-party server. The image tag looks like this:
<img src="https://tracker.example.com/pixel.gif?id=12345" width="1" height="1" alt="" />When the browser loads this “image,” the third-party server receives:
- The visitor’s IP address
- The User-Agent string (browser, OS, device)
- The Referer header (which page they’re on)
- Any query parameters the pixel was configured with
- A cookie, if one was previously set by that domain
That’s more data than most cookies collect.
Why consent is required
The ePrivacy Directive doesn’t say “you need consent for cookies.” It says:
“storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user”
A tracking pixel does both:
- It accesses information already stored (reads any existing cookie from that domain)
- It stores new information (sets a fresh cookie via the
Set-Cookieresponse header)
Both actions require consent under EU law. The mechanism (pixel, cookie, script, localStorage) is irrelevant. The law regulates the action, not the technology.
Common arguments (and why they fail)
“It’s a first-party pixel, not third-party.” First-party vs third-party is a technical distinction, not a legal one. If the pixel sets or reads a cookie, consent is required regardless of domain.
“It’s anonymous, no PII.” IP addresses are personal data under GDPR. The pixel sends the IP address. It’s not anonymous.
“It’s necessary for analytics.” Analytics is not strictly necessary for the user to receive the service they requested. You may want analytics. The user doesn’t need it.
What to do instead
- Block pixels before consent. Your CMP should prevent pixel tags from loading until the user opts in.
- Use cookieless analytics where possible: server-side analytics that don’t touch the browser.
- Declare pixels in your cookie policy. Transparency is the minimum.
For Google-specific signals, wire your CMP into Google Consent Mode so denied state actually reaches Google. For programmatic ads, the IAB TCF TC string carries the same choices to every vendor in the bid chain.
Zest blocks tracking pixels by intercepting <img> elements that match known tracker patterns. It also patches fetch, XHR, and sendBeacon so tracking requests can’t bypass the consent check.
How Zest handles it
Zest blocks pixels at the network level before consent fires, then releases them in the chosen categories the moment the user opts in. Interception happens on <img>, fetch, XHR, and sendBeacon in one pass, so a Meta, TikTok, or Pinterest pixel never makes a request until the user has actually chosen its category. No opt-in, no fire.