By TGM Team · Sun Oct 18 2026 · 8 min read
...
Prebid is the open-source framework most publishers use to run header bidding. It comes in two main forms: Prebid.js, which runs the auction in the reader's browser, and Prebid Server, which runs it on a server. They are less rivals than two halves of the same toolkit, and most mature setups use both.
So the real question is not which one is better. It is which demand should run where, for which inventory, and who will maintain it. This guide explains how each works, how they combine, and the practical decisions behind a Prebid implementation.
Prebid is a set of open-source projects maintained by an industry community and governed through Prebid.org. Its purpose is to give publishers a neutral, transparent way to run header bidding without depending on a single vendor's code.
The framework works through adapters. Each demand partner maintains a bidder adapter that translates Prebid's standard request into that partner's format and translates the response back. Because the core is shared and the adapters are modular, a publisher can add or remove partners without rebuilding the auction.
Prebid.js is a JavaScript library that runs on the page. It sends bid requests to each configured partner, collects responses within a timeout and passes the results to the ad server, typically as key-value pairs that line items can target.
Publishers build a package containing only the modules they need. The main types are:
That flexibility is Prebid.js's strength and its maintenance burden. Every module added is code the page has to load, and someone has to keep it current as partners update their adapters.
Prebid Server is a server-side auction engine, with open-source implementations that publishers or their partners host. Instead of the page calling each partner, one request goes to Prebid Server, which calls the partners and returns the results.
This takes processing off the reader's device, so more partners can compete without slowing the page. Prebid Server also powers environments where Prebid.js cannot run. Prebid Mobile SDKs route app auctions through it, and it is the natural route for connected TV and long-form video, where there is no web page at all.
A Prebid wrapper is the configured package that manages the auction on a page: the bidder adapters, timeout settings, price rules and ad server connection.
Publishers can build their own wrapper from Prebid.js or use a managed wrapper from a partner. The terms "Prebid wrapper" and "header bidding wrapper" are often used interchangeably, and "Prebid wrapper vs header bidding" is really a comparison between a tool and the method it runs.
Prebid.js can hand selected partners to Prebid Server through its server-to-server configuration. The page still runs Prebid.js, but some partners are called from the browser and others from the server, in the same auction.
That makes the choice a dial, not a switch. Publishers can move one partner at a time, measure the effect on revenue and page speed, and keep the partners that depend on browser identity on the client.
1. Partner Reliance on Its Own Cookies or IDs
- Lean towards Prebid.js: When demand partners rely on browser-accessible cookies or identifiers and need to access them directly to support user matching.
- Lean towards Prebid Server: When reliable ID syncing and server-side identity integrations are available to support user matching across demand partners.
2. Page Speed Is Under Pressure
- Lean towards Prebid.js: When page performance can accommodate additional browser-side processing and network requests.
- Lean towards Prebid Server: When reducing browser workload is a priority, as moving parts of the auction process to a server can reduce client-side processing.
3. Many Long-Tail Demand Partners
- Lean towards Prebid.js: When the number of demand partners is manageable and direct browser-level visibility into their bidding activity is important.
- Lean towards Prebid Server: When working with many long-tail demand partners and seeking to reduce the browser-side overhead associated with running auctions across numerous partners.
4. App or CTV Inventory
- Lean towards Prebid.js: Not generally applicable to environments that lack a compatible browser-based integration. Its suitability depends on the app or CTV platform and available implementation.
- Lean towards Prebid Server: When monetising app or connected TV (CTV) inventory through server-side integrations that support the relevant environment.
5. Need for Direct Per-Partner Debugging
- Lean towards Prebid.js: When direct inspection of browser-level bid requests and responses is important for debugging individual demand partners.
- Lean towards Prebid Server: When server-side logging and reporting provide sufficient visibility into individual partners' bid requests, responses, errors, and timeouts.
Two checks matter after any move. First, compare the partner's bid rate and win rate before and after; some bid less without direct browser access. Second, confirm user syncing is configured, or match rates fall quietly and revenue follows.
Prebid Server has to run somewhere, and the hosting choice shapes cost and control.
Self-Hosted vs. Partner-Hosted vs. Managed Service: 3 Deployment Options
1. Self-Hosted
2. Partner-Hosted
3. Managed Service
Self-hosting brings server costs and operational responsibility, but gives full control over routing, timeouts and logging. A hosted option is faster to start but means less direct control. The right choice depends on traffic volume, engineering capacity and how much the business needs to own its auction logic.
Prebid supports video formats, with video ad requests returning VAST responses that a player can render. For instream video on the web, Prebid.js can run alongside the video player; for outstream, a renderer displays the ad outside a content player.
For connected TV and long-form video, the auction usually runs through Prebid Server, often alongside server-side ad insertion. The bid request needs to describe the ad break, the content and the device accurately, because buyers have far fewer signals on a TV screen than in a browser.
b
A Prebid implementation is not a one-off project. Partners update their adapters, Prebid releases new versions, privacy rules change, and browsers change what scripts are allowed to do. A setup that performed well at launch can drift without anyone noticing.
A simple routine prevents most of that drift:
Review partner performance monthly. Look at win rate, timeout rate and net revenue for each partner, and question any that has declined for several months in a row.
Plan version updates. Schedule Prebid upgrades rather than waiting for something to break, and test each upgrade on a share of traffic first.
Re-check consent handling after changes. Any update to consent tools or Prebid modules should be followed by a check that privacy signals still reach every partner.
Keep configuration under version control. Knowing exactly what changed, and when, makes a revenue drop far faster to trace.
The publishers that get the most from Prebid tend to treat it as an ongoing product with a named owner, not as code that was installed once.
TGM's Prebid Adapter work covers custom client-side and server-side adapters, built to connect publishers to DSPs, SSPs and private marketplaces across web, CTV and OTT. For publishers whose inventory spans formats, that means one Prebid strategy rather than separate setups for each environment.
For teams planning a migration, the useful first step is a partner-by-partner view of bid rate, win rate and timeouts, so each move can be judged on evidence. TGM's publisher team can help plan a Prebid setup or migration around that baseline.
Q1. What is the difference between Prebid.js and Prebid Server?
Prebid.js runs header bidding auctions in the browser. Prebid Server runs them on a server, which reduces load on the device and supports app and CTV inventory.
Q2. Can I run Prebid Server without Prebid.js?
Yes. App and CTV setups typically call Prebid Server directly, through Prebid Mobile SDKs or a server integration.
Q3. Does Prebid Server always lower latency?
It lowers the work done on the device. Total auction time still depends on server location, partner response times and timeout settings.
Q4. What is a Prebid adapter?
A bidder adapter is the module that connects one demand partner to Prebid, translating Prebid's standard request and the partner's response.
Q5. Is Prebid free to use?
The software is open source. Hosting, engineering time and maintenance are real costs.
Q6. How often should Prebid be updated?
There is no fixed schedule. Regular, planned upgrades tested on a share of traffic are safer than infrequent jumps across several versions at once.
Q7. Can TGM build a custom Prebid adapter for my stack?
Yes. TGM offers custom client-side and server-side Prebid adapter solutions for web, CTV and OTT inventory.
