Cookie syncing, explained for publishers who sell programmatic ads

Cookie syncing (also called cookie matching) is how two ad tech companies link their own IDs for the same browser, so a buyer can recognise a visitor that a seller sends into an auction. It happens through small redirect calls, called sync pixels, that fire on publishers' pages and save the pairing in a match table.

Here's why you should care. Those sync calls run on your pages, use your visitors' bandwidth, need your visitors' consent in many countries, and decide how much some buyers bid for your ad slots. Most publishers never look at them.

This guide explains what cookie syncing is, how it works with the tools you actually run (Prebid.js, Prebid Server and Google's ad stack), what it costs you, where it no longer works in 2026, and which settings we'd change first. If you'd rather hand the whole bidding setup to someone, our header bidding service covers the sync and consent side too.

What is cookie syncing?

Cookie syncing is the process of matching one company's user ID to another company's user ID for the same browser. Each ad tech company sets its own cookie with its own random ID, so on its own an SSP's ID means nothing to a DSP. A sync creates the link between the two.

Think of it like two shops with different loyalty cards. The SSP knows the browser as "abc123". The DSP knows the same browser as "x9-77". Neither can read the other's cookie, because browsers only send a cookie back to the domain that set it.

So they swap notes once, store the pair, and from then on the SSP can say "this is your x9-77" in a bid request.

That's the whole idea. Everything else, the pixels, the redirects and the tables, is plumbing to make that swap happen. If you're new to the cookie side of this, our guide to third party cookies explains why an SSP's cookie can't simply be read by a DSP.

Cookie syncing vs cookie matching

They're the same thing. "Cookie matching" is the name Google uses in its buyer docs, and "user sync" is the name Prebid uses in its settings. You'll see all three in config files and vendor contracts.

How cookie syncing works, step by step

Cookie syncing works by sending the browser from one ad tech domain to another, with an ID in the URL, so each side can read its own cookie and store the other's ID. Here's the most common version, as it happens on a publisher's page:

1. A visitor loads your article. Your header bidding wrapper or ad tag loads, and the auction runs.
2. A sync pixel fires. After the auction, the wrapper drops a tiny image or iframe whose URL points at the SSP's sync endpoint.
3. The SSP reads its cookie. The browser sends the SSP's cookie with that request, so the SSP knows its own ID for this browser, say "abc123".
4. The SSP redirects to the DSP. It sends the browser on to the DSP's endpoint with "abc123" in the URL.
5. The DSP reads its cookie. The DSP now sees its own ID, "x9-77", next to the SSP's ID, and stores the pair in its match table.
6. Next auction, the ID travels. When that browser shows up again, the SSP puts the DSP's ID into the bid request, and the DSP can use what it knows about "x9-77".

In OpenRTB, the standard most exchanges use for bid requests, that field has a name. The OpenRTB 2.6 spec defines user.id as the "exchange-specific ID for the user" and user.buyeruid as the "buyer-specific ID for the user as mapped by the exchange for the buyer". That second field is what cookie syncing fills. No sync, no buyeruid, and the buyer is bidding on a stranger.

Single-partner and multi-partner syncs

A single-partner sync links two companies, as above. A multi-partner sync chains redirects so one page view syncs an SSP with several DSPs, or a DMP with several buyers. That's where page cost climbs, because every hop is another request from your visitor's browser.

Some explainers call the single-partner version "server-to-server". It isn't. Both kinds run through the visitor's browser. Server-to-server matching is a different thing, covered below with Prebid Server.

Cookie syncing in Prebid, Prebid Server and Google

On a real publisher page, cookie syncing is run by three things: Prebid.js bidder adapters, Prebid Server, and Google's own cookie matching for its buyers. Here's what each one does, with the settings you control.

Prebid.js user sync

Every Prebid.js bid adapter can register sync pixels, and Prebid fires them for you. The Prebid setConfig docs list the defaults:

• syncEnabled is true, so user sync is on unless you turn it off.
• Image syncs are enabled by default, and iframe syncs are disabled by default. You allow iframes per bidder with filterSettings.
• syncsPerBidder is 5. That's up to five sync pixels per adapter.
• syncDelay is 3000, so syncs fire 3 seconds after the auction ends, out of the way of your ads.
• enableOverride is false. Set it to true if you want to fire syncs yourself with pbjs.triggerUserSyncs().

Do the maths on a busy wrapper. Ten bidders at five syncs each is up to 50 extra requests per page view. We see setups like that more than you'd think, usually because bidders were added over the years and never reviewed.

Prebid also stops syncs where they can't work. Its docs say the sync queue "is not fired at all if the browser is Safari", nor, since Prebid.js 11.9, Firefox or Chrome on iOS, nor when cookies are disabled or access is denied by consent. Adapters still register their syncs, but no pixels fire.

Since 11.20 the Prebid Server adapter skips its own sync call under the same rules. If you're on an old version, you're firing pixels that can't do anything. Our Prebid.js setup guide covers updating safely.

Prebid Server cookie sync

Prebid Server, the server-side half of Prebid, keeps its own ID list. Per the Prebid Server user ID sync docs, it "stores bidder IDs in the uids cookie in the host domain". The flow goes like this:

1. The page calls Prebid Server's /cookie_sync endpoint with the bidder list and the consent strings.
2. If privacy rules allow, Prebid Server checks the uids cookie and returns sync URLs for bidders it has no ID for.
3. Each bidder's endpoint reads its own cookie and redirects back to Prebid Server's /setuid endpoint with its ID.
4. Prebid Server checks privacy settings again and, if allowed, saves the ID in the uids cookie.
5. In later auctions, Prebid Server puts that value into request.user.buyeruid for the bidder.

So server-side bidding doesn't remove syncing. It moves the match table into a cookie on the Prebid Server host's domain, which is still a third-party cookie on your page.

Google cookie matching

Google runs cookie matching for the buyers that bid on Ad Exchange through Authorized Buyers. Google's cookie matching guide says it "allows you to link your user ID to a corresponding Google User ID". A buyer places a match tag such as https://cm.g.doubleclick.net/pixel?google_nid=...&google_cm, and Google then passes the result in BidRequest.user.buyeruid.

Google also recommends that buyers let Google host the match table. For you as a publisher, the point is this: if you sell through AdSense, Ad Manager or AdX, Google's own matching runs on its side. You don't add or manage those pixels, and you can't speed them up. What you do control is your Prebid and Prebid Server syncs.

Why cookie syncing matters for your ad revenue

Cookie syncing matters because buyers pay more for visitors they can recognise. A DSP that can match your visitor to its own ID can use its audience data, cap frequency and measure results, and that's worth more to an advertiser than an anonymous impression.

Here's how that plays out in an auction.

Say two visitors land on the same article. One is in Chrome with consent and synced IDs, so the bid request carries buyeruid values for several DSPs. The other is in Safari, with no third-party cookies, so the request carries none. Buyers running retargeting or audience campaigns can bid on the first visitor and have little to go on for the second.

That's why some publishers see lower CPMs on Safari traffic. It isn't the browser itself. It's that buyers can't match the user. Our post on real time bidding shows where these IDs sit in the bid request.

What a cookie match rate is

A cookie match rate is the share of a seller's IDs that a buyer can link to its own IDs. A low cookie match rate means the buyer sees many of your impressions as unknown. Vendors quote all sorts of match rate figures, often from studies several years old, so treat any single number with care. The direction is what counts: more matched users, more bidders with a reason to bid high.

The costs of cookie syncing for publishers

Cookie syncing has three costs that land on you, not the ad tech companies: page speed, consent and data leakage. Each one is worth checking.

On privacy, Prebid's TCF consent management docs are direct: if the user hasn't consented to Purpose 1, set deviceAccess: false, don't enable userSync and don't enable User ID modules. The TCF Control module lists "invoke usersync pixels" as an activity tied to Purpose 1, "store and/or access information on a device", and can block vendor syncs that lack it.

Here's the catch. A sync pixel fired before the consent banner is answered is a cookie set without consent. When we review a site, opening the network tab before clicking the banner is one of the first things we do, and stray sync calls show up there more than any other ad request.

Does cookie syncing still work in 2026?

Cookie syncing still works in Chrome, and mostly doesn't in Safari and Firefox. That split is the most important thing to know about it today.

The sources behind that table: in its 17 October 2025 Privacy Sandbox update, Google said Chrome "will maintain our current approach to offering users third-party cookie choice", and it retired most of the Privacy Sandbox ad APIs (our Privacy Sandbox guide covers what that means for you). WebKit's March 2020 post says cookies for cross-site resources "are now blocked by default across the board" in Safari. And MDN's third-party cookies guide explains that Firefox gives "third-party cookies a separate cookie jar per site", which stops a cookie from linking one browser across sites.

One more detail from MDN. A cookie only travels in a cross-site request if it's set with SameSite=None, and then it also needs the Secure attribute. A sync endpoint that sets cookies wrongly simply doesn't match anyone, even in Chrome.

So don't believe pages that say cookie syncing is dead, and don't believe the ones that say nothing has changed. If half your traffic is on iPhones, half your audience is already outside it.

Alternatives to cookie syncing

The alternatives to cookie syncing put an ID or a signal straight into the bid request instead of matching cookies through redirects. You'll use a mix of them, not one.

• Universal ID modules. Prebid's User ID module sets up shared pseudonymous IDs and passes them to every bidder in bidRequest.userId. The docs pitch it as a way to avoid "having several exchanges sync IDs with dozens of demand sources". Each ID provider has its own terms and consent needs, so add them one at a time. Our guide to universal IDs for publishers compares the main types.
• Publisher provided IDs. In Ad Manager 360, a publisher provided identifier (PPID) lets you send your own first-party ID for frequency capping and audience segments. It works for logged-in or returning readers whatever the browser.
• First-party data. Your own audience segments, built from what readers do on your site. Here's how to build and activate those segments. Our guide to DMPs for publishers covers when that's worth the effort.
• Contextual signals. Page category, keywords and content data, passed to bidders so they can price the page even when they can't match the user.

Our opinion: keep cookie syncing tidy for Chrome, and put your real effort into the list above. That's the work that pays on Safari, Firefox and declined-consent traffic, where syncing can't help at all.

Cookie syncing settings we check in a header bidding review

When we review a publisher's header bidding setup, we go through cookie syncing in this order. It takes about half an hour with the browser's network tab and the wrapper config open side by side.

1. Count the sync calls. Load a page in Chrome with consent given, filter the network tab for "sync", "usersync", "setuid" and "match", and count. Then do the same in Safari. Safari should show close to none.
2. Check timing. Syncs should fire after the auction. If you see them before your first ad renders, check syncDelay or whether a bidder fires its own pixels outside Prebid.
3. Check consent. Reload with the banner unanswered, then declined. No sync calls should fire before an answer, and none after a decline in the EU or UK.
4. Trim bidders. Look at win rates in your reports. A bidder that hasn't won in months still costs you its syncs. Remove it, or at least drop its sync.
5. Limit iframes. Keep iframe syncs off unless a bidder you value needs them, and allow it by name in filterSettings.
6. Update Prebid. Version 11.9 or later skips syncs on Firefox and Chrome on iOS, so you stop firing pixels that can't work.
7. Check Prebid Server. If you run server-side bidders, confirm the /cookie_sync call carries your consent strings.

Here's a trimmed Prebid config that matches the checklist. Treat the bidder names as placeholders for your own:

pbjs.setConfig({
  userSync: {
    syncEnabled: true,
    syncsPerBidder: 2,
    syncDelay: 3000,
    filterSettings: {
      iframe: { bidders: ['bidderA'], filter: 'include' },
      image:  { bidders: '*', filter: 'include' }
    }
  }
});

Lowering syncsPerBidder from 5 to 2 is a judgement call, not a rule. Watch your Chrome CPMs for a couple of weeks after any change and put a bidder back if its bids drop. Our guide to SSPs covers how to test one partner at a time.

Frequently asked questions

What is cookie syncing in simple terms?

It's two ad tech companies agreeing that their two different IDs belong to the same browser. They do it with a quick redirect between their domains, store the pair, and use it later so a buyer can recognise a visitor in a bid request.

Is cookie syncing the same as cookie sharing?

No. Neither company reads the other's cookie. Each reads only its own, and they swap the ID values in a URL. What gets shared is the ID mapping, plus the fact that the browser visited your page.

Does cookie syncing slow down my site?

It adds requests, so yes, a little, and a lot with many bidders. With Prebid's default 3-second delay the syncs fire after the auction, so they don't hold up your ads. They still use the visitor's bandwidth, which is why trimming partners helps.

Does cookie syncing need consent?

In the EU and UK, yes, because syncs read and set cookies on the visitor's device. Prebid's docs tie user syncs to TCF Purpose 1 and say not to enable them without it. Rules elsewhere vary, so check the laws where your visitors are.

Does cookie syncing work in Safari?

No. Safari has blocked third-party cookies by default since 2020, so there's no cookie for a sync to read, and Prebid.js doesn't fire its sync queue in Safari at all. Safari visitors are reached with first-party IDs and page context.

Is cookie syncing going away?

Not in Chrome for now. Google said in October 2025 that Chrome will keep giving users the choice over third-party cookies. It's already gone in Safari and limited in Firefox, so plan as if a large share of your traffic can't be synced.

Next step

Cookie syncing still earns its place for Chrome visitors, as long as it runs after the auction, inside consent and with partners who actually bid. Count your sync calls today, trim the ones that don't pay, and put the time you save into first-party IDs and context. If you'd like us to look at your wrapper and sync setup, ask for a free site review.