What Actually Happens When Your Player Doesn't Support a VAST Version

One question, three different failures

Ask what happens when an ad stack meets a VAST version it does not support, and most people picture an error code. That answer exists: VAST error 102, the version-not-supported signal the spec has carried since VAST 3.0. In production it is the rarest of three outcomes. The common outcomes are quieter. Either the player renders the ad and silently ignores the parts of the document it does not understand, or something upstream downgraded the tag to an older version before the player ever saw it, shedding features along the way.

All three outcomes cost money. Only one of them tells you it happened. This post walks through where version support is actually decided, what each failure looks like on a real stack, and how to catch the two silent ones.

Where version support is decided

A VAST document declares its version exactly once, in the version attribute on the root VAST element. The player reads that attribute and chooses its parsing behavior from it. That is the entire in-band negotiation. There is no handshake, no capability exchange, and no fallback protocol inside VAST itself.

The real negotiation happens one layer up, in OpenRTB. A video bid request lists the versions the player accepts in imp.video.protocols, using the AdCOM protocols list: VAST 2.0 is value 2, VAST 3.0 is value 3, and VAST 4.0 through 4.2 with their wrapper variants run from 7 to 14. A buyer that respects the list never sends an unsupported version. A buyer that ignores it, or a request that omits it, is how a 4.2 document arrives at a player built for 2.0.

The third decision point is configuration. Ad servers and SSPs let you choose which VAST version they render out, and many default to 2.0 or 3.0 on purpose, because old versions play everywhere. Version support is therefore decided three times, by three different parties, and any one of them can create the mismatch.

The loud failure: error 102

When a player checks the version attribute and refuses to proceed, the spec gives it error code 102: VAST version of response not supported. The player substitutes 102 into the [ERRORCODE] macro, fires the Error tracker, abandons the ad, and falls through to whatever the waterfall has next. The impression never fires, so the buyer logs a lost opportunity and the publisher logs an unfilled or refilled slot.

Error 102 has one virtue: it is visible. It shows up in error reporting, ad server dashboards break it out, and both sides can see the disagreement and fix it. The fix is alignment work, either the demand side stops sending versions the player cannot read, or the player upgrades.

Two neighboring codes matter for diagnosis. Error 100 is an XML parsing failure and 101 is a schema validation failure. Players without a strict version check often surface a version problem as 100 or 101 instead, when an element from a newer version trips their parser. If a partner's 100s spike right after you move to a newer VAST version, you are usually looking at a version problem wearing a parsing costume.

The quiet failure: the ad plays, the features don't

Most modern players do not hard-reject on version. They parse the elements they know and skip the rest. Google's IMA SDK reads the version attribute and applies version-appropriate parsing across 2.0 through 4.3. Roku's RAF accepts 4.2 and 4.3 documents but silently ignores some newer fields. For players like these, an unsupported version does not fail. It degrades.

The degradation pattern is consistent: the media file plays, and the money-adjacent metadata disappears.

What silently disappears when a 4.x tag meets an older parser

• AdVerifications and OMID measurement. VAST 4.1 moved verification out of Extensions into a first-class element, so an older parser never sees it. Viewability and IVT measurement vanish while the ad plays normally.
• UniversalAdId, added in 4.0. Creative deduplication and cross-platform frequency capping lose their key.
• Mezzanine, added in 4.0. SSAI stitchers lose the mastering-quality source they transcode from and fall back to whatever MediaFile survives.
• ClosedCaptionFiles, added in 4.2. Caption files are dropped without any accessibility warning.
• Category with its authority attribute. Brand safety classification quietly falls back to nothing.
• SIMID interactivity, formalized in 4.3. Interactive layers simply do not render, while the underlying video still plays.

Wrappers multiply the mismatch

A wrapper chain is not one VAST document. It is one document per hop, and each hop declares its own version. A 4.2 wrapper can point to a 3.0 wrapper that resolves to a 2.0 inline, and nothing in the spec forbids it. The effective feature set of the chain is the minimum of the versions along it, applied hop by hop by whatever parses each document.

That has two operational consequences. Verification injected at the wrapper level survives only if the player understands the wrapper's version. And a downgrade anywhere in the chain, say an SSP re-rendering to 2.0 for compatibility, strips 4.x features for everything downstream, no matter how carefully the inline creative was authored.

Why old versions still dominate

The economics explain the state of the ecosystem. Serving VAST 2.0 or 3.0 is the lowest common denominator: it plays on everything, so nothing visibly breaks, so the integration ticket never gets opened. That is why, seventeen years after VAST 2.0 shipped, a large share of production tags still declare 2.0 or 3.0 even when the buy paid for a 4.x feature set.

The asymmetry is the trap. A version rejection is an incident with an error code and an owner. Silent feature loss is invisible, so every rational participant downgrades toward compatibility, and the industry keeps trading 4.x features that are stripped before they reach glass. If you bought OMID verification or rely on UniversalAdId dedup, the version your stack actually delivers end to end is not a detail. It is whether you got what you paid for.

The playbook

• Declare the version you actually use. If the document contains 4.x elements, the root attribute must say so. IMA and other SDKs pick parsing rules from that attribute, and a 4.1 element inside a document declaring version 3.0 may be silently ignored.
• Know your player matrix before trafficking. IMA parses 2.0 through 4.3, RAF tops out with partial 4.2 and 4.3 handling, and every CTV platform has its own quirks. The per-platform guides on this site list what each SDK reads and drops.
• Populate and respect imp.video.protocols in the bid stream. The protocols list exists so this negotiation happens before the tag is sent, not after it fails.
• Validate what the transcoder emits, not what you authored. If an SSP, ad server, or SSAI stitcher re-renders your tag, pull the served document and validate that, because the downgrade happens between your QA and the device.
• Pin validation to the version you traffic and run it in CI, so a partner-side version change shows up as a failing check instead of a quarter-end revenue question.