green gradient background, "The Future of Application Security Is Already Here." and a read the report button.

Category: Tracking Technologies

Tracking Pixels

Also known as: Pixel Tracking, Tracking Pixel, 1x1 Pixel, Pixel Tag

Simply put

A tracking pixel is a tiny, often invisible image (typically 1×1 pixels in size) or snippet of code embedded in a website, email, or advertisement. When the content loads, the user's browser requests the pixel from a server, which allows the operator to record information about the user's behavior, such as whether an email was opened or a page was visited. Tracking pixels serve a purpose similar to browser cookies, but they can operate even where cookies are not used.

Formal definition

A tracking pixel is an HTML or JavaScript-based tracking mechanism, commonly implemented as a 1×1 transparent image or an equivalent code snippet, embedded in web pages, emails, or ad creatives. When the client renders the content, the browser issues an HTTP request to the hosting server to retrieve the pixel; this request can transmit metadata (such as IP address, user agent, timestamps, and referrer information) and can be paired with cookies or other identifiers to attribute user behavior and conversions. Although a tracking pixel is not literally a cookie, in most EU jurisdictions the placing of, or gaining access to, information on a user's device via such technologies generally falls within the scope of the ePrivacy Directive's national implementations in the same way as cookies, and any resulting processing of personal data is governed by the GDPR. Where a pixel is used for non-essential purposes such as analytics or advertising, prior consent is typically required under EU law, whereas some other regimes (for example certain US state privacy laws) may rely on an opt-out model instead. The specific consent obligations depend on the pixel's purpose, the data processed, and the applicable jurisdiction, which are outside the scope of this core definition.

Why it matters

Tracking pixels matter because they allow website operators, advertisers, and email senders to observe user behavior, such as whether an email was opened or a page was visited, often without the user's awareness, since the pixel itself is typically invisible. From a compliance perspective, the fact that a pixel is not literally a cookie does not place it outside the rules. In most EU jurisdictions, the placing of, or gaining access to, information on a user's device via technologies like tracking pixels generally falls within the scope of the ePrivacy Directive's national implementations in much the same way as cookies, and any resulting processing of personal data is governed by the GDPR. Treating pixels as exempt because they are not cookies is a common and risky misconception.

Who it's relevant to

Privacy officers and data protection professionals

Pixels should be included in cookie and tracking-technology audits alongside cookies, local storage, and SDKs. Because pixels can transmit metadata such as IP address and user agent, they may involve processing of personal data under the GDPR, and their placement on a user's device may engage ePrivacy rules in most EU jurisdictions. Whether prior consent is required depends on the pixel's purpose, the data processed, and the applicable jurisdiction.

Marketing and compliance teams

Marketing measurement often relies on pixels for conversion attribution and campaign tracking, but where a pixel serves non-essential purposes such as analytics or advertising, prior consent is typically required under EU law. Teams should verify how each pixel is governed by their consent mechanism rather than assuming it falls outside consent obligations because it is not a cookie.

Web developers and email teams

Developers who embed pixels in web pages, ad creatives, or email templates should ensure that pixels which require consent do not fire before that consent is obtained, where the applicable regime uses an opt-in model. Documenting where and how each pixel is deployed supports downstream compliance review, though the tooling that gates pixel loading supports compliance rather than guaranteeing it.

Legal counsel

Counsel advising on tracking practices should note that obligations differ by jurisdiction. Some EU frameworks generally require prior consent for non-essential pixels, whereas certain US state privacy laws may rely on an opt-out model instead. The specific consent obligations depend on facts outside a core technical definition, including purpose, data processed, and geographic scope.

Inside Tracking Pixels

Tracking pixel (web beacon)

A small, often invisible image or snippet of code embedded in a web page or email that loads from a remote server, allowing that server to register when the content is viewed. The pixel request itself can transmit information such as IP address, device and browser characteristics, and timing data.

Association with cookies and identifiers

Tracking pixels are frequently used in conjunction with cookies or other identifiers to link a user's activity across pages or sessions. The pixel triggers the setting or reading of identifiers, so its operation can involve both the placing of and access to information on a device and the subsequent processing of personal data.

Legal treatment analogous to cookies

Although a pixel is not literally a cookie, in most EU jurisdictions the placing of or access to information on a user's device via a pixel falls within the same ePrivacy rules that apply to cookies. Any personal data processed as a result is separately governed by the GDPR.

Common use cases

Pixels are typically used for analytics, conversion measurement, advertising and retargeting, and email open tracking. The applicable consent obligations generally depend on the purpose rather than the technology, so non-essential purposes typically require prior consent in the EU.

Third-party involvement

Many pixels are provided by third parties (for example advertising or analytics vendors), which means the pixel request may disclose data to those parties and raises questions about controller and processor roles and the transparency owed to users.

Common questions

