TL;DR
What is header bidding: Tech that allows publishers auction inventory to multiple demand sources at once.
How it works:
- Wrapper (e.g., Prebid.js) sends bid requests.
- Multiple bids returned simultaneously.
- Highest bids passed to the ad server.
- Ad server runs final auction with direct + programmatic deals.
Types:
- Client-side → simple, cheap, but slows page load.
- Server-side → faster, scalable, but pricier.
- Hybrid → mix of both, complex to maintain.
Benefits: More demand partners, higher CPMs, transparency, optimized ad revenue.
Drawbacks: Complexity, latency, ongoing costs.
From ad blockers and harsh competition to ad fraud and data discrepancies – it seems like publishers just can’t catch a break. But “One must imagine Sisyphus happy,” and in our case, instead of embracing absurdism, publishers can find salvation in the header bidding process.
Or they can’t? The flare of novelty behind the technology has vanished, and now we can clearly look at all of the good, the bad, and the ugly related to header bidding. What exactly is it, and how does this solution fit in the ad tech ecosystem? How does it work? How expensive is it? Let’s find out!
What Header Bidding Means in Advertising?
Header bidding is a technology that allows publishers to offer ad inventory to their programmatic demand sources — SSPs, ad exchanges, and ad networks — simultaneously, before selling it directly.

Bids during the header bidding process are collected in real time, and the highest bid competes alongside deals in the ad server auction.
The result: more transparency and often higher revenue. According to Digiday, publishers observe no less than 20-50% lifts after header bidding setup. There are multiple implementation paths, client-side, server-side, or hybrid, each with its own trade-offs in complexity, latency, and control.
When Header Bidding Solution Was Invented?
“I started hearing the term ‘header’ in late 2014. We enable our SSP in the header so it can submit bids in advance of the ad call. But that was only to describe the location.” recalled Chip Schenck, VP of Programmatic at Meredith, confirming the label first emerged around then among industry insiders.
It wasn’t universally called “header bidding”, though. The lame names included “tagless integration,” “parallel auction”, and “holistic yield management” (thank God that didn’t stick).
While the terminology became common, the header bidding technology itself had no single inventor. The tech came under many masks in the early years, so it’s difficult to find its one true father. Some credit OpenX, but there’s not much proof.
Why Did Header Bidding Start & How Google Ad Manager is Involved?
What sparked this shift? Two clear catalysts:
- Publishers needed fair competition for every impression. Waterfall setups stifled yield by favoring pre-set partners over open demand.
- Google’s DFP (DoubleClick for Publishers) had a structural preference for its own AdX, limiting external SSPs. Header bidding flipped that power dynamic.
Google's DFP (now Google Ad Manager) has always been the most popular solution for said publishers. The comfort of a walled garden comes at a price. Specifically, it favored Google ad exchange, limiting external ad offers and lowering publishers’ profits.
Google later rolled out Exchange Bidding (renamed Open Bidding) to let third-party supply-side platforms bid inside Google Ad Manager. This aimed to reduce the latency problems of client-side header bidding and keep publishers inside Google’s ecosystem.
The Difference Between Header Bidding and Waterfalling
In waterfalling, publishers pass each impression through a fixed chain of partners. If a higher-paying bidder is ranked lower in that sequence, their offer may never be seen leaving money on the table.
Header bidding fixes this by letting all demand partners compete at the same time. Instead of sequential offers, every SSP, ad exchange, and network submits bids simultaneously, and the highest bid is always considered in the bidding process.

