How Do Tracking Pixels Set Cookies?

The HTTP request-response cycle

Every tracking pixel starts as a standard HTTP request. The mechanism is defined in RFC 6265 (HTTP State Management Mechanism), which says that any HTTP response, regardless of content type, can include Set-Cookie headers.

Here's the full sequence:

1. The page loads a pixel

A website includes an image tag pointing to an external server:

<img src="https://tracker.example.com/pixel.gif?page=/checkout" width="1" height="1" />

2. The browser sends a request

The browser makes a GET request to tracker.example.com. This request automatically includes the user's IP address, User-Agent string, the referring page URL, and any cookies the browser has previously stored for tracker.example.com:

GET /pixel.gif?page=/checkout HTTP/2
Host: tracker.example.com
Referer: https://shop.example.com/checkout
Cookie: uid=abc123

3. The server responds with an image and a cookie

The server returns a 1x1 transparent GIF (43 bytes) and includes a Set-Cookie header:

HTTP/2 200 OK
Content-Type: image/gif
Content-Length: 43
Set-Cookie: uid=abc123; Domain=tracker.example.com; Max-Age=31536000; SameSite=None; Secure; HttpOnly

4. The browser stores the cookie

The browser processes the Set-Cookie header and stores the cookie under the tracker.example.com domain. The next time any page loads a pixel from tracker.example.com, the browser automatically attaches the uid=abc123 cookie to the request. That is how the server recognises the same user across different sites.

Two mechanisms: server-side vs. client-side

Not all pixels set cookies the same way. There are two distinct mechanisms, and many tracking implementations use both.

Server-side: the Set-Cookie header

This is the mechanism described above. The pixel is a plain image request. The server's HTTP response includes a Set-Cookie header. No JavaScript is involved; the browser processes the cookie as part of standard HTTP handling.

• Works even when JavaScript is disabled
• Cookie is scoped to the pixel server's domain (third-party context)
• Can use the HttpOnly flag, which keeps the cookie out of JavaScript's reach

Client-side: JavaScript document.cookie

Many "pixels" are actually JavaScript tags rather than image elements. These scripts execute on the host page and can write cookies directly:

document.cookie = "tracker_id=xyz789; max-age=31536000; path=/; SameSite=Lax; Secure";

Because the script runs in the context of the host page, cookies set via document.cookie are first-party cookies. They belong to the website's domain, not the tracker's. That distinction is important: first-party cookies are not subject to the same browser restrictions as third-party cookies, which is why this method has caught on as browsers tighten their cross-site cookie policies.

A JavaScript pixel can also fire secondary image or XHR requests back to its own server, and the server can then set additional third-party cookies via Set-Cookie headers. The same tracking implementation ends up using both mechanisms at once.

Key cookie attributes in pixel responses

The Set-Cookie header includes attributes that control how the browser handles the cookie. For tracking pixels in a third-party context, those attributes decide whether the cookie actually works.

Cookie syncing: how pixels link identities across platforms

The mechanism described above lets a single tracking server identify users across sites. But ad tech ecosystems are full of separate platforms (ad exchanges, demand-side platforms, data management platforms, and so on), each with their own cookies. To link those identities together, they use a technique called cookie syncing.

In a cookie sync, a pixel request from Platform A redirects through Platform B. Each platform reads or sets its own cookie during its leg of the redirect, and tacks the other platform's user ID onto the URL as a parameter. Both platforms then store the mapping in a match table, so two independent identifiers can be tied to the same user.

Cookie syncing has real privacy and performance costs. Industry data suggests match rates of only around 60%, and each redirect adds latency. We cover it in more depth in a dedicated explainer (coming soon).

When browsers block the cookie

The mechanism above assumes the browser will honour the Set-Cookie header from a cross-site pixel response. More and more often, it doesn't.

Safari: Intelligent Tracking Prevention (ITP)

Safari blocks virtually all third-party cookies by default. A pixel loaded from tracker.example.com on shop.example.com will have its Set-Cookie header silently ignored. ITP also caps first-party JavaScript cookies at 7 days if the script gets flagged as a tracking resource, which closes off the document.cookie workaround.

Firefox: Total Cookie Protection

Firefox doesn't block the cookie outright. It partitions it. Each top-level site gets its own cookie jar for third-party domains. A cookie set by tracker.example.com on shop.example.com is stored separately from one set on news.example.com. The cookie still exists, but it can't be used to link visits across different sites.

Chrome: SameSite defaults and CHIPS

Chrome still allows third-party cookies from pixel responses, as long as they include SameSite=None; Secure. Chrome also supports the Partitioned attribute (CHIPS), which is an opt-in flavour of Firefox-style per-site cookie isolation. Cookies with SameSite=None that do not include Partitioned may be blocked in future Chrome versions.

Why this matters for your website

If your site loads third-party pixels (from ad platforms, analytics providers, social widgets, marketing tools), those pixels may be setting cookies you don't know about. The mechanism is invisible. Nothing triggers your consent banner, nothing appears on the page, and the cookies don't show up in your source code. They exist only in the HTTP response headers between the user's browser and the pixel server.

Under GDPR, these cookies need informed consent before they get set. If a pixel fires before your consent banner loads, or if it fires regardless of the user's choice, you have a compliance gap.

Tagmaps maps every cookie on your site back to the pixel or script that created it, and tells you whether it was set via a Set-Cookie header or through JavaScript. It also scans before and after consent so you can spot pixels firing outside your consent policy.