Header bidding explained: a buyer's view of the auction
The auction that runs before the ad server is asked anything — and why it changes what you pay for the same person.
Almost every page that ranks for this term is written for publishers. That is useful if you sell ad space. Less useful if you buy it.
This page sits under our hub on programmatic advertising in India, which covers the whole buying chain. Here we stay on one piece of plumbing and finish it properly.
What header bidding actually is
Say it to your CFO like this: the publisher asks every buyer for a price at the same time, instead of asking them one at a time.
Three parts do the work.
- The wrapper. Code on the page that holds the auction, keeps the list of bidders and enforces a time limit. Prebid.org calls Prebid "the most widely used header bidding 'container' or 'wrapper'" (Prebid Overview, accessed 15 October 2026). It is free and open source.
- The bidders. The exchanges and networks the publisher has chosen to let bid. Prebid.org's own line: "publishers decide which suppliers can bid on their impressions."
- The ad server. Still picks the final winner. The header bid arrives as a number it has to beat with its own demand and direct deals.
The name is a historical accident, and Prebid.org says so. The code once sat in the HTML header; now the same idea runs in apps, video and server-side. Prebid's own documentation suggests "pre-ad server bidding" as the accurate term. That phrase tells you more about the mechanism than "header bidding" ever did.
Sequential became parallel.
The waterfall, and what it actually cost
Before this, publishers sold leftover inventory down a chain. Google's own Ad Manager documentation still describes the mechanism plainly: Ad Manager "assembles a list, or chain, of ad networks to receive that request in sequence," and that chain is "ordered from highest to lowest expected yield using historical performance data or user-entered CPM values." Each network gets a call "until an ad is returned" (How mediation works, accessed 15 October 2026).
Read that twice and the problem is obvious.
- The order was a guess. It came from past averages, not from this impression. A buyer who would have paid well for this person sat fourth in the chain and was never asked.
- Nobody could see inside it. Prebid.org's history of the period puts it bluntly: "The whole process was mostly invisible to the publisher (and also the buyer)."
- Every miss cost time. A sequence of calls only ends when one fills. Misses stack.
- The highest bidder did not necessarily win. The first acceptable one did.
How header bidding changed the sequence
The fix was to stop asking in turn. The same auction logic that IAB Tech Lab's OpenRTB protocol standardised for real-time bidding — version 2.6 shipped in April 2022, with the 2.6-202309 update in September 2023 — gets run once, in parallel, before the ad server hears about the impression.
- The page starts to load and the wrapper fires. Prebid.org: "Requests are sent to all bidders at once, rather than one at a time."
- A timeout runs. Prebid.org: "any bidder not returning a result within the timeout duration is excluded from the auction." Slow bidders simply lose.
- The winning header bid is attached to the ad server call as a CPM value.
- The ad server compares that number with its own demand and any direct deals, then serves the winner.
There is a real cost, and Prebid.org names it rather than hiding it: with header bidding "the publisher creates a short delay in their ad serving to obtain bids." Publishers who load slowly lose impressions from people who leave first. You will see specific millisecond figures quoted for this. We have left them out, because the ones in circulation are vendor-published and not traceable to a neutral dated source.
Client-side vs server-side header bidding
Same auction, two places to hold it. This is the trade-off that actually matters.
| Question | Client-side (Prebid.js) | Server-side (Prebid Server) |
|---|---|---|
| Where the auction runs | In the person's browser. Prebid.js is "a JavaScript library that runs in the browser." | On a server. "The browser just makes one request to PBS, which delegates the actual auctions to the server." |
| Cost to the page | Every bidder is another browser request. More partners, more work on the device. | One request out of the page. The partner count moves off the user's device. |
| Identity | Each bidder reads its own cookie in the browser, where it was set. | IDs must be re-housed under the server's domain and stored in a uids cookie. A bidder with no match is flagged "no_cookie": true. |
| Who sees what | Bidders see the page and browser signals directly. | The publisher's server sits in the middle and decides what is passed on. |
| Where it is the only option | Ordinary web pages. | Apps and AMP — Prebid.org says server-side is "required in environments that don't have HTML header sections." |
| Partner supply | Limited by what the page can carry. | Prebid.org lists "230+ server-side bid adapters available." |
The honest version of the identity trade-off: server-side costs you some user matching, because the sync has to be done deliberately and only runs "if privacy regulations allow" (Prebid Server User ID Sync, accessed 15 October 2026). How much you lose is the number everyone wants. Prebid.org does not publish it, and the percentages you will find quoted come from vendors with a product in the answer. Treat them that way, and lean harder on your own first-party data instead.
What header bidding means for you as a buyer
This is the part the publisher-written pages skip. Four things change for an advertiser.
Your reach goes up quietly
Inventory that used to be committed to whoever sat at the top of the chain now goes to open auction. Prebid.org's own framing is that header bidding lets publishers "capture bids for ad units from demand sources that might otherwise have been missed." The mirror image is that you can now reach audiences you were structurally shut out of.
You bid against yourself
If a publisher runs eight partners and your DSP connects to five of them, one pageview can arrive as several separate bid requests. You are not always bidding against a rival. Sometimes you are the competition.
Frequency breaks at the edges
A cap set inside one exchange caps that exchange, not the person. Set caps where every path is counted once — at campaign level in the DSP — or your remarketing pools will hit the same people far more often than your settings say.
The same person costs different amounts
Each path adds its own fees, floor, auction rules and data on that user. Two routes to one impression are not the same product at two prices. They are two different products.
The industry built tools for exactly this, and they are free to read. IAB Tech Lab's sellers.json and the OpenRTB SupplyChain object exist so buyers can "see all parties who are selling or reselling a given bid request" — finalised by the OpenRTB Working Group on 31 July 2019 (IAB Tech Lab, page last updated 7 October 2026). ads.txt — "Authorized Digital Sellers", at version 1.1 since August 2022 — tells you who is even permitted to sell a given site, which is also your cheapest defence against ad fraud on an open-exchange buy (IAB Tech Lab ads.txt, page last updated 14 September 2026).
If you want the wider discipline of choosing and pricing those routes, that sits in our media buying explainer and the broader performance marketing guide.
Do you need to care if you only buy Google and Meta?
Mostly, no. If your media is Google Search, Performance Max and Meta, header bidding is not a lever you can touch. You do not pick the publisher's wrapper and you are not bidding into one. It starts to matter in four situations, and not before.
- You add exchange-bought inventory. Display, video or CTV through a DSP means you are buying into these auctions. Formats and sizes are covered in our display ad formats piece.
- A placement report confuses you. The same domain showing up at three different CPMs is usually paths, not fraud.
- You also publish. A brand running a large content site is a publisher, and the revenue case is real on that side.
- Someone brings you a vendor deck. Knowing the mechanism is how you read the claims in it.
One thing to keep separate: Search is a closed auction Google runs on its own inventory. There is no wrapper and no supply path there. The competitive metric you manage is impression share, which is a different system entirely.
DH's own view: what we do with this in client conversations
In our own client work, header bidding comes up in three ways and almost never the way the search results suggest.
- A client has seen it in a deck and asks if they need it. If they only buy ads, our answer is usually no. It is a publisher revenue tool wearing advertiser clothing.
- A display placement report has the same site at wildly different prices. That is the conversation where this page gets explained, and it is the only time clients find it genuinely interesting.
- The client is also a publisher. Then we point them at Prebid.org's own documentation before any managed vendor, because the wrapper is open source and the vendor's margin is not in the docs.
Before an open-exchange display buy, four things we actually do: read the ads.txt of the domains on the plan; ask the DSP for seller-level or path-level reporting and insist on getting it; set frequency caps at campaign level rather than per exchange; and keep the open exchange a small, measured share of budget until the path data earns more.
What we will not do is attach an uplift percentage to any of it. We have no neutral dated source for one, so we do not quote one.
Why this gets more useful to buyers from here
Header bidding started as a workaround publishers built around an ad server. In September 2026 it became something closer to required infrastructure. Reporting on the unsealed remedies decision in the US ad tech antitrust case says Google must build API integrations connecting AdX and DFP to Prebid, that AdX must bid into rival publisher ad servers on terms "functionally equivalent" to what DFP gets, and that Google must share real-time bid data with publishers, overseen by a court-appointed monitor for six years and applying globally (AdExchanger, 16 September 2026). No ship date for those integrations has been published.
For a buyer that points one way: more live paths to the same impression, and therefore more value in knowing which path you are on. The identity layer underneath it has not moved as fast as the decks predicted either — Google confirmed on 22 April 2025 that it would "maintain our current approach to offering users third-party cookie choice in Chrome" and would not roll out a new standalone prompt (Privacy Sandbox blog).
Which leaves the buyer-side skill exactly where it was: fewer, better-understood paths beat more of them.
Frequently asked questions
What is header bidding in simple terms?
It is an auction a publisher holds in the page before calling its ad server. Several buyers are asked for a price at the same time, and the best price is handed to the ad server as a number to beat. The older method asked buyers one after another.
What is a header bidding wrapper, and is Prebid one?
A wrapper is the code that runs the auction: it holds the bidder list, sends all requests together and enforces the timeout. Prebid.org describes Prebid as "the most widely used header bidding 'container' or 'wrapper'". It is open source and free to implement.
Is client-side or server-side header bidding better?
Neither is better everywhere. Client-side keeps user matching intact but every bidder adds browser work. Server-side moves the auction off the device and supports far more partners, but IDs must be synced under the server's domain, so some matching is lost. Apps and AMP leave no choice — server-side is required.
Does header bidding slow down a page?
It adds a deliberate wait. Prebid.org states that the publisher "creates a short delay in their ad serving to obtain bids", and that this can cost impressions from people who leave quickly. The timeout caps how long that wait can run. Specific millisecond figures in circulation are vendor-published.
Can an advertiser use header bidding directly?
No. It is run by the publisher, and the advertiser's side of it is the bid your DSP submits. What a buyer controls is which paths to that inventory you buy through, how you cap frequency across them, and whether you check ads.txt before spending.
Paths, caps and spend you can account for
We plan and run open-exchange, display and video buys with path-level reporting as a condition, not an extra.
Related guides
Make Digital Hangover a preferred source
One tap tells Google to show more of our SEO and marketing coverage in your Top Stories.