What Is Header Bidding? Client-Side, Server-Side, Prebid

What is header bidding?

Header bidding is a way for a website to ask several ad exchanges and SSPs for a bid on each ad slot at the same time, before the page calls its ad server. The bids are passed to the ad server, which compares them with its own demand and direct deals and serves the highest-paying ad. The open-source project Prebid describes the model simply: it “collects bids before the ad server is called, and the ad server makes the final decision.”

The name comes from where the code first ran, in the <head> of a web page. Prebid’s introduction to header bidding notes that the term is outdated now that it also runs on servers and in apps, and suggests “pre-ad server bidding” as more accurate.

Why header bidding exists: the waterfall problem

Before header bidding, a publisher’s ad server usually offered an impression to demand sources one at a time, in a fixed order based on what each had paid on average in the past. If the first partner passed, the request moved to the next one, and so on down the list. This is called a waterfall or daisy chain.

The waterfall has two weaknesses. A partner low in the list might have paid more for this particular visitor but never got asked. And each step down the list adds a delay. Header bidding fixes both by asking all partners at once and letting their real bids for this impression compete. The same shift happened in mobile apps, where it is called in-app bidding; In-app bidding vs waterfall covers the app side.

How header bidding works, step by step

1. The page loads the header bidding library and its list of ad slots and bidders.
2. The library sends bid requests to every bidder at once. Each bidder is usually an SSP or exchange, which may run its own auction among its buyers. What is an ad exchange? explains that auction.
3. Bids come back within a timeout. Prebid’s overview says any bidder “not returning a result within the timeout duration is excluded from the auction.”
4. The best bids are passed to the ad server as key-values on the ad request. Prebid’s introduction explains that the ad server then “will look for line items matching the key values in those bids”, so someone has to set up those line items.
5. The ad server picks the final winner among header bids, its own exchange demand and any direct campaigns, and the winning ad renders.

Prebid can also make the decision itself without an ad server, but most publishers who use header bidding pair it with one.

Client-side vs server-side header bidding

The main design choice is where the auction runs.

Client-side

The visitor’s browser sends a request to each bidder directly and collects the answers. Bidders can read their own cookies and IDs, which helps them recognize users and bid. The cost is work in the browser: more scripts to download, more network requests, and more JavaScript running while the page loads.

Server-side

The browser sends one request to a server, which calls the bidders and returns the results. Prebid’s Prebid Server overview calls it “an open-source solution for server-to-server header bidding” with more than 230 server-side bid adapters (checked on November 4, 2026). Prebid’s overview says publishers move auctions server-side to “lighten the load that header bidding has on the browser”, and that server-side is required where there is no web page head at all, such as mobile apps and AMP pages.

The trade-off is identity. Bidders’ cookies belong to their own domains, not to the server running the auction, so Prebid Server has to collect bidders’ user IDs through a process called cookie syncing and pass them on. When an ID is missing, a buyer may not recognize the user.

Many publishers run a hybrid: their best-paying bidders client-side and the rest server-side.

Prebid.js, Prebid Server and Prebid Mobile

Prebid is the best-known open-source header bidding project. According to Prebid’s overview page, it is “free and fully open source”, run by Prebid.org, a membership organization of ad tech companies funded by member dues, and its ecosystem supports more than 300 demand partners, which Prebid calls the largest repository of working header bidding adapters (checked on November 4, 2026). It has three main products:

• Prebid.js, a JavaScript library that runs in the browser and is the core of the suite. It supports display, video and native formats.
• Prebid Server, the server-side version, available in Go and Java. Prebid’s own docs warn that installing it “is not nearly as easy as Prebid.js”, and Prebid.org members offer hosted versions.
• Prebid Mobile, an SDK for iOS and Android apps that sends requests to Prebid Server.

The Prebid.js download page lets you build a file with only the bidder adapters and modules you select. Build it with the partners you actually use, not with every adapter. Timeouts are set with the bidderTimeout setting; Prebid’s documentation shows 3000 ms as an example value, not as a recommendation, so test what your pages can afford.

What a header bidding wrapper is

A wrapper is the code that manages header bidding for you: it loads the bidders, sends requests in parallel, enforces the timeout, and passes the results to the ad server. Prebid.js is itself a wrapper, and many SSPs and ad management companies offer their own wrappers or managed Prebid setups, with a dashboard, analytics and managed setup.

When you compare wrappers, ask:

• Can you add and remove bidders yourself, or only through the vendor?
• Do you see each bidder’s bid rate, win rate, response time and timeouts?
• Who owns the ad server setup and the line items?
• Does the vendor take a share of revenue, and is it on top of the SSPs’ own fees?
• Which lines does it require in your ads.txt? What is programmatic advertising? explains the file.

Google offers a server-side alternative inside its own ad server. Google’s Ad Manager help page on Open Bidding describes a “server-to-server” integration in which third-party demand partners bid in real time in one auction alongside Ad Manager line items and Ad Exchange, with net bids that take Ad Manager’s revenue share into account.

How header bidding affects page speed

Header bidding holds back the ad call while bidders answer. Prebid’s introduction says plainly that the ad calls on the page “will be delayed for a set period of time.” Done badly, it adds heavy scripts, blocks rendering, and makes the page jump when ads load. Done well, the content loads first and ads fill in without moving anything.

• Load the wrapper and ad tags asynchronously so the page content never waits for them.
• Set a firm timeout and look at which bidders regularly miss it.
• Reserve space for every ad slot. Google’s Publisher Tag guide on layout shift says “the only guaranteed way to avoid layout shift is to reserve a sufficient amount of space for a given ad slot using CSS.”
• Cut bidders that rarely win. Each one adds requests and code for little revenue.
• Lazy-load slots below the fold so their auctions run when the reader gets close, not on page load.
• Move long-tail bidders server-side if you want more demand without more browser work.

Performance and revenue are not opposites. In a web.dev case study, the German publisher Netzwelt reported that third-party JavaScript for advertising and header bidding was behind poor input delay; after it cut ad scripts and providers and loaded them with async or defer, it reported 18% higher advertising revenue. That is one publisher’s result, not a benchmark.

When should a small site care about header bidding?

Header bidding pays off when there is enough traffic for extra competition to matter and someone to look after it. Running Prebid yourself means choosing bidders, getting approved by each SSP, setting up ad server line items, maintaining ads.txt, and watching timeouts and discrepancies every month.

• Starting out or small: one network such as AdSense, or a managed partner that runs header bidding for you, is usually the better use of your time. How to monetize a website and Best ad networks for publishers cover the options.
• Growing, with steady traffic: compare managed wrappers, and judge them on revenue per 1,000 sessions, page speed and transparency, not on promised uplifts.
• Large or technical: running Prebid.js with your own ad server, and Prebid Server for long-tail bidders, gives the most control.

Where an offerwall fits next to header bidding

Header bidding sells impressions. An offerwall sells nothing per impression: it is a non-programmatic, pay-per-result format where users choose offers, such as trying an app or answering a survey, to earn your site’s own points or coins, and you earn when the advertiser confirms the action. It has no bidders, no timeout and no ad server line items, and it lives on its own page or screen, so it adds nothing to your article pages’ load time. It only fits sites with logged-in users and a points or coin system; for a blog with anonymous readers, header bidding or a network is the right tool. What is an offerwall? explains the model.

Frequently asked questions