Skip to main content
green gradient background, "The Future of Application Security Is Already Here." and a read the report button.
Category: Tracking Technologies

Web Beacons

Also known as: tracking pixel, web bug, pixel tag, clear GIF
Simply put

A web beacon is a tiny, usually invisible graphic or file embedded in a web page or email that allows the sender or site operator to detect when the content has been viewed or opened. It is commonly used to track user behavior, gather analytics, and monitor how people interact with a page or message. Although not a cookie, it serves a similar tracking purpose and is often used alongside cookies.

Formal definition

A web beacon is a small, typically transparent or invisible object (often a 1x1 pixel image or other embedded resource) placed on a web page or within an email that, when loaded from a remote server, signals that the containing content has been accessed. The retrieval request can convey information such as access time and associated identifiers, enabling analytics and behavioral tracking, frequently in combination with cookies. Because web beacons involve reading from or writing to a user's device and may facilitate the processing of personal data, they generally fall within the same regulatory scope as cookies under EU frameworks such as the ePrivacy Directive and, where personal data is processed, the GDPR; consequently, non-essential beacons typically require prior consent in most EU jurisdictions, while requirements differ under other regimes such as US state privacy laws. The precise compliance treatment depends on the specific use, data collected, and applicable jurisdiction, which are outside the scope of this definition.

Why it matters

Web beacons matter because they extend tracking capabilities beyond cookies into contexts where cookies alone are limited, most notably email. When an email containing a beacon is opened, the remote request to load the invisible image can signal that the message was viewed, along with information such as access time and associated identifiers. This makes beacons a powerful tool for analytics and behavioral monitoring, but also one that can operate without a user's awareness, since the tracking element is typically invisible.

From a compliance standpoint, web beacons are significant because they are frequently treated in the same way as cookies under EU frameworks. The placing of or access to information on a user's device is governed by the ePrivacy Directive and its national implementations, and where the beacon facilitates the processing of personal data, the GDPR applies as well. As a result, non-essential beacons generally require prior consent in most EU jurisdictions, whereas requirements differ under other regimes such as US state privacy laws, which often rely on opt-out mechanisms. Because beacons are not literally cookies, organizations sometimes overlook them when building consent and disclosure practices, creating a compliance gap.

The precise treatment of any given beacon depends on how it is used, what data it collects, and the applicable jurisdiction, and these facts are outside the scope of a general definition. Organizations should assess each beacon deployment on its own terms rather than assuming that a technology which is not a cookie falls outside consent obligations.

Who it's relevant to

Privacy officers and data protection professionals
Web beacons should be inventoried and assessed alongside cookies, not treated as a separate or exempt category. Because non-essential beacons generally require prior consent in most EU jurisdictions where personal data is processed, privacy teams need to confirm that beacon use is captured in consent flows, disclosures, and records rather than assumed to be outside scope.
Marketing and email compliance teams
Beacons are commonly embedded in emails to detect when a message is opened, which raises consent and transparency considerations distinct from web analytics. Teams should be aware that the legal treatment differs between the EU, the UK, and individual US states, and that opt-in and opt-out expectations vary accordingly.
Web developers and engineers
Developers implementing analytics or tracking pixels should recognize that beacons, like cookies, involve accessing a user's device and may trigger consent obligations. Building deployments so that non-essential beacons can be conditioned on obtained consent supports compliance, though technical controls alone do not resolve the underlying legal questions.
Legal counsel
Counsel advising on tracking technologies should treat web beacons within the same analysis applied to cookies under the ePrivacy Directive and, where personal data is processed, the GDPR, while accounting for differing requirements under other regimes such as US state privacy laws. The precise treatment depends on the specific use, data collected, and jurisdiction, which require fact-specific evaluation.

Inside Web Beacons

Tracking pixel
A web beacon is commonly implemented as a tiny, often 1x1 pixel, transparent image or similar embedded resource whose request to a server reveals that a page or email has been loaded. The visual element itself is typically invisible to the user.
Server request as signal
The core mechanism is the HTTP request triggered when the beacon loads. That request can transmit information such as the fact of a page view or email open, timestamps, IP address, and other details available in the request headers, and can be associated with identifiers.
Association with cookies and identifiers
Web beacons are frequently used together with cookies or other identifiers to link activity to a particular browser, device, or user, which is often how the resulting data becomes personal data.
Use in emails and web pages
Beacons appear in both web pages and HTML emails. In emails they are typically used to detect opens and engagement, while on web pages they support analytics, advertising measurement, and behavioral tracking.
Legal treatment alongside other tracking technologies
Although a beacon 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 falls within the same ePrivacy rules as cookies, and any resulting processing of personal data is governed by the GDPR.

Common questions

Answers to the questions practitioners most commonly ask about Web Beacons.