Important to note, header bidding doesn’t replace auction mechanics like first-price or second-price. Instead, it decides who enters the auction. Once bids are passed to the ad server, they’re resolved using whichever auction rule the publisher’s stack applies.
How Does a Header Bidding Auction Work?
Here’s what happens when header bidding runs behind the scenes, in the client-side header bidding case.
Step 1. Receiving multiple bids at once
The header bidding wrapper (for example, Prebid.js) fires off requests to all connected SSPs and exchanges the moment a page loads.
Step 2. Passing bids back to the ad serving platform
Each partner responds with their best offer — say SSP A at $2.50, SSP B at $3.00, and SSP C at $2.75.
Instead of picking a winner immediately, the header bidding wrapper sends these bids into the publisher’s server. Usually, the highest bid (SSP B's bid at $3.00) is passed along, but in some setups multiple bids go in to compete further.
Step 3. The unified auction
This is where it all comes together. The ad server takes the header bidding bids and compares them against everything else: direct sales, programmatic guaranteed, and ad exchange traffic.
Step 4. Applying publisher rules
It’s not always “highest CPM is the winning bid.” Publishers set prioritization rules to determine which ad to serve. These rules can include:
- A $2.80 guaranteed deal may still beat a $3.00 open bid.
- Floor prices can block low-value bids.
- Campaign line items with fixed delivery requirements can impact header bidding work as well.
5. Final ad delivery
Once the ad server makes the call, the winning creative is delivered to the user’s screen. From the outside it looks instant — but inside, dozens of bids just fought for that ad space in an auction process.

What is the Header Bidding Wrapper?
A header bidding wrapper is just a piece of JavaScript code you drop into the <head> of your site. Think of it like a traffic cop:
- It sits at the very top of your page (in the header).
- When a user loads the page, the wrapper pauses ad delivery for a moment.
- Then it shouts: “Hey SSPs, ad exchanges, and demand partners — who wants this ad space?”
- Everyone sends back their best offer.
- The wrapper collects those offers, picks the winner (or a shortlist), and hands it over to your ad server (like Epom or Google Ad Manager
Without the wrapper, you’d only be able to ask demand partners one by one (waterfalling). With it, all partners bid at the same time.
What Prebid.js Is
Prebid.js is the most common open-source header bidding wrapper. It’s just a ready-made toolkit so you don’t have to build the auction logic yourself.
- You download the code bundle (only the “adapters” you need for your chosen SSPs).p
- You plug it into your site’s header.p
- You tell it which ad sizes/units you want to sell.p
- It automatically handles the “ask for bids → collect offers → send winning bid to ad server” loop.p
So when guides say “install Prebid.js”, they literally mean: paste a script that runs this process for you.
Types of Header Bidding: Client-Side vs. Server-Side vs. Hybrid
Not all header bidding setups are created equal. The way you run the auction process — in the user's browser, on a separate server, or in a combination of both has a direct impact on page speed, ad delivery quality and ultimately, ad revenue.
In practice, publishers and ad networks usually choose between three models:
- Client-side header bidding: lightweight, transparent, but limited by browser performance.
- Server-side header bidding: scalable, faster, but often less transparent and more expensive.
- Hybrid header bidding models: a mix that balances transparency and scale.
Let's elaborate on each type of header bidding in more detail and define how your own implementation of header bidding may look like.
Client-Side Header Bidding
Client-side header bidding involves running the auction directly inside the user’s browser. When a page loads, the header bidding wrapper (e.g. Prebid.js) sends ad requests to various demand sources like SSPs, multiple ad exchanges, ad networks and publisher's direct deals at once.
Each partner responds with a bid for the available ad impression, and the header bidding wrapper passes the winning bid to the publisher's ad server.
Advantages:
- Transparency: Publishers see which partners bid, at what price, which ad space was involved and how the auction process worked.
- Control: Easy to add or remove demand sources by editing the header bidding wrapper.
- Competition: With multiple demand partners, publishers usually achieve higher ad revenue and fill rates for the same inventory.
Drawbacks:
- Latency: Every partner request adds weight to the user's browser. Too many bidders slow down page load and hurt user experience.
- Scalability issues: Larger publishers with many partners often hit browser performance limits.
According to this statistics, 39% of publishers who adopt header bidding start with client-side setups because it’s easier and cheaper to implement compared to server-side.
Server-Side Header Bidding
In simple words, instead of leaving everything to the browser, a separate server is now responsible for running header bidding auctions, solving ad requests and defining the winning bid. Server-side header bidding solution usually comes as a SaaS with its own set of analytics & reporting tools.
Advantages:
- Reduced latency: Since the user's browser isn’t overloaded with parallel ad requests, pages load faster.
- Scalability: Publishers can connect to more demand sources without harming performance.
- Advanced analytics: Many header bidding platforms (Amazon's transparent ad marketplace, Index Exchange) provide real-time reporting, audience insights, and fraud detection.
Drawbacks:
- Transparency loss: Some partners may only report aggregated results about ad impressions, so publishers see less performance metrics about bids.
- Costs: Server-side header bidding comes as a hosted external server, with tech fees or revenue share.
- Target audience matching issues: Syncing users across multiple demand sources is less accurate in a server-side setup, which may reduce efficiency.
According to the same report, only around 7% of publishers have chosen this implementation of header bidding, going completely server-side.
Hybrid Header Bidding for Publishers
Hybrid combines client-side vs. server-side setups. Some demand sources are called in the browser (for transparency and better cookie match rates), while others are routed through a server-side header setup (for scale and reduced latency).
Advantages:
- Best of both worlds: Publishers keep high match rates and transparency from client-side while scaling demand with server-side.
- Flexibility: High-value partners can remain client-side, while bulk partners move server-side to reduce strain on the browser.
- Optimization: Better balance between UX and ad revenue.
Drawbacks:
- Complex setup: Managing two auction layers increases technical overhead.
- Monitoring challenges: Harder to debug and optimize since part of the header bidding work is split across environments.
Cost & maintenance: Requires more advanced ad ops and engineering resources.
Hybrid setups are rare but often used by large publishers (news sites with massive traffic) that need both transparency and performance at scale.

What Is In-App Header Bidding?
Mobile apps don’t have a “header” section like websites, so in-app header bidding works differently. Instead of JavaScript wrappers, the auction happens through SDKs (software development kits) integrated into the app. These SDKs let multiple demand partners compete simultaneously for the same ad impression.
- Google AdMob and Meta Audience Network both provide SDK-based solutions.
- Other vendors like AppLovin MAX and ironSource have become leaders in mobile header bidding technology, helping app developers unify demand from multiple ad exchanges with less latency.
What Is the Price of Header Bidding Adoption?
“That seems quite cool, but how much do I pay for it?”
The cost of adopting header bidding varies widely. Some publishers experiment with client-side header bidding using open-source tools like Prebid.js (free), while others invest in server side header bidding setups that can run into tens of thousands of dollars per month.
Common Cost Ranges: Free vs. Managed vs. Enterprise
Implementing header bidding solutions involves a lot of variables that could change the price from “free” to “several thousand dollars a month.” These include:
Tech fees
Header bidding wrappers and libraries are free. However, managed services are not; the providers charge revenue shares.
Development & Maintenance
The in-house advertising team will cost an established hourly rate. Outsourcing isn’t cheap either. Of course, you can do everything by yourself and we’ll discuss how a bit later.
Analytics & Support
If you want a finite header bidding product worth investing in, you’ll require analytics and reporting tools. Moreover, you’ll have to opt for a server-side implementation.
The most common cost breakdown for implementing header bidding will be:
- DIY / Open Source: $0 in licensing fees (using Prebid.js), but header bidding requires in-house development hours for integration, troubleshooting, and ongoing updates.
- Header Bidding Platforms: Typically charge a revenue share or fixed monthly fee, ranging from a few hundred to a few thousand dollars.
- Enterprise / Custom: Large publishers using server side header bidding technology with premium support, analytics, and integrations can expect costs from $5k to $10k+ monthly.
As a result, the final solution usually varies from a few thousand dollars for small-scale implementations using open source to tens of thousands of dollars if you’re a large publisher.
How to Set Up Header Bidding for Free?
But wait, there is light at the end of the tunnel. If you’re ready to sacrifice a few small things, you can implement header bidding for free. For such header bidding setup, follow these steps:
- Download Prebid.js – Get the library with only the javascript code (adapters) required for your SSPs.
- Add to your site – Place the header bidding code in the <head> section of your web page.
- Configure adapters – Define ad units, bidders, and parameters for each demand partner.
- Integrate with an ad server – Set up key-value pairs so bids compete (Dynamic Allocation in GAM).
- Test, then retest – Verify ads render correctly and page load times stay acceptable.
The “broke setup” is a good way to learn new things and test if the tech is worth further investment. But, we should mention certain constraints of implementing header bidding this way. Among them are:
- No customization. Limited beyond what the header bidder wrapper/existing modules expose.
- Ready SSP support only. You’re confined to adapters the ecosystem already provides; SSP access itself isn’t free.
- No additional analytics. You won’t get managed log-level insights or dashboards unless you build them.
- Self-maintenance. You own updates, bidder changes, compliance, user ID modules to identify users, and ongoing QA.
What Are the Benefits of Header Bidding?
Header bidding enables publishers to maximize the value of each ad impression by opening their publisher's ad space to multiple demand partners at once instead of relying on sequential waterfalls. The benefits of header bidding include:
Diversified demand partners
Access to multiple third-party demand partners (SSPs, ad exchanges, networks) means more competition for each ad placement. This improves fill rates, helps secure premium ad inventory, stabilizes ad revenue, and reduces reliance on few buyers.
Transparency
The tyranny of walled garden providers is over! Just kidding. But unlike Google’s historical Dynamic Allocation or exchange bidding inside GAM, header bidding gives publishers more control over auction logic.
They can see how bids are valued and avoid black-box favoritism toward a single exchange. This transparency makes it easier to optimize yield and compare direct sales vs. programmatic.
Increased ad revenue
This is the main reason publishers adopt the tech. Industry tests show that simply adding one more demand source can lift CPMs by 5–10%. For large publishers, diversifying to 5+ partners often results in significant incremental ad revenue.
What Are the Disadvantages of Header Bidding?
Okay, now to the nasty stuff:
Tech complexity
Even with open-source wrappers, a proper header bidding setup requires dev resources. Integrating adapters, troubleshooting, and maintaining updates is ongoing work, especially when partners change specs.
Pricing
While Prebid.js is free, managed or server-side solutions are not. Vendors may charge a rev-share or flat platform fees that can run into thousands per month. Analytics, reporting, and support add to costs.
Increased latency
With browser-side header bidding, multiple parallel ad requests compete while the browser starts loading a page. This can slow down rendering and hurt UX if not optimized.
Server-side header bidding reduces page load times but can introduce “information loss” (fewer user IDs passed) that lowers bid density. Hybrid setups balance both but add monitoring complexity.
How to Set Up Header Bidding?
At its core, the whole process works thanks to a pre-bidding adapter based on an open-source Javascript library. We’re simplifying things a bit, but that’s how you basically use it as a service:
Step #1
Your vendor company that positions itself as an SSP or ad exchange (Epom Ad Exchange, Index Exchange, etc.) provides you with a JS code. This code is a wrapper (framework, container) that you put in the <head> section of your website.
Step #2
Check to see if your ad tech demand partners (ad exchanges, DSPs connected to your SSPs, or ad networks) support the pre-bid adapter. It’s easy to do:
go here.
Step #3
When all of the conditions are met, your demand partners will be able to place their bids on your inventory.

Epom Ad Server & Header Bidding Implementation
Epom Ad Server can be your choice for header bidding, integrating seamlessly with Prebid.js or allowing for a server-side setup.
Bids collected in real time are passed into the Epom ad server as key-value pairs, where they compete fairly alongside direct sales and programmatic deals.
This combination gives publishers more yield, higher transparency, and better yield from premium ad inventory, without locking into Google’s walled garden.
Epom setup is simpler than most enterprise alternatives, making it a practical option for ad networks and publishers looking to maximize ad revenue through programmatic header bidding.
Header Bidding FAQ:
-
How does header bidding work?
A wrapper (like Prebid) requests bids from multiple demand partners at once, then passes the top bids to the ad server, which runs the final auction.
-
Header bidding vs. Open Bidding (Google): what’s the difference?
Header bidding happens outside Google’s stack (client or server side), giving publishers more transparency and control. Open Bidding runs inside GAM, simplifying setup but keeping control with Google.
-
Header bidding vs. RTB: what’s the difference?
RTB is the auction protocol that determines a winning bid in real time. Header bidding is a supply tactic that uses RTB to invite more bidders before the auction.
-
Is header bidding worth it for small publishers?
Yes, if you want higher CPMs and fill rates, but it requires setup and monitoring. Small publishers often start with client-side Prebid to test the waters before investing in server-side solutions.
-
How many demand partners should I run?
Client-side setups usually perform best with 5–8 high-quality partners. Server-side or hybrid setups can scale higher, but too many low-performing bidders may increase latency without adding revenue.
Try Epom and see how fair auctions can drive your revenue higher.
Unlock free trial