Two ad companies both have a cookie on your browser. One calls you user-8842, the other calls you abc-1179. Neither can read the other's cookie, because the browser only lets a domain read cookies it set. So how does an ad you looked at on one site follow you to a completely different one? A background handshake called cookie syncing, or cookie matching.
It's one of the least visible pieces of ad tech and one reason a single page can fire dozens of third-party requests. Once you see how it works, a lot of "how did they know" moments stop being mysterious.
The problem it solves
The browser enforces a hard rule: a cookie set by adnetwork-a.com can only be read by adnetwork-a.com. That's the same-origin boundary that keeps one site from reading another's cookies. It also means two ad platforms that both track you have no shared name for you. A demand-side platform bidding on an ad slot and a data provider that knows your interests are looking at the same browser under different IDs, with no way to line them up.
Cookie syncing is the workaround. It lets two parties agree that their ID and your ID point at the same browser, so they can trade data about that user in real time when an ad slot comes up for auction.
The handshake, step by step
The mechanism rides on redirects and URL parameters, because those are the one thing that crosses domains freely:
- You load a page that includes a pixel or tag from platform A. Platform A reads its own cookie and finds your ID,
user-8842. - Platform A's response redirects your browser to platform B's sync endpoint, with A's ID tacked onto the URL:
sync.platform-b.com/match?partner_id=user-8842. - Your browser makes that request to platform B. Now B reads its own cookie (
abc-1179) and also sees A's ID sitting in the URL. - Platform B stores the pair in a match table: A's
user-8842equals myabc-1179. If the sync is two-way, B redirects back to A with its ID so A can store the mirror image.
Repeat that across a dozen partners and the platforms build a shared map of IDs, without any of them ever reading another's cookie directly. The user sees nothing but a slightly slower page.
Why your page feels heavy
Each sync is at least one extra network request, and popular tags chain syncs to many partners at once. That's a real slice of the third-party requests, redirects, and data transfer on an ad-supported page, and it happens before you've interacted with anything. It's also a privacy surface: every partner in the chain gets handed an identifier.
The GDPR and consent problem
Cookie syncing runs on third-party cookies and shares a personal identifier across companies, which under the GDPR and the ePrivacy rules is processing that needs a legal basis. For this kind of cross-site advertising, that basis is consent. The sync fires the moment the ad tag loads, so if it runs before the visitor has agreed, the consent came too late. Regulators have treated exactly this pattern, tags that read and share IDs on page load, as a violation.
This is why blocking order matters. A banner that appears while the syncs are already flying does nothing. The tags have to be held until the visitor opts in. For what a compliant setup looks like, see how to block scripts before consent.
Why cookie syncing is fading
The whole technique depends on third-party cookies, and browsers have spent years dismantling those. Safari's tracking prevention and Firefox's cookie isolation already block cross-site cookies by default, which breaks syncing on a large slice of traffic. Chrome kept third-party cookies alive longer than expected and, in 2025, stepped back from forcing them out, but it has added user controls and cookie partitioning that still disrupt the classic sync. For where that stands, see third-party cookies aren't dead in Chrome and partitioned (CHIPS) cookies.
The industry's answer has been to move identity server-side and toward shared login-based IDs, which shifts the same matching problem onto first-party data. That doesn't remove the consent requirement; it relocates it. See first-party vs third-party cookies.
Where CookieBeam fits: its scanner watches the outbound connections a page makes, so the sync requests to partner domains show up in the inventory as third-party connections tied to the tag that triggered them. You see which vendors your ad tags talk to, and those tags stay blocked until a visitor opts in.
What this means if you run the site
If your pages carry ad tags, cookie syncing is happening on your domain whether you arranged it or not, and each partner in the chain is processing your visitors' data under your banner. Three things keep you on the right side of it. Know your vendors: a scan that lists the outbound connections a page makes shows exactly which sync partners your tags pull in, including ones you never chose directly. Block before consent: the syncs must not fire until the visitor opts into advertising, which means gating the tags rather than showing a notice while they run. And disclose honestly: your cookie policy and vendor list should name the partners, because "and our advertising partners" is not a vendor list. See how cookie scanners work.