VASTlint

VAST examples / Document structure

An <Ad> with an invalid adType value

VAST 4.10 errors2 warningsVAST-4.1-adtype-value

The scenario

A streaming audio service was assembling an ad pod that mixes audio spots with the occasional companion-rich hybrid ad. VAST 4.1 added the adType attribute on <Ad> so the player can tell whether an ad is video, audio, or hybrid and place it correctly in the pod.

The broken tag

<?xml version="1.0" encoding="UTF-8"?>
<!-- WARNING: VAST-4.1-adtype-value — Ad adType attribute value not in allowed set (video/audio/hybrid) -->
<VAST version="4.1">
  <Ad id="ad-001" adType="display">
    <InLine>
      <AdSystem>Test</AdSystem>
      <AdTitle>Test Ad</AdTitle>
      <AdServingId>test-serving-id-001</AdServingId>
      <Impression><![CDATA[https://track.example.com/impression]]></Impression>
      <Creatives>
        <Creative>
          <UniversalAdId idRegistry="ad-id.org">TEST-001</UniversalAdId>
          <Linear>
            <Duration>00:00:30</Duration>
            <MediaFiles>
              <MediaFile delivery="progressive" type="video/mp4" width="1920" height="1080">
                <![CDATA[https://cdn.example.com/video.mp4]]>
              </MediaFile>
            </MediaFiles>
          </Linear>
        </Creative>
      </Creatives>
    </InLine>
  </Ad>
</VAST>

What the validator reports

Running this tag through vastlint produces the following. The primary failure for this example:

warningVAST-4.1-adtype-valueIAB VAST 4.1 §2.2.1line 4

Ad adType attribute value is not in the allowed set (video, audio, hybrid)

The same tag also surfaces these secondary findings — real tags rarely fail in isolation:

warningVAST-2.0-linear-tracking-quartilesIAB VAST 4.1 §3.14.2line 13

<Linear> has no standard quartile tracking events (start/firstQuartile/midpoint/thirdQuartile/complete) — ad will serve but measurement system receives no signal

infoVAST-4.1-mezzanine-recommendedIAB VAST 4.1 §3.9.2line 15

<MediaFiles> has no <Mezzanine> — ad-stitching servers may reject this tag in CTV/SSAI contexts

Why it breaks

The <Ad> declares an adType whose value is not one of the spec's allowed tokens (video, audio, or hybrid). Because adType drives how a pod-aware player categorizes and slots the ad, an unrecognized value leaves the player unable to classify it. Lenient players may default it; strict ones treat the value as invalid.

What it costs

Misclassification breaks pod assembly: an audio service may receive an ad it cannot categorize as audio, leading it to drop the ad or mis-slot it, which causes under-fill or a jarring format mismatch for the listener. On hybrid units the companion behavior can be lost. The net effect is degraded pod delivery on exactly the 4.1-aware platforms the attribute was meant to serve.

The fix

Set adType to one of video, audio, or hybrid to match the creative. Omit it only if you intend the default (video); never use a custom token.

<!-- allowed: video | audio | hybrid -->
<Ad id="1" adType="audio">
  <InLine>...</InLine>
</Ad>

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.

Check your own version of this tag

Paste the resolved XML to run the same spec check, test a live tag URL, or inspect the wrapper chain hop by hop.

Validate this XML →Test this live URL →Inspect this wrapper chain →

Related examples

Related reading