OpenRTB bid request builder and validator: build, paste and check OpenRTB 2.6 requests

Paste a request from your exchange logs, a Prebid Server debug response or a partner's integration guide. The validator reads it the way a careful bidder would and tells you what to fix before a partner rejects it. For what each field means, read OpenRTB 2.6 explained alongside the tool.

1. Pick a preset. Choose display banner, outstream video, CTV pod, native, audio or DOOH. Each preset loads a complete request that passes every check.
2. Edit the form. Change sizes, durations, floors, currency, the site or app, the device and the privacy signals. Drop-downs show the AdCOM label next to each code, so you pick "4 = No Content/Standalone", not a bare 4.
3. Watch the findings. The validator runs on every change. A red badge means the request breaks a rule; amber means a bidder may misread it; grey is a note.
4. Copy or download. Copy the JSON, download it as bid-request.json, or copy a cURL command with the x-openrtb-version: 2.6 header for your own test endpoint. The tool never sends the request anywhere.
5. Share the state. The share link stores the whole form in the URL fragment, which browsers do not send to our server.

To validate instead, open the Paste tab, paste a request and press Validate. Findings appear in document order, each with a JSON path, a plain-English message and a link to the section of the spec.

Every preset uses reserved .example domains, documentation IP ranges and invented IDs. Codes come from AdCOM 1.0 and are labelled in the form. The privacy strings are real test strings from the IAB Tech Lab reference library (iabgpp-es, GppModel tests), so they decode in our GPP consent string decoder.

Sources for the codes: AdCOM 1.0, OpenRTB Native Ads 1.2 and the OpenOOH Venue Taxonomy 1.1.

The display and CTV examples are explained field by field in OpenRTB 2.6 explained, so this page prints the two formats that article does not cover. Here is the outstream video preset. The slot sits in an article, below the fold, and the player starts muted when it scrolls into view.

Three choices make this outstream rather than instream. A plcmt of 4 tells buyers there is no video content around the ad. A playbackmethod of 6 says the player starts when it enters the viewport, with sound off. A playbackend of 2 says it stops when the player leaves the viewport (AdCOM, Playback Methods and Playback Cessation Modes). The implementation guide maps the old "In-Article" placement to this value (implementation guide, section 7.10.2).

The TC String in user.consent matches section 2 of the GPP string, so both readers see the same consent; you can open it in the TCF consent string decoder.

The DOOH preset shows the fields a screen needs and a phone does not.

One play of this ad counts as 14.2 impressions, so a winning bid of 6.00 GBP CPM costs 6.00 / 1000 x 14.2, or about 0.085 GBP. That is the pricing rule in the implementation guide, section 7.9.4. The dt value is the planned display time in milliseconds: 1794229200000 is 9 November 2026 at 13:00 UTC. Venue 10602 is "Transit, Train Stations, Platform" in the OpenOOH Venue Taxonomy, and venuetypetax 5 names version 1.1 of that list. The ifa_type value sits in device.ext, where the IAB community extension defines it.

The best test of a validator is the specification itself. We pasted Example 4, the video request in section 6.2.4 of 2.6.md. It parses, it has every required field, and it gets no errors. It still draws two warnings and four notes.

The apis finding is the instructive one. The field apis exists in OpenRTB 2.6, but on the bid object of the response, not on the video object of the request (OpenRTB 2.6, Object: Video). A bidder that follows the versioning rule will silently ignore it, so the VPAID support the example meant to signal never reaches the buyer. Three edits clear both warnings and the two most useful notes: rename apis to api, add "plcmt": 1, and set cattax to a current taxonomy with matching category IDs.

The validator applies 11 families of checks, in the order a parser meets them. Severity follows one rule. An error means the request breaks a "must" in the specification or cannot be read. A warning means a buyer may misread it or a "should" is broken. A note is information.

Enumerated values outside AdCOM are warnings rather than errors for the same reason unknown fields are notes. A partner may be on a newer AdCOM release than our copy, and the spec tells receivers to cope. For GPP the validator reads the header and compares it with gpp_sid; the GPP consent string decoder reads each section in full.

We ran all seven request examples that IAB Tech Lab publishes in the two specification files. None has an error, which is good news for anyone copying them. None is clean either.

