OpenRTB Bid Request Validator
Validate an OpenRTB 2.5 or 2.6 bid request against the IAB rules in your browser. The JSON you paste stays on your device.
The OpenRTB Bid Request Validator runs entirely in your browser. The bid request JSON you paste is parsed and checked on your device and is never uploaded to ArrayKit or sent to any exchange.
Open the OpenRTB Bid Request Generator
About OpenRTB Bid Request Validator
The OpenRTB Bid Request Validator lints a real-time bidding request against the IAB OpenRTB 2.5 and 2.6 rules the moment you paste it. Pick a version and it confirms the required id and imp[] are present, that every impression carries exactly one media object (banner, video, native, or audio), that field types line up, and that each enumerated field — auction type, video protocols, placement or plcmt, devicetype, connectiontype, and api frameworks — holds a code that actually exists in that version. Findings come back as a pass/fail verdict plus a path-addressed list you can jump straight to. Ad-ops engineers and SSP/DSP integrators debug live traffic samples here without POSTing a bid request to a third-party endpoint — it all runs on your device.
Features
- Validates against OpenRTB 2.5 or 2.6 using version-aware enumeration sets
- Confirms the required id and a non-empty imp[] impression array
- Checks that each impression declares exactly one of banner, video, native, or audio
- Verifies IAB enum codes: at, video protocols, placement/plcmt, devicetype, connectiontype, api
- Handles the 2.6 plcmt field and flags deprecated placement usage per version
- Every finding carries a JSON path like imp[0].video.plcmt so you can pinpoint it
- Separates blocking errors from advisory warnings such as deprecations and duplicate imp ids
- Parses and checks the bid request in your browser — samples never leave your device
How to use the OpenRTB Bid Request Validator
- Choose the OpenRTB version your exchange speaks (2.5 or 2.6)
- Paste the bid request JSON, or load the sample to see the expected shape
- Read the pass/fail verdict and the path-addressed findings list
- Fix each error at the flagged path and re-check until the request is valid
Example
Input
{
"id": "r1",
"imp": [{ "id": "1", "video": { "plcmt": 5 } }],
"site": { "id": "s1" }
}
Output
Invalid (OpenRTB 2.6)
imp[0].video.plcmt — 5 is not a valid video plcmt for OpenRTB 2.6. Allowed: 1, 2, 3, 4.
The plcmt field only accepts codes 1–4 in OpenRTB 2.6.
Common errors & troubleshooting
- "Missing required field imp" even though the request has impressions. — imp must be a JSON array — imp: [{ ... }], not a single object. The validator also flags an empty [] because at least one impression is required.
- An impression with both a banner and a video object is rejected. — This validator expects exactly one media object per impression. Split multi-format inventory into separate imp entries, one media type each.
- devicetype or connectiontype is flagged as invalid on a request that worked before. — Some codes are version-specific: devicetype 8 (OOH) and connectiontype 7 (5G) only exist in 2.6. Switch the version toggle to match your exchange.
- placement is flagged after upgrading to OpenRTB 2.6. — 2.6 deprecates video.placement in favor of video.plcmt (Plcmt Subtypes). Move the value to plcmt, whose valid codes are 1–4, and the warning clears.
Frequently asked questions
- What does the OpenRTB Bid Request Validator check?
- It confirms the required id and a non-empty imp[] array, that each impression has exactly one media object (banner, video, native, or audio), that field types are correct, and that every enumerated field holds a code valid for the selected OpenRTB version.
- What is the difference between placement and plcmt in OpenRTB 2.6?
- video.placement (Video Placement Types, codes 1–5) is the 2.5 field; OpenRTB 2.6 deprecates it in favor of video.plcmt (Plcmt Subtypes, codes 1–4). In 2.6 the validator checks plcmt and warns if the legacy placement field is still present.
- Why does my request fail when an impression carries both a banner and a video?
- The validator enforces exactly one media object per impression, so a banner plus a video on the same imp is reported as an error at that imp path. Model multi-format inventory as separate impression objects instead.
- Which codes are allowed for devicetype and connectiontype?
- devicetype accepts 1–7 in 2.5 and 1–8 in 2.6 (8 = OOH Device). connectiontype accepts 0–6 in 2.5 and 0–7 in 2.6 (7 = Cellular 5G). The validator lists the allowed codes for the version you selected in the error message.
- Does switching between OpenRTB 2.5 and 2.6 change the result?
- Yes. The enumeration sets are version-aware, so codes added in 2.6 (OOH devicetype, 5G connectiontype, SIMID api, the plcmt field) validate in 2.6 but are rejected in 2.5. Always pick the version your exchange negotiated.
- Is my bid request sent to an ad server when I validate it?
- No. The tool parses and checks the JSON on your device and never fetches a remote ad tag or POSTs the request anywhere. Nothing about the bid request is uploaded to ArrayKit or an exchange.
Related tools
All ArrayKit tools