Prebid.js vs. Prebid Server: What's the Difference?
The Aditude Team
Prebid.js runs in the user's browser and orchestrates header bidding client-side; Prebid Server runs on a server and handles the auction off-browser, returning consolidated results to the page or app. Both are open-source projects maintained by Prebid.org, and both connect publishers to programmatic demand — but where the auction happens changes everything about latency, scale, and implementation complexity.
The Core Distinction: Where the Auction Lives
Every header bidding auction involves the same basic logic: send bid requests to demand partners, collect responses, pick a winner, pass it to the ad server. The question is where that logic executes.
Prebid.js executes in the browser. The JavaScript wrapper loads on your page, calls each configured demand partner directly from the user's device, collects bids, and hands winners to Google Ad Manager or your ad server of choice. The user's browser is doing the work.
Prebid Server executes on a server. Your page or app makes one request to a server endpoint; the server fans out to all demand partners in parallel, collects responses, and returns the consolidated results. The browser just waits for the answer.
Everything else — latency profiles, mobile support, cookie handling, operational overhead — follows from this single architectural distinction.
Prebid.js: How It Works and Where It Shines
Prebid.js is the most widely deployed header bidding solution in digital advertising. It's JavaScript, loaded on the page, giving publishers direct control over their auction configuration through a well-documented wrapper.
When the page loads, the wrapper fires simultaneously to all configured SSP adapters. Each adapter makes a real-time bid request to its respective demand partner. Responses that come back within the configured timeout window are collected; the highest bid wins and is sent to the ad server as a key-value pair. The ad server compares this against direct campaigns and serves accordingly.
Prebid.js works well for web publishers with standard desktop and mobile web inventory, teams without dedicated server infrastructure to maintain, and publishers with a manageable number of demand partners — typically under 15–20. It also suits teams who want direct control of adapter configuration and auction logic without an additional operational layer.
The honest tradeoff: each demand partner you add means another JavaScript file loaded on the page and another network call from the user's device. At 10 partners this is manageable; at 25 it starts to affect page performance measurably. There's also a ceiling on timeout — the longer you wait for bids, the more latency you add to page load. Prebid.js requires you to constantly balance auction completeness against user experience.
Prebid Server: How It Works and Where It Shines
Prebid Server is the server-side counterpart — same open-source project, different execution environment. It's available in Go and Java implementations, both maintained by the Prebid.org community.
The page or app sends a single request to a Prebid Server endpoint. That server holds configured bid adapters and fires requests to all demand partners in parallel, off the user's device. Responses are collected server-side, assembled into a single payload, and returned to the page. On web, Prebid.js can receive these results via its S2S module and merge them with any remaining client-side bids.
Prebid Server is the right fit for mobile apps (where there's no browser and no Prebid.js), AMP pages (which don't support arbitrary JavaScript), CTV and streaming environments, and web publishers with large demand partner counts where client-side latency has become a problem.
The honest tradeoff: Prebid Server requires infrastructure — either self-hosted or managed. The open-source codebase is free, but running it reliably at scale means provisioning servers, keeping the software current, monitoring uptime, and handling incidents. Cookie syncing is also more complex server-side, covered below.
Head-to-Head Comparison
Prebid.js | Prebid Server | |
Where it runs | User's browser | Server infrastructure |
Primary use case | Web (desktop + mobile web) | Mobile apps, AMP, CTV, high-scale web |
Setup complexity | Moderate (JS configuration) | Higher (server infrastructure required) |
Infrastructure cost | None (runs on client) | Yes (self-hosted or managed service) |
Latency impact on browser | Adds load per bidder | Minimal — one request to server |
Demand partner scale | Practical ceiling ~15–25 | Scales more easily |
Cookie/identity syncing | Standard browser cookie sync | More complex; requires dedicated user sync infrastructure |
Mobile app support | No | Yes |
AMP support | No | Yes |
CTV support | No | Yes |
Maintenance burden | SDK/adapter updates | Server ops + adapter updates |
Open source | Yes (Prebid.org) | Yes (Prebid.org) |
The Cookie Sync Problem on Server-Side
Client-side Prebid.js syncs user IDs naturally — the browser executes sync pixels and stores cookies. Demand partners can match their user IDs to your inventory, which improves bid rates and eCPMs because buyers know who they're reaching.
Server-side, this gets harder. When Prebid Server makes bid requests on behalf of the user, it doesn't automatically carry the user's browser cookies to each demand partner. User sync has to be handled explicitly — either by running sync endpoints through the server or by maintaining a separate client-side sync mechanism.
This doesn't make Prebid Server worse, but it's a real operational consideration. Poorly handled user sync is one of the most common reasons publishers see lower-than-expected eCPMs after migrating to server-side.
For more on how Prebid Server works under the hood, see: What Is Prebid Server and How Does It Work?
When to Use Each
Use Prebid.js when your inventory is primarily web-based, you want a straightforward setup without server infrastructure, your demand partner count is manageable, and your ad ops team is comfortable with JS wrapper configuration.
Use Prebid Server when you're monetizing a mobile app, when you have AMP or CTV inventory, when you have 20+ demand partners and client-side latency is a concern, or when you want to keep auction logic off the page.
Use both when you have a mix of web and mobile inventory, when you want server-side scale without giving up the orchestration flexibility of Prebid.js, or when you're running a hybrid auction where some partners are called client-side and others server-side.
The Hybrid Setup: Getting the Best of Both
The most common production setup for large web publishers isn't Prebid.js or Prebid Server — it's both.
Prebid.js stays on the page as the orchestration layer, handling the ad server integration and any demand partners you want to keep client-side. Its S2S module connects to Prebid Server for partners that benefit from server-side execution — typically the high-latency ones, or any partners you've added beyond what the browser handles well.
Results from both paths are collected by Prebid.js, merged, and the winner is sent to the ad server in the standard way. From the ad server's perspective, nothing has changed.
This hybrid approach is how many publishers scale their demand partner count without degrading page performance. It's also what Aditude's Cloud Wrapper is designed to support — handling the configuration and maintenance of both layers so your team isn't managing two separate systems.
The Short Answer
Prebid.js is a client-side JavaScript wrapper — widely deployed, straightforward to set up, runs in the browser. Prebid Server is a server-side auction platform — better for mobile, AMP, and high-scale web, but requires infrastructure to operate. They're complementary rather than competing, and many publishers run both.
The right choice depends on your inventory mix, your demand partner count, and how much operational complexity your team can absorb.
Run Prebid Server without the infrastructure headache —see how Aditude handles it →
Prebid.js runs in the user's browser and orchestrates header bidding client-side; Prebid Server runs on a server and handles the auction off-browser, returning consolidated results to the page or app. Both are open-source projects maintained by Prebid.org, and both connect publishers to programmatic demand — but where the auction happens changes everything about latency, scale, and implementation complexity.
The Core Distinction: Where the Auction Lives
Every header bidding auction involves the same basic logic: send bid requests to demand partners, collect responses, pick a winner, pass it to the ad server. The question is where that logic executes.
Prebid.js executes in the browser. The JavaScript wrapper loads on your page, calls each configured demand partner directly from the user's device, collects bids, and hands winners to Google Ad Manager or your ad server of choice. The user's browser is doing the work.
Prebid Server executes on a server. Your page or app makes one request to a server endpoint; the server fans out to all demand partners in parallel, collects responses, and returns the consolidated results. The browser just waits for the answer.
Everything else — latency profiles, mobile support, cookie handling, operational overhead — follows from this single architectural distinction.
Prebid.js: How It Works and Where It Shines
Prebid.js is the most widely deployed header bidding solution in digital advertising. It's JavaScript, loaded on the page, giving publishers direct control over their auction configuration through a well-documented wrapper.
When the page loads, the wrapper fires simultaneously to all configured SSP adapters. Each adapter makes a real-time bid request to its respective demand partner. Responses that come back within the configured timeout window are collected; the highest bid wins and is sent to the ad server as a key-value pair. The ad server compares this against direct campaigns and serves accordingly.
Prebid.js works well for web publishers with standard desktop and mobile web inventory, teams without dedicated server infrastructure to maintain, and publishers with a manageable number of demand partners — typically under 15–20. It also suits teams who want direct control of adapter configuration and auction logic without an additional operational layer.
The honest tradeoff: each demand partner you add means another JavaScript file loaded on the page and another network call from the user's device. At 10 partners this is manageable; at 25 it starts to affect page performance measurably. There's also a ceiling on timeout — the longer you wait for bids, the more latency you add to page load. Prebid.js requires you to constantly balance auction completeness against user experience.
Prebid Server: How It Works and Where It Shines
Prebid Server is the server-side counterpart — same open-source project, different execution environment. It's available in Go and Java implementations, both maintained by the Prebid.org community.
The page or app sends a single request to a Prebid Server endpoint. That server holds configured bid adapters and fires requests to all demand partners in parallel, off the user's device. Responses are collected server-side, assembled into a single payload, and returned to the page. On web, Prebid.js can receive these results via its S2S module and merge them with any remaining client-side bids.
Prebid Server is the right fit for mobile apps (where there's no browser and no Prebid.js), AMP pages (which don't support arbitrary JavaScript), CTV and streaming environments, and web publishers with large demand partner counts where client-side latency has become a problem.
The honest tradeoff: Prebid Server requires infrastructure — either self-hosted or managed. The open-source codebase is free, but running it reliably at scale means provisioning servers, keeping the software current, monitoring uptime, and handling incidents. Cookie syncing is also more complex server-side, covered below.
Head-to-Head Comparison
Prebid.js | Prebid Server | |
Where it runs | User's browser | Server infrastructure |
Primary use case | Web (desktop + mobile web) | Mobile apps, AMP, CTV, high-scale web |
Setup complexity | Moderate (JS configuration) | Higher (server infrastructure required) |
Infrastructure cost | None (runs on client) | Yes (self-hosted or managed service) |
Latency impact on browser | Adds load per bidder | Minimal — one request to server |
Demand partner scale | Practical ceiling ~15–25 | Scales more easily |
Cookie/identity syncing | Standard browser cookie sync | More complex; requires dedicated user sync infrastructure |
Mobile app support | No | Yes |
AMP support | No | Yes |
CTV support | No | Yes |
Maintenance burden | SDK/adapter updates | Server ops + adapter updates |
Open source | Yes (Prebid.org) | Yes (Prebid.org) |
The Cookie Sync Problem on Server-Side
Client-side Prebid.js syncs user IDs naturally — the browser executes sync pixels and stores cookies. Demand partners can match their user IDs to your inventory, which improves bid rates and eCPMs because buyers know who they're reaching.
Server-side, this gets harder. When Prebid Server makes bid requests on behalf of the user, it doesn't automatically carry the user's browser cookies to each demand partner. User sync has to be handled explicitly — either by running sync endpoints through the server or by maintaining a separate client-side sync mechanism.
This doesn't make Prebid Server worse, but it's a real operational consideration. Poorly handled user sync is one of the most common reasons publishers see lower-than-expected eCPMs after migrating to server-side.
For more on how Prebid Server works under the hood, see: What Is Prebid Server and How Does It Work?
When to Use Each
Use Prebid.js when your inventory is primarily web-based, you want a straightforward setup without server infrastructure, your demand partner count is manageable, and your ad ops team is comfortable with JS wrapper configuration.
Use Prebid Server when you're monetizing a mobile app, when you have AMP or CTV inventory, when you have 20+ demand partners and client-side latency is a concern, or when you want to keep auction logic off the page.
Use both when you have a mix of web and mobile inventory, when you want server-side scale without giving up the orchestration flexibility of Prebid.js, or when you're running a hybrid auction where some partners are called client-side and others server-side.
The Hybrid Setup: Getting the Best of Both
The most common production setup for large web publishers isn't Prebid.js or Prebid Server — it's both.
Prebid.js stays on the page as the orchestration layer, handling the ad server integration and any demand partners you want to keep client-side. Its S2S module connects to Prebid Server for partners that benefit from server-side execution — typically the high-latency ones, or any partners you've added beyond what the browser handles well.
Results from both paths are collected by Prebid.js, merged, and the winner is sent to the ad server in the standard way. From the ad server's perspective, nothing has changed.
This hybrid approach is how many publishers scale their demand partner count without degrading page performance. It's also what Aditude's Cloud Wrapper is designed to support — handling the configuration and maintenance of both layers so your team isn't managing two separate systems.
The Short Answer
Prebid.js is a client-side JavaScript wrapper — widely deployed, straightforward to set up, runs in the browser. Prebid Server is a server-side auction platform — better for mobile, AMP, and high-scale web, but requires infrastructure to operate. They're complementary rather than competing, and many publishers run both.
The right choice depends on your inventory mix, your demand partner count, and how much operational complexity your team can absorb.
Run Prebid Server without the infrastructure headache —see how Aditude handles it →