The DOOH rows matter most. A bidder that reads only geo.lon sees no longitude at all, and the guide itself says latitude and longitude are required for DOOH. The deal floors in the DOOH banner example are also read as USD while the impression floor is in GBP, because a deal's currency never inherits the impression's (OpenRTB 2.6, Object: Deal). If you copy an official example as a template, run it through the validator first.

These patterns break integrations quietly, because JSON parsers accept them and bidders then drop or misprice the request.

1. Numbers sent as strings. "bidfloor": "0.50" is a string. A strict parser rejects it, and a lenient one has to guess.
2. Booleans for flags. "secure": true is not the integer 1 the spec asks for.
3. A single currency instead of an array. cur is a string array, so "cur": "USD" fails the type check.
4. Two duration models at once. rqddurs must not appear with minduration or maxduration (Object: Video).
5. Pre-2.6 locations. OpenRTB 2.6 moved regs.ext.gdpr, user.ext.consent and source.ext.schain into the core objects, and a 2.6 bidder may not look in ext at all.
6. A GPP string without gpp_sid. The buyer then cannot tell which section governs the transaction.
7. A supply chain that does not end with the seller. The last node's sid should equal publisher.id; the SupplyChain, ads.txt and sellers.json guide explains why buyers check this.
8. DOOH timestamps in seconds. dt is milliseconds since 1970. A value in seconds lands in January 1970.
9. A native request sent as an object. OpenRTB 2.x defines native.request as a JSON-encoded string, although some exchanges accept an object.
10. Site and app together. Only one context object applies to a request, and a DOOH request must carry neither.

The checks follow the OpenRTB 2.6 specification and implementation guide at release 2.6-202606, which was still the latest state of the repository on 9 November 2026. Enumerations come from AdCOM 1.0 as of its 23 July 2026 commit. Native checks follow Native Ads 1.2; supply chain checks follow the SupplyChain object 1.0. Each finding links to the section it relies on, so you can disagree with us on the evidence.

The tool checks one bid request at a time. It does not check bid responses, exchange-specific ext rules, or whether a seller ID appears in an exchange's sellers.json; the ads.txt and sellers.json validator does that last job. It reads the GPP header and the shape of a TC String; full consent decoding happens in the two decoders linked above. For how the auction around a request works, see how real-time bidding works. Pod logic is covered in depth in SSAI and CTV ad serving. Other engineering tools and guides sit in the RTB architecture hub.

1. IAB Tech Lab, "OpenRTB API Specification Version 2.6" (2.6.md, release 2.6-202606; accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/2.6.md
2. IAB Tech Lab, "OpenRTB 2.x Implementation Notes" (implementation.md, accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/openrtb2.x/blob/main/implementation.md
3. IAB Tech Lab, openrtb2.x releases 2.6-202210 (3 November 2022) to 2.6-202606 (11 June 2026), including the 2.6-202211 and 2.6-202303 notes (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/openrtb2.x/releases
4. IAB Tech Lab, "AdCOM Specification v1.0" (main branch, last commit 23 July 2026; accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/AdCOM/blob/main/AdCOM%20v1.0%20FINAL.md
5. IAB Tech Lab, "OpenRTB Dynamic Native Ads API Specification Version 1.2" (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/Native-Ads/blob/main/OpenRTB-Native-Ads-Specification-Final-1.2.md
6. IAB Tech Lab, "SupplyChain Object" 1.0 (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/openrtb/blob/main/supplychainobject.md
7. IAB Tech Lab, "IFA_TYPE" community extension for OpenRTB (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/openrtb/blob/main/extensions/community_extensions/ifa_type.md
8. IAB Tech Lab, "Global Privacy Platform: Consent String Specification" and "Section Information" (accessed 9 November 2026). https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Sections/Section%20Information.md
9. IAB Tech Lab, iabgpp-es reference library, GppModel.test.ts (accessed 9 November 2026). https://github.com/IABTechLab/iabgpp-es/blob/master/modules/cmpapi/test/GppModel.test.ts
10. OpenOOH, "Venue Taxonomy" specification 1.1 (accessed 9 November 2026). https://github.com/openooh/venue-taxonomy/blob/main/specification-1.1.md