What changed between VAST 4.3 and VAST 4.4

VAST 4.4 has not been released. vast_4.4.xsd was merged into the IAB VAST repository on 17 July 2026 from a branch named 4.4Development, and its own annotation reads “DRAFT for working group discussion”. There is no press release, no release-notes entry, and no mention of it in the repository README.

The schema arrived as a by-product of a different piece of work: the CTV Ad Portfolio, whose signaling guidance was finalised, on 22 July 2026, after a public comment period that closed on 5 June. Keeping those two apart is the whole story of this migration.

If you take one thing from this page: you do not need to declare version="4.4" to use anything on it. Every VAST example in IAB's own final guidance declares version="4.2".

Summary

Why this exists: the CTV Ad Portfolio

Since 2024 the IAB's Ad Format Hero initiative collected hundreds of format submissions and consolidated them into six CTV ad formats that had been running in market for years on bespoke, per-publisher integrations:

Five of the six land in <NonLinearAds>, which is why a node that had barely moved since VAST 2.0 suddenly grew a content model. Menu ads go through Native and never touch this page.

1. MediaFiles under NonLinear

This is the substantive change. <NonLinear> previously accepted only <StaticResource>, <IFrameResource> and <HTMLResource>. It now accepts the same <MediaFiles> container as <Linear>, holding MediaFile, Mezzanine, InteractiveCreativeFile and ClosedCaptionFiles.

Before 4.4, a pause ad was a JPEG. Now it can be a 15-second MP4, a cinemagraph, or an interactive SIMID unit with a video fallback.

