Header bidding explained in plain English

28 October 2026, 4 min read

Many website owners and media buyers hear the words header bidding but are not sure what they mean. In simple terms, it lets several buyers bid for the same ad slot at the same moment, instead of being asked one by one. This article explains how it works, what it changes, and which trade-offs you should know about.

The old way: one buyer at a time

Before header bidding became common, many publishers used a method called the waterfall. The ad server is the system that decides which ad to show. In a waterfall, it asks one demand source first. That source has a price set in advance. If it does not fill the slot at that price, the ad server moves to the next source, then the next one.

Imagine a shop with a line of customers. You ask the first person if they will pay 2 dollars for a ticket. If the answer is no, you ask the second person, and so on. The first person who says yes wins, even if the fifth person would have paid more. This is the main weakness of the waterfall: the buyer who values the slot most may never get a chance to bid.

How header bidding works

Header bidding changes the order of events. The name comes from the header of a web page. This is the top section of code that loads before the visible content. A small piece of code placed there asks many buyers for a bid at the same time. Each buyer must answer within a short time limit. For example, imagine the limit is a fraction of a second.

The code collects the answers and keeps the highest bid. It then passes that bid to the ad server. The ad server compares it with other demand, such as direct deals the publisher has agreed with advertisers. The best eligible ad is shown. The publisher sets the rules: which buyers can take part, how long to wait, and the lowest price allowed.

• The page starts to load and the header code runs.
• The code sends a bid request to each connected buyer.
• Each buyer replies with a price and an ad, or with no bid.
• When time is up, the code stops the auction and keeps the highest bid.
• The ad server compares that bid with its other options and shows the winner.

The tools behind it

Most publishers do not build header bidding from nothing. Prebid is a well-known open-source project for this job. Open source means the code is public and many people can review and improve it. Prebid.js is its JavaScript library that runs in the visitor's browser. It gives publishers one common way to connect many buyers, so they do not need separate code for each one.

The requests and answers often follow OpenRTB. OpenRTB is an open standard (RTB means real-time bidding) that describes what a bid request and a bid response should contain. When many systems share the same format, they can talk to each other more easily and with fewer mistakes.

Browser or server: two ways to run it

In client-side header bidding, the auction runs in the visitor's browser. It is a common way to start, and it is easy to see what is happening. The downside is that the browser must send many requests. On a slow phone or a weak mobile connection, this can make the page feel heavy.

In server-side header bidding, the browser sends one request to a server. The server then asks the buyers for bids. Prebid Server is the open-source software made for this. The browser has less work to do. However, matching a visitor between different systems can be harder, and some buyers may bid lower when they know less about the visitor. Running a server also takes setup and care. Many publishers use a mix of both methods and test what suits their audience.

Trade-offs to weigh

Header bidding is not magic, and it does not promise higher earnings. More competition can lift prices when buyers value your audience. But the result depends on your content, your visitors, buyer demand and how well the setup is done. It also brings costs that you should look at honestly.

• Page speed: waiting for bids can delay ads and move content around. Web Vitals are measures of loading, response and visual stability. Keep the time limit short and reserve space for each ad so the page does not jump.
• Complexity: more partners mean more setup, testing and reports to read.
• Repeated requests: a buyer may see the same ad slot through several routes. This can confuse reports and make buyers bid against themselves.
• Ad experience: a slow or heavy ad can annoy visitors, so watch quality as well as price.

What to check before you start

Publishers should begin small. Send a part of your traffic through the new setup and keep the rest unchanged. Compare both groups over the same period. Look at page speed and visitor behaviour next to revenue, not only at the price you earn.

Advertisers and media buyers can ask simple questions too. Where will my ad appear? Do I reach the same slot through more than one route? Is the path from my bid to the page clear? Shorter, cleaner paths usually make results easier to understand and to improve.

• Pick a small set of buyers first and add more later.
• Set a short, tested time limit for bids.
• Reserve ad space in the page layout.
• Review reports on a regular schedule.
• Remove partners that add delay but little value.

Wrap-up

Header bidding gives several buyers a fair chance to compete, but it needs careful setup and a watchful eye on page speed. If you are a publisher, write down your current page speed and ad income, then test one small change at a time. If you are a buyer, ask your partners how your ads reach each slot.

Prepared by the DIGIWEBS team with the help of AI writing tools. General information only, not legal, tax or financial advice. Images by DIGIWEBS Media.