Answers to the questions practitioners most commonly ask about Tracking Pixels.

Are tracking pixels exempt from consent because they are not technically cookies?

No. Although a tracking pixel is not a cookie in the literal sense, the ePrivacy rules in the EU and UK generally apply to the storing of, or gaining access to, information on a user's device regardless of the specific technology used. Where a pixel is used to place or read information on a device, or to identify a user, it typically falls within the same consent requirements as cookies. The relevant question is what the pixel does, not whether it meets a narrow definition of a cookie.

Does obtaining cookie consent automatically cover the personal data collected through tracking pixels?

Not necessarily. In the EU, two distinct legal regimes may apply: the ePrivacy rules govern the placing of and access to information on the device, while the GDPR governs any subsequent processing of personal data that the pixel enables. Consent obtained for placing the technology does not automatically satisfy every GDPR obligation for the downstream processing, and a lawful basis, transparency, and other GDPR requirements may still need to be addressed separately. Requirements also differ outside the EU, so scope should be assessed per jurisdiction.

When should a tracking pixel fire relative to obtaining consent?

In most EU and UK contexts, where consent is required, a tracking pixel used for analytics, advertising, or similar non-essential purposes should generally not fire until the user has given a clear affirmative indication of consent. Loading such a pixel before consent, or firing it on page load by default, is widely viewed as inconsistent with the prior-consent standard in these jurisdictions. Under some US state frameworks that rely on opt-out rather than opt-in, timing expectations differ, so the applicable regime should determine the implementation approach.

How can tracking pixels be integrated with a consent management platform (CMP)?

A common approach is to gate pixel loading through a tag manager or the site's own logic that reads the consent state maintained by the CMP, so that a pixel only fires for the categories and purposes the user has permitted. The CMP can signal which purposes are consented, and the pixel deployment should respond to changes in that state, including withdrawal of consent. Note that a CMP supports compliance but does not by itself guarantee it; the configuration, the underlying legal analysis, and correct mapping of each pixel to a purpose remain the operator's responsibility.

How should tracking pixels be categorized in a consent banner?

Pixels should generally be classified according to their actual function rather than their format, for example as analytics, advertising, or functional, so that users can make specific, informed choices. Because a single pixel may serve more than one purpose, its classification should reflect all of those purposes. Where a pixel is used purely for a strictly necessary function it may fall within an exemption, but this is fact-specific and should not be assumed; the categorization should be supported by an accurate assessment of what the pixel does.

What should be documented about tracking pixels for consent record-keeping?

Operators typically maintain records that support their consent and processing decisions, which may include an inventory of the pixels in use, their vendors, the purposes they serve, the category they are assigned to, and the consent state under which each is permitted to fire. Retaining evidence of the consent captured before a pixel loads can help demonstrate that a clear affirmative action was obtained where that standard applies. The precise record-keeping expectations depend on the applicable regime and evolving regulatory guidance, so documentation practices should be reviewed against current obligations rather than treated as fixed.

Common misconceptions

Tracking pixels are not cookies, so cookie consent rules do not apply to them.

In most EU jurisdictions the relevant ePrivacy rules concern the placing of or access to information on a user's device, not the specific technology used. Pixels, along with local storage, SDKs, and fingerprinting techniques, can therefore fall within the same requirements as cookies, and non-essential uses typically require prior consent.

Because a pixel is invisible and stores nothing on the device, no consent or disclosure is needed.

A pixel can still transmit information such as IP address and device characteristics and can trigger the reading or setting of identifiers. Where this involves access to information on a device or the processing of personal data for non-essential purposes, consent and transparency obligations may apply in the EU; requirements can differ under other regimes such as US state privacy laws, which often rely on opt-out.

Blocking cookies is enough to stop tracking pixels.

A pixel can register a view and transmit data through the request itself, independently of whether a cookie is set. Controlling pixels generally requires managing when and whether the pixel loads, not only cookie controls.

Best practices

Inventory and classify all tracking pixels alongside cookies and similar technologies, recording their provider, purpose, and the data they transmit, so that the correct legal treatment can be assessed by purpose.

Withhold non-essential pixels until valid prior consent has been obtained where EU ePrivacy rules apply, ensuring the pixel does not fire on page load before the user takes a clear affirmative action.

Disclose pixels and their purposes in your consent notice and privacy information, including any third parties involved, rather than describing only cookies.

Distinguish geographic scope in your configuration, applying opt-in logic where required in the EU and UK and opt-out mechanisms (including recognition of signals such as Global Privacy Control) where applicable under US state privacy laws.

Maintain records of consent that reflect when pixels were allowed to load, and periodically re-audit pages and emails to detect pixels added outside the consent management process.

Treat consent management platforms and tag or pixel management tools as support for compliance rather than a guarantee of it, and confirm through testing that blocked pixels genuinely do not fire before consent.