What is header bidding? It is a programmatic technique that lets multiple ad exchanges and supply-side platforms bid on a publisher's ad slot at the same time, before the page's ad server is even called. Every demand source competes in one simultaneous auction, and the highest bid wins. It replaced the old "waterfall," where buyers were offered inventory one at a time in a fixed order, and it raised publisher revenue by making every impression genuinely competitive.
That is the whole idea. The rest of this page is the how and the why, in plain English, because most explanations of this drown a simple concept in acronyms.
What is header bidding, and why does it exist at all?
Before header bidding, publishers sold inventory through a waterfall (also called a daisy chain). The ad server offered each impression to demand partners in a ranked sequence: partner one gets first look, and if they pass or do not meet the floor price, the impression cascades down to partner two, then three, and so on.
The problem is obvious once you say it out loud. The order was fixed, usually based on each partner's historical average price, not what they would pay for this specific impression right now. So a buyer sitting fourth in line might have paid the most for a particular user, but they never got the chance to bid because someone above them filled the slot first. Publishers left money on the table on basically every impression.
Header bidding fixes that by collapsing the sequence into a single moment. Instead of asking buyers one at a time, the publisher asks all of them at once, lets them bid simultaneously, and sends the winning bid into the ad server as a competitive number. The name comes from where the code originally lived: in the <head> of the page, firing before the rest of the ad stack loaded.
How header bidding works
Here is the sequence, step by step:
- The page starts loading. A piece of code (the header bidding "wrapper") fires early, before the publisher's primary ad server is called.
- All demand partners are asked at once. The wrapper sends a simultaneous bid request to every connected supply-side platform and ad exchange.
- They bid in real time. Each exchange runs its own real-time bidding auction and returns a price for that exact impression and user.
- The wrapper picks the highest bid. It collects every response, identifies the winner, and passes that bid into the ad server as a key-value pair.
- The ad server makes the final call. The header bidding winner now competes against the publisher's direct-sold deals and any other demand. Whatever pays most, serves.
The catch hiding inside step 2 is time. The whole auction has to finish before the page can render its ads, so the wrapper enforces a timeout (commonly a few hundred milliseconds). Any bidder that does not respond in time is dropped from the auction entirely. That is the central tension of header bidding: more demand partners means more competition and higher bids, but every partner you add is another response the wrapper has to wait for. Push the timeout too long and you slow the page; cut it too short and you leave good bids on the table. Tuning that window is most of the ongoing work.
The wrapper is the orchestration layer that makes all of this possible, and in practice one wrapper dominates the market: Prebid.js, the open-source framework. Most publishers running header bidding are running Prebid or something built on top of it. When you hear "prebid," that is what people mean.
Client-side vs server-side header bidding
There are two places the auction can run, and the difference matters because it is a tradeoff, not an upgrade path.
| Client-side | Server-side | |
|---|---|---|
| Where the auction runs | In the user's browser | On an external server |
| Latency | Higher (browser makes many calls) | Lower (one call to a server that fans out) |
| Number of partners you can add | Limited by page speed | Many more, since the browser only makes one request |
| User-matching / cookie data | Strong (rich browser cookies) | Weaker (cookie matching is harder server-side) |
| Transparency into the auction | High | Lower |
Client-side puts the auction in the browser. It carries richer user data (the browser has the cookies), which buyers like, and it gives publishers clean visibility into who bid what. The cost is speed: every demand partner is another call the browser has to make while the page is trying to load, so adding partners eventually drags down page performance and, with it, viewability and user experience.
Server-side moves the auction off the browser and onto a server. The browser makes one request, the server calls all the demand partners, and results come back fast. That lets a publisher connect to far more partners without wrecking page speed. The tradeoff is weaker user-identity matching (the server cannot read the browser's cookies as cleanly, so buyers see fewer matched users) and less visibility into the auction, since the bidding happens somewhere you cannot watch directly.
Most sophisticated publishers run a hybrid: a handful of high-value partners client-side for the data quality, the long tail server-side for scale and speed. There is no universally "correct" setup. The right split depends on the publisher's audience, page-speed budget, and which partners pay enough to justify the cookies they consume. That is exactly the kind of detail that gets glossed over when this is explained badly.
Does header bidding help the buyer, or just the publisher?
Header bidding is a sell-side technique, so the headline benefit is the publisher's: more competition per impression means higher yield. Industry sources commonly report revenue lifts in the rough range of 20 to 40 percent versus a waterfall-only setup, though the real number depends entirely on the publisher, the inventory, and how many quality demand partners are connected. Treat any single figure as directional, not gospel.
But buyers benefit too, in a less obvious way. In the old waterfall, a buyer's bid could simply never be seen if a lower-value partner sat above them in the chain. Header bidding gives every connected buyer a fair, simultaneous shot at every impression, so a buyer who genuinely values a specific audience can win it on the merits instead of losing to queue position. More transparent competition is generally good for the side that is willing to pay for the right user. The flip side: it also means there is nowhere to hide, so your bidding strategy and creative have to earn the win. This is one reason programmatic and Google Ads behave differently: in open programmatic, what you pay is set by a live auction against everyone else who wanted that same impression.
Where this sits in the programmatic stack
Header bidding is one piece of a larger machine. It is the auction mechanism on the publisher's side. The pipes it runs through are ad exchanges, the publisher-side software is the supply-side platform, and the pricing engine inside every exchange is real-time bidding. On the buy side, you reach these auctions through a demand-side platform, and premium publishers often wall off their best inventory in a private marketplace rather than the open auction.
If you are buying media, you do not configure header bidding yourself (publishers do), but understanding it tells you why the same impression can cost very different amounts depending on how many buyers were allowed to compete for it. For the full picture of how these pieces fit together, our guide to programmatic advertising walks the whole supply chain end to end.
Want this run for you, not just explained?
Header bidding is the publisher's lever. Knowing how it works is the buyer's edge. We run programmatic advertising for businesses that want senior people pulling the levers, plain-English reporting on where the money goes, and no markup games hidden inside the supply chain. If you are weighing budget first, our programmatic pricing lays out what it costs. Or get in touch and we will tell you straight whether it is the right channel for you. No pressure and no jargon, just the real picture.
Part of the MoonSauce ad-tech glossary. We explain the work as we do it.
