Prebid.js ships every bidder adapter by default, and trimming the bundle is the publisher's job

What the library is for, and who it is not for

Prebid.js is a free and open source library for publishers to quickly implement header bidding, and the project description expands it as setting up and managing header bidding advertising partners without writing code or confusing line items.

The mechanism is that a publisher loads one library, the library runs an auction across several demand sources at once, and the winning bid is sent to the server as a single ad request. The publisher sees one line item rather than a set of them, and the adapters handle the differences between exchanges.

The README is careful about who it is written for. It says the README is for developers who want to contribute to Prebid.js, and that additional documentation can be found at the Prebid.js documentation homepage with working examples in the developer docs. So the repository README is the contributor document, and the user facing documentation lives elsewhere.

The disclaimer is the paragraph to read before adopting it. Prebid.js is open source software offered for free as a convenience, and while it is designed to help companies address legal requirements associated with header bidding, the project cannot and does not warrant that your use will satisfy legal requirements. You are solely responsible for ensuring your use complies with all applicable laws, and they strongly encourage you to obtain legal advice.

That is a careful and unusual thing for a project to say about itself, and it reflects where the real risk lies. Header bidding in most regulated markets is a privacy question first and a technology question second, and a library cannot decide for you what your consent requirements are.

The licence is Apache-2.0, the primary language is JavaScript, and the last push to the repository was on 2026-10-17 with the repository not archived. The recent releases include 11.41.0 from 2026-10-08, 11.40.0 from 2026-10-07 and 10.29.2 from 2026-10-06, so the project ships on a regular train.

The build contains everything, and the modules flag is how you shrink it

The build optimisation section is the part of the README that a publisher should read twice, because the default is the opposite of what most people want.

The standard build output contains all the available modules from within the modules folder. If you do not see a file in modules for a bid adapter, the README says you may need to grep the repository to find the name of the module you need to include, because there are bid adapters which support multiple bidders through aliases.

That alias detail is the one that trips people up. A single adapter file can serve several exchanges, so the module list does not map one to one onto the bidders you want, and the discovery has to be done by searching the repository rather than by browsing a directory.

The remedy is the `--modules` CLI argument on the serve command, and the example names three adapters.

gulp serve --modules=openxBidAdapter,rubiconBidAdapter,sovrnBidAdapter

Building with just these adapters results in a smaller bundle, which the README says should allow the pages to load faster. For a publisher, that is the whole point, because header bidding scripts are on the critical path of page load and the difference between a bundle with every adapter in the ecosystem and one with five is measured in hundreds of kilobytes.

There is a set of build options that go further, and they are documented in the table. `globalVarName` sets the Prebid global variable name, defaulting to `pbjs`. `defineGlobal` is a boolean, defaulting to true, and if false no global variable is set at all. And `distUrlBase` is the base URL used for dynamically loaded modules, for example the debugging standalone file, defaulting to a jsdelivr path pointing at the chunks directory in the npm package.

Those options are customised through the webpack loader or the Rollup-compatible plugin, with details in the customize README. A publisher with a strict CSP who does not want Prebid touching the global scope can set `defineGlobal` to false, which is the kind of detail the option table exists for.

Using it as an npm dependency, and the TypeScript requirements

The usage section covers the npm dependency path, and there is a note that versions prior to v10 required some Babel plugins to be configured when used as an NPM dependency, with a link to the v9 README.

The current pattern is a named import plus side effect imports for the adapters you want.

import pbjs from 'prebid.js';
import 'prebid.js/modules/rubiconBidAdapter';
import 'prebid.js/modules/appnexusBidAdapter';
pbjs.processQueue();

pbjs.requestBids({
  ...
})

The imported modules register themselves automatically with Prebid, and `pbjs.processQueue()` is required to process existing pbjs.queue blocks and set up any further queue execution.

TypeScript support is explicit and the requirements are particular enough to cause friction if you miss them. The type definitions require TypeScript 5.6 or later. `moduleResolution` must be `bundler`, `node16` or `nodenext`, with a `module` that is valid for it. `target` must be ES2015 or later. And `lib`, if you set it explicitly, must include `DOM` and ES2015 or later, though the default for the targets above already includes both.

The `moduleResolution: node10` case is called out as not supported, with the note that it is the default when `module` is `commonjs`. That is a common breakage, because a TypeScript project with a CommonJS module setting will fail to resolve the types until the setting is changed.