<NonLinear width="1920" height="1080">
  <Duration>00:00:15</Duration>
  <MediaFiles>
    <MediaFile delivery="progressive" type="video/mp4" width="1920" height="1080">
      <![CDATA[https://cdn.example.com/pause.mp4]]>
    </MediaFile>
  </MediaFiles>
</NonLinear>

<NonLinear width="1920" height="1080">
  <Duration>00:00:15</Duration>
  <MediaFiles>
    <MediaFile delivery="progressive" type="video/mp4" width="1920" height="1080">
      <![CDATA[https://cdn.example.com/pause.mp4]]>
    </MediaFile>
  </MediaFiles>
</NonLinear>

Validation rule: VAST-4.4-nonlinear-mediafiles-empty catches a container with nothing renderable in it.

2. Duration under NonLinear

<Duration> is what makes quartile and overlayViewDuration tracking possible for these formats. The guidance makes it optional, with a specific carve-out: static image creative used for pause, screensaver and overlay may not have a known duration at response time, and in those cases the publisher expresses duration in the bid request instead.

A video MediaFile has a known duration by definition. Omitting <Duration> there means the ad renders and the measurement stack sees nothing.

Validation rule: VAST-4.4-nonlinear-video-no-duration

3. Icons under NonLinearAds

<Icons> previously appeared under <Linear>, <Companion> and <CompanionAds>. It now also appears under <NonLinearAds>, so a pause ad can carry an AdChoices icon.

4. NonLinearCustomClick returns

NonLinearCustomClick does not appear in the VAST 2.0.1, 3.0 or 4.2 XSDs. The 4.4 draft reintroduces it, typed as a URI element with an optional id, alongside <NonLinearClickThrough> and <NonLinearClickTracking>.

5. SIMID moves into NonLinear MediaFiles

The guidance is direct about this:

This is the preferred VAST 4.4 pattern for secure interactive NonLinear creative. The prior pattern of using <IFrameResource apiFramework="SIMID"> is not recommended for CTV Ad Portfolio NonLinear ads.

<!-- Superseded -->
<NonLinear width="480" height="70">
  <IFrameResource apiFramework="SIMID" type="text/html">
    <![CDATA[https://cdn.example.com/simid.html]]>
  </IFrameResource>
</NonLinear>

<!-- Preferred, with fallback -->
<NonLinear width="480" height="70">
  <MediaFiles>
    <MediaFile delivery="progressive" type="video/mp4" width="480" height="70">
      <![CDATA[https://cdn.example.com/fallback.mp4]]>
    </MediaFile>
    <InteractiveCreativeFile type="text/html" apiFramework="SIMID">
      <![CDATA[https://cdn.example.com/simid.html]]>
    </InteractiveCreativeFile>
  </MediaFiles>
</NonLinear>

<!-- Superseded -->
<NonLinear width="480" height="70">
  <IFrameResource apiFramework="SIMID" type="text/html">
    <![CDATA[https://cdn.example.com/simid.html]]>
  </IFrameResource>
</NonLinear>

<!-- Preferred, with fallback -->
<NonLinear width="480" height="70">
  <MediaFiles>
    <MediaFile delivery="progressive" type="video/mp4" width="480" height="70">
      <![CDATA[https://cdn.example.com/fallback.mp4]]>
    </MediaFile>
    <InteractiveCreativeFile type="text/html" apiFramework="SIMID">
      <![CDATA[https://cdn.example.com/simid.html]]>
    </InteractiveCreativeFile>
  </MediaFiles>
</NonLinear>

The point of the split is that <MediaFile> is a renderable asset and <InteractiveCreativeFile> is a separate interactive layer. A player that cannot execute SIMID renders the MediaFile. A player that has neither fires the error URI and the impression is lost. SIMID support on CTV devices is nowhere near universal, so shipping an interactive-only NonLinear is a quiet way to no-fill a large share of your install base.

Validation rules: VAST-4.4-nonlinear-no-renderable-asset and VAST-4.4-nonlinear-simid-iframe

6. AdCOM signals round-tripped into Extension

This is the part most people will get wrong, because it is a VAST change driven entirely by an OpenRTB problem.

The bid request describes the opportunity using AdCOM enumerations on plcmt, pos and playbackmethod. But the VAST response often travels further than the bid object does: an SSAI stitcher or a measurement vendor downstream of the original RTB transaction never sees the bid. So the DSP echoes the format context back into the creative.

One signal per <Extension>, with ext="adcom":

<Extensions>
  <Extension type="plcmt" ext="adcom"><plcmt>7</plcmt></Extension>
  <Extension type="pos" ext="adcom"><pos>14</pos></Extension>
  <Extension type="playbackmethod" ext="adcom"><playbackmethod>2</playbackmethod></Extension>
  <Extension type="attr" ext="adcom"><attr>23</attr></Extension>
</Extensions>

<Extensions>
  <Extension type="plcmt" ext="adcom"><plcmt>7</plcmt></Extension>
  <Extension type="pos" ext="adcom"><pos>14</pos></Extension>
  <Extension type="playbackmethod" ext="adcom"><playbackmethod>2</playbackmethod></Extension>
  <Extension type="attr" ext="adcom"><attr>23</attr></Extension>
</Extensions>

plcmt: Plcmt Subtypes, Video

Values 1 to 4 predate the CTV Ad Portfolio.

playbackmethod

Values 1 to 7 predate it.

Overlay, Squeezeback and In-Scene reuse the existing 1 and 2.

pos

Extends past the old 0 to 7 ceiling to describe on-screen treatment. The guidance gives per-format sets rather than a table: 7 and 8 for fullscreen and partial-screen Pause and Screensaver, 5/9/10/14/15 for Overlay geometry, 11/12/13/16/17 for Squeezeback layouts. Observed ceiling is 17.

attr: creative motion

Three new Creative Attributes, and the ones that make the whole thing work commercially:

A publisher whose pause placement renders an MP4 as a still frame sets battr: [22, 23] to block motion creative while still accepting MP4 delivery. That distinction, between technical format support and experiential constraint, was not expressible before.

Validation rules: adcom-extension-unknown-signal, adcom-extension-type-mismatch, adcom-signal-not-integer, adcom-plcmt-value, adcom-playbackmethod-value, adcom-pos-value, adcom-attr-not-motion

7. QR codes in CreativeExtension

Pause, screensaver and idle-state placements are the natural home for a QR code, because the viewer is not mid-content and has a phone within reach. The draft schema adds four typed elements under <CreativeExtension>:

<CreativeExtension type="tl_qrcode">
  <QrCodeScanUrl><![CDATA[https://brand.example.com/qr]]></QrCodeScanUrl>
  <QrCodeImageUrl><![CDATA[https://cdn.example.com/qr.png]]></QrCodeImageUrl>
  <QrCodePosition xPosition="10%" yPosition="70%"/>
  <QrCodeSize size="15%"/>
</CreativeExtension>

<CreativeExtension type="tl_qrcode">
  <QrCodeScanUrl><![CDATA[https://brand.example.com/qr]]></QrCodeScanUrl>
  <QrCodeImageUrl><![CDATA[https://cdn.example.com/qr.png]]></QrCodeImageUrl>
  <QrCodePosition xPosition="10%" yPosition="70%"/>
  <QrCodeSize size="15%"/>
</CreativeExtension>

The trap: <Icon> types its xPosition and yPosition as vastIntegerOrPercent_type, so xPosition="120" is valid there. <QrCodePosition> types them as vastPercent_type. The same markup is invalid. CTV screens vary too much in resolution for pixel coordinates to mean anything, which is presumably why. If you are generating QR blocks by adapting existing icon markup, this will bite you.

Validation rules: qrcode-position-percent, qrcode-position-attrs, qrcode-size-percent, qrcode-size-attr, qrcode-missing-scan-url

8. minSuggestedDuration retyped

4.2 typed it xs:time, which requires a full hh:mm:ss. 4.4 types it vastTime_type, permitting mm:ss and milliseconds. This brings it in line with every other VAST time field. No practical migration work.

What the draft XSD gets wrong

Two things in vast_4.4.xsd should not be treated as normative, and VASTlint does not enforce either.

It drops elements that exist in published VAST. The draft was rebuilt by hand from the 4.2 XSD rather than diffed against it, and AltText, BlockedAdCategories, Expires, IconClickFallbackImage and IconClickFallbackImages all vanish. Nothing in the CTV Ad Portfolio guidance removes them and no IAB communication announces it. Treat 4.4 as 4.3's content model plus the additions above.

It makes Extension/@type required and restricts custom Extension children to ##other. In 4.2, type is optional and custom children use processContents="skip". Enforcing the draft here would invalidate a decade of deployed vendor extensions.

Defects in the published examples

Worth knowing if you are copying from the guidance document. We filed these upstream:

• The Screensaver cinemagraph example has an unbalanced </Extension>. That example does not parse.
• One Overlay example carries <attr>20</attr>. The same document defines only 21, 22 and 23 as motion attributes.
• One template is still <VAST version="INSERT VAST VERSION">.

Migration checklist: VAST 4.3 to 4.4

• Do not change your version attribute to "4.4" for production traffic. Stay on 4.2 or 4.3, matching IAB's own examples. The content model works either way.
• For CTV Ad Portfolio formats, move NonLinear creative delivery to <MediaFiles>
• Add <Duration> to any NonLinear carrying a video MediaFile
• Move SIMID from <IFrameResource apiFramework="SIMID"> to <InteractiveCreativeFile apiFramework="SIMID"> inside <MediaFiles>
• Always ship a renderable fallback alongside an interactive file
• Round-trip plcmt, pos, playbackmethod and attr into <Extensions> with ext="adcom"
• Set attr honestly. 21, 22 and 23 are what publishers filter on
• Express QR geometry in percentages, never pixels
• Do not remove AltText, BlockedAdCategories, Expires or IconClickFallbackImages on the draft schema's say-so

Validate your CTV Ad Portfolio tags in the web validator, see the full rule reference, read what VAST 4.4 actually is, or go back to the VAST 4.2 to 4.3 migration guide.