Are web beacons exempt from consent because they are not technically cookies?
No. Although web beacons (also called tracking pixels or clear GIFs) are not cookies in the technical sense, EU rules on cookie consent are not limited to cookies. The ePrivacy Directive and its national implementations generally govern the storing of, or gaining access to, information on a user's device, and this is widely interpreted to capture web beacons and similar technologies where they are used to read or transmit information from the device. Where a web beacon is used for analytics, advertising, or other non-essential purposes, prior consent is typically required in most EU jurisdictions, just as it would be for a comparable cookie. The technology label does not determine the obligation; the purpose and function do.
If web beacons only collect anonymous or aggregate data, does that mean no privacy rules apply?
Not necessarily. Two distinct legal regimes can be engaged. The ePrivacy rules on accessing information on a device can apply regardless of whether the information is personal data, so the consent question may arise even where the data is claimed to be non-personal. Separately, the GDPR applies where personal data is processed, and data that is described as anonymous is often in practice pseudonymous or linkable to an identifier, which would still be personal data. Whether data is genuinely anonymous is a fact-specific assessment that this definition cannot resolve. As a general matter, describing beacon data as anonymous does not by itself remove either the ePrivacy consent obligation or potential GDPR obligations.
How can we identify web beacons already present on our website or in our emails?
Web beacons are often embedded as small or invisible image requests, script tags, or references loaded from third-party domains, so they may not appear in a standard cookie scan that only inspects stored cookies. Reviewing outbound network requests, examining the page and email HTML for image or tracking tags, and auditing third-party tags deployed through a tag manager can help surface them. Because beacons can be introduced by marketing tools, email platforms, and embedded content, a combined technical and vendor-inventory review is generally more reliable than a cookie-focused tool alone. The specific findings depend on your stack and are out of scope for this general guidance.
Should web beacons be blocked until a user has given consent?
In most EU jurisdictions, non-essential web beacons used for purposes such as analytics or advertising should generally not fire before valid consent is obtained, consistent with the prior-consent standard applied to comparable technologies. In practice this often means integrating beacon-loading tags with a consent management platform so they are held back until the relevant consent category is granted. Requirements differ under other frameworks; for example, several US state privacy laws rely on an opt-out model rather than prior opt-in, which may change when a beacon can lawfully operate. The correct configuration depends on the jurisdictions you serve and the purpose of each beacon.
How should email tracking beacons be handled compared with website beacons?
Email tracking beacons, commonly used to detect opens and engagement, raise similar consent and transparency questions but arise in the context of electronic communications, where additional rules on marketing and consent may apply depending on the jurisdiction. Because such beacons access information relating to the recipient's device and behaviour, some data protection authorities have treated their use as requiring a lawful basis and appropriate transparency. The precise obligations vary by country and by whether the recipient is an existing customer or a new contact, and the applicable marketing rules are broader than this cookie-focused entry. Specific email marketing compliance requirements are out of scope here.
What should we record about web beacons for accountability and record-keeping purposes?
As with other tracking technologies, it is generally advisable to document each beacon's provider, purpose, the categories of data it collects, the consent category it is assigned to, and the retention and sharing arrangements involved. Where consent is required, maintaining logs of consent decisions that govern when beacons fire supports the accountability expectations under the GDPR. A consent management platform can help capture and store these records, but it supports compliance rather than guaranteeing it, and the adequacy of your records ultimately requires legal judgment about the specific processing involved. This entry does not prescribe a fixed record format, which may vary by organisation and jurisdiction.

Common misconceptions

Web beacons are exempt from consent because they are not cookies.
The relevant EU rules generally apply to the storing of or access to information on a user's device regardless of the technology used. In most EU jurisdictions, beacons used for analytics or advertising typically require prior consent in the same way cookies do, while genuinely strictly necessary uses may be exempt. Classification depends on the specific purpose and facts.
Because they are invisible and lightweight, web beacons do not process personal data.
The invisible nature of a beacon does not determine whether personal data is processed. Information such as IP address, combined with cookies or other identifiers, can make beacon data personal data, in which case the GDPR applies in the EU. Whether a given beacon processes personal data depends on the data collected and how it is linked to individuals.
Consent for cookies automatically covers web beacons and other similar technologies.
Consent must generally be specific and informed. Where beacons serve distinct purposes or transmit data to distinct parties, users should typically be informed and, where required, consent obtained for those purposes. Consent obtained for one technology or purpose does not automatically extend to all tracking technologies.

Best practices

Inventory all web beacons and pixels alongside cookies and other tracking technologies, recording their purpose, the data they transmit, and the parties that receive that data.
Classify each beacon by purpose (for example strictly necessary versus analytics or advertising) and, in EU and UK contexts, obtain prior consent for non-essential uses through your consent management platform before the beacon loads.
Disclose the use of web beacons in emails and on web pages within your cookie or privacy notice, describing the purposes and recipients so that any consent is informed.
Ensure that beacons requiring consent are actually suppressed until valid consent is given, and verify this technically rather than assuming the CMP blocks them.
Assess whether beacon data constitutes personal data under the GDPR, and apply the corresponding obligations, since a tool alone does not resolve that legal judgment.
Account for differing regimes: EU and UK rules generally rely on prior consent for non-essential tracking, while several US state laws often rely on opt-out mechanisms, and confirm the geographic scope before applying a single approach.
a promotional banner asking how ready are you for PCI DSS 4.0? With a call-to-action to get the checklist now.