VASTlint
Validate

VAST is XML, but valid XML is not necessarily a valid video ad

VAST vs XML is a question about layers. XML is a syntax for structured documents. VAST is the IAB Tech Lab's video ad response format written in that syntax. A VAST response uses XML elements to tell a player or stitcher which ad to play, where to fetch its media, and which events to track. An XML parser can confirm that the document is well formed. It cannot decide whether the ad can play or count.

QuestionXMLVAST
What is it?A general document syntaxA video ad response standard expressed in XML
What is the root?Any well-formed root element<VAST> with a supported version
What does it describe?Whatever its author definesAds, media, impressions, tracking, wrappers, and other ad behavior
Who reads it?Any suitable XML parserA VAST-aware player, ad server, stitcher, or validator
What proves it works?Successful parsing proves only syntaxSpecification checks plus a playback test

A well-formed XML file is not automatically a VAST tag

This document is valid XML. A VAST player has no instruction to treat it as a video ad:

<?xml version="1.0" encoding="UTF-8"?>
<videoAd>
  <media>https://cdn.example.com/spot.mp4</media>
</videoAd>

A VAST response instead uses the vocabulary and ordering defined by the VAST specification. The example below is a compact VAST 3.0 InLine ad. The URLs are placeholders, so the XML can be checked before a real media fetch, but it cannot be played until those URLs resolve.

<VAST version="3.0">
  <Ad id="spot-1">
    <InLine>
      <AdSystem version="1.0">Example Ad Server</AdSystem>
      <AdTitle>Example spot</AdTitle>
      <Impression><![CDATA[https://metrics.example.com/imp]]></Impression>
      <Creatives>
        <Creative>
          <Linear>
            <Duration>00:00:15</Duration>
            <TrackingEvents>
              <Tracking event="start"><![CDATA[https://metrics.example.com/start]]></Tracking>
              <Tracking event="complete"><![CDATA[https://metrics.example.com/complete]]></Tracking>
            </TrackingEvents>
            <MediaFiles>
              <MediaFile delivery="progressive" type="video/mp4"
                         width="1280" height="720">
                <![CDATA[https://cdn.example.com/spot.mp4]]>
              </MediaFile>
            </MediaFiles>
          </Linear>
        </Creative>
      </Creatives>
    </InLine>
  </Ad>
</VAST>

The MediaFile supplies a candidate playable asset. The Impression URL counts a qualifying ad impression. A wrapper would instead point to another VAST response through VASTAdTagURI. See the VAST examples library for version-specific documents and the wrapper guide for chained responses.

Four checks answer four different questions

  1. XML parsing: Do tags close, attributes parse, and entities escape correctly? Failure here stops every later check.
  2. VAST schema validation: Are elements and attributes allowed in this VAST version, with the required structure and order?
  3. VAST specification validation: Does the document satisfy requirements in the written spec that the XSD cannot fully encode?
  4. Live delivery and playback: Does the URL respond, do wrappers resolve, can the player decode the media, and do tracking requests fire at the right events?

The layers cannot stand in for one another. An XML parser accepts the first example. An XSD catches many structural mistakes in the second. Neither can fetch a media URL or watch a player fire a quartile beacon. For a pasted document use the VAST validator. For a URL and its redirects use the live tag tester or wrapper inspector.

A real case where the XSD passed and the VAST rule failed

We checked the IAB Tech Lab's public sample tags against the matching XSD and against vastlint. Two ad verification samples, one labeled VAST 4.1 and one VAST 4.2, pass XSD validation while omitting attributes that the written VAST 4.1 specification requires. The missing fields are Verification@vendor and JavaScriptResource@apiFramework. This is a concrete example of why "schema valid" and "specification valid" are different claims. The benchmark publishes the files, commands, and results.

<!-- The sample's structure passes the VAST 4.1 XSD. -->
<AdVerifications>
  <Verification>
    <JavaScriptResource>
      <![CDATA[https://verification.example.com/omid.js]]>
    </JavaScriptResource>
  </Verification>
</AdVerifications>

<!-- The written VAST 4.1 requirements also need these attributes. -->
<AdVerifications>
  <Verification vendor="verification.example.com-omid">
    <JavaScriptResource apiFramework="omid" browserOptional="true">
      <![CDATA[https://verification.example.com/omid.js]]>
    </JavaScriptResource>
  </Verification>
</AdVerifications>

VAST XML fragment only. This excerpt belongs inside a complete VAST document, so standalone validation will fail until it is wrapped in a full <VAST>response.

These are fragments to show the attribute difference, not complete ad responses. For a repeatable XML, XSD, and VAST check in a pipeline, follow the validation guide.

Which check should you run?

  • You have a local XML file: validate its VAST structure and rules, then test the live media when the URLs are available.
  • You have only an ad tag URL: fetch it and inspect redirects first, then validate the VAST response returned at each relevant hop.
  • The XML validates but the ad does not play: check media codec support, HTTP responses, wrapper timeouts, and the player's VAST error code.
  • You are comparing an XML validator with a VAST validator: check whether it implements the written VAST rules and whether it can test a live URL. A generic XML parser does neither.

Sources