What Is a Tracking Pixel?

Technically, a tracking pixel is an <img> tag whose src attribute points to a server outside the page's own domain instead of a real image. The browser or email client loads it like any other image, no JavaScript required, and that plain HTTP request gets logged on the destination server with the IP address, user agent, timestamp and, if the URL carries parameters, the campaign or message ID.

The name gets confused with cookies constantly, but they solve different jobs: the pixel triggers the request, the cookie stores an identifier across visits. Most pixels in use today, like Meta's or LinkedIn's Insight Tag, don't load as a literal 1x1 image anymore. They run as a JavaScript tag that does both at once: it fires the event to the server and also reads or writes a cookie to recognize the same browser on a later visit. The word "pixel" stuck around out of habit even as the underlying technology moved on.

It gets used for three things mainly: confirming that an email got opened, logging the arrival on a landing page after an ad click, and building remarketing lists from visitors who were on a specific page.

The three terms get mixed into one sentence often, but each solves a separate piece of the same problem.

The technical path differs across the three, but the duty to obtain consent stays the same in each one.

When the browser parses the HTML of a page or email, it hits the pixel tag and sends a GET request to the server named in the src attribute. The server only needs to return a minimal, usually transparent, 1x1 image in reply; what matters is the request itself, logged with a timestamp, IP address and the rest of the HTTP headers. If the URL carries a parameter with a message or campaign ID, that log entry links directly to that specific send.

JavaScript-based pixels, like Meta's or Google Ads', go a step further: alongside firing the request, they read an existing cookie on the advertiser's domain or set a new one. That's how the same browser gets recognized on a later visit, and how remarketing audiences get built from it. That step depends entirely on whether the browser allows storing and reading cookies across different sites, and that's exactly where 2026 looks uneven: Safari has blocked third-party cookies by default since version 13.1 in 2020, Firefox since 2019 with tracking protection turned on for every user, and Chrome, after years of announcing it would remove them, reversed course in July 2024 and confirmed in October 2025 that it's keeping them while retiring most of the Privacy Sandbox technologies that were meant to replace them.

That's why server-side tracking has grown as a companion approach: instead of waiting for the browser to fire the request, the advertiser's own server sends the event directly to the platform through an API, such as Meta's Conversions API or Google Ads Enhanced Conversions. That gets around a blocker running in the browser, though the data itself stays personal information reaching a third party, and it still needs the same legal basis as the classic pixel.

Real budget decisions ride on what a pixel captures. If a conversion never gets logged because the pixel didn't fire, that campaign looks weaker than it actually performed, and spend shifts toward whatever channel does have data, not necessarily toward whatever channel produced the result.

There's a direct legal risk too. Firing a pixel that carries personal data before the user has consented breaches Article 5(3) of the ePrivacy Directive, and regulators such as France's CNIL have already fined companies for exactly this pattern. That's a compliance risk with a real price tag attached.

Browser fragmentation also makes campaigns harder to compare: the same action can show different numbers in Chrome than in Safari, a purely technical effect tied to how many events each browser actually captures. Moving to server-side tracking takes more setup work upfront, but that investment usually pays off in steadier data over time.

Given how unevenly browsers treat cookies now, and the regulatory pressure on top of that, more companies lean on first-party data and server-side tracking so they aren't left depending on a cookie a browser can block at any point.

• Wire the pixel to the consent banner (CMP) at the technical level, so the request only leaves the browser after the user has actually accepted.
• Document every active pixel in the cookie policy under its real provider name, not a generic bucket like "advertising."
• Prioritize server-side tracking for the conversions that actually drive budget decisions, instead of relying only on the browser-based pixel.
• Review which pixels are still loading on the site on a regular basis; leftovers from a closed campaign only add risk without producing any useful data.
• Check the browser's network tools to confirm no pixel fires before the user has given consent.
• Keep identifiable data, like a plaintext email address, out of the pixel's URL parameters.

• Firing the pixel before the user accepts the cookie banner, the single most fined mistake in this area.
• Assuming server-side tracking skips the consent requirement because it doesn't set a cookie, when it still carries personal data.
• Relying only on a third-party-cookie pixel for remarketing audiences, with no fallback for Safari or Firefox.
• Leaving the pixel out of the record of processing activities and the site's privacy policy.
• Assuming Chrome already removed third-party cookies, when Google itself confirmed in 2025 that it kept them.