There is also a path for type-only consumers. You can import just type definitions for every module from `types.d.ts`, and for the `pbjs` global from `global.d.ts`, and if your bundle uses a different global variable name you can declare it yourself.

import type {PrebidJS} from 'prebid.js/types.d.ts';
declare global {
    interface Window {
        myCustomPrebidGlobal: PrebidJS;
    }
}

Installing `@types/google-publisher-tag` improves type checking where the Prebid types refer to GPT ad slots, such as the argument to `customGptSlotMatching`.

Building from source, and the gulp version history

The install instructions are the standard clone and install.

$ git clone https://github.com/prebid/Prebid.js.git
$ cd Prebid.js
$ npm ci

NodeJS 12.16.1 or greater is required for the general install path, and the package manifest for the current development version requires Node 24.14.1 or newer, so the floor has moved up over the years.

The gulp note is the interesting one. In the 1.24.0 release the project transitioned to gulp 4.0 from gulp 3.9.1, and to comply with gulp's recommended setup for 4.0 you need `gulp-cli` installed globally before running the general `npm ci`. The README warns that this shouldn't impact other projects using an earlier version of gulp, and explains how to check: run `gulp -v` and look at the version listed in the `CLI` field. If you have the `gulp` package installed globally it is likely the same version shown in the `Local` field, and if `gulp-cli` is already installed it should be a lower major version.

The remedy is two commands, remove the old global gulp and install the CLI.

npm rm gulp -g
npm install gulp-cli -g

For development the recommended command runs the tests but not the linting, and starts a web server at `http://localhost:9999` serving from the project root, generating the full source with source maps plus a core build. The alternative is `gulp serve` if you prefer linting and additional watch files, at the cost of a slower development loop.

The repository has more build configuration than a typical library because it has to produce several different artefacts. There are separate webpack configs for the common build, the creative build and the standalone build, a karma configuration for unit tests, and WebdriverIO configs for the end to end tests in shared, local and public variants. The `modules/` and `metadata/` directories hold the adapters and their metadata, `creative/` holds the creative rendering code, and `plugins/` holds the plugin implementations.

An agent skill for inspecting a live auction

The agent tooling section is a new addition and worth a look, because it is a different kind of contribution from the rest of the project.

Agents debugging a live Prebid.js page can use the repository's `prebid-chrome-devtools` skill, which lives under `.agents/skills/prebid-chrome-devtools/SKILL.md`. The skill explains how to enable Chrome DevTools MCP's experimental third-party tools, how to discover the Prebid.js tool group, and how to inspect auctions, bids, events, floors and cache eligibility. It is invoked as `$prebid-chrome-devtools` in clients that support repository scoped agent skills.

The value of that is specific. Header bidding bugs are notoriously hard to diagnose from the outside, because the symptom is usually a missing or mispriced bid, and the cause is somewhere in the auction: a bidder that did not return, a floor that was computed too high, a targeting rule that excluded the slot, a timeout that fired. The Prebid.js dev tools already expose that, but knowing what to look at is the hard part, and a skill file that lists the questions in order is a real contribution to the debugging workflow.

The repository has clearly been prepared for agent-assisted work more broadly. There is an `AGENTS.md`, a `CLAUDE.md` and a `.claude/` directory at the root, alongside a `.devcontainer/` directory for a consistent development environment.

The governance and process files are also worth noting for anyone contributing. There is `governance.md`, `CONTRIBUTING.md`, `PR_REVIEW.md`, `RELEASE_SCHEDULE.md` and a `PREBID_VERSIONING_DEPRECATION.md`, plus a `CODE_OF_CONDUCT` referenced by the badge. The release schedule document and the versioning deprecation notice together suggest a project with a defined release process and a considered approach to deprecating versions, which is what you want in a dependency that every publisher's revenue depends on.

Editorial conclusion

Adopt Prebid.js if you need header bidding across multiple exchanges and you want a maintained adapter set rather than writing your own. Do not adopt it expecting a small script, because the standard build contains every adapter and the trimming is manual, and do not treat it as legal advice on consent frameworks, since the project explicitly says it cannot warrant that your use satisfies legal requirements. Verify first that the adapters you need are in the modules folder, that your consent management platform integration is configured the way your jurisdiction requires, and that the build you ship only contains the modules you intend to run.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. prebid/Prebid.js on GitHub
3. Project website
4. README
5. Releases