What changed between VAST 4.2 and VAST 4.3
VAST 4.3 was released by the IAB in December 2022. It is the smallest VAST release on record. The IAB explicitly noted that the changes did not require an XSD update — the VAST 4.2 XSD remains the authoritative schema for VAST 4.3 documents. There are three meaningful changes.
| Change | Impact |
|---|---|
<InteractiveCreativeFile> may contain an inline data: URI | data: URIs are now valid content; do not reject them |
[PLAYBACKMETHODS] macro value 7 added | Live macro context only; no XML lint impact |
| Macros reference moved to separate GitHub document | No XML impact |
<InteractiveCreativeFile> can contain inline data: URIs
Previously, <InteractiveCreativeFile> was expected to contain a URL pointing to the interactive creative resource. VAST 4.3 explicitly allows the content to be an inline data URI instead.
A data URI embeds the resource content directly in the VAST XML rather than requiring a separate HTTP request. For small SIMID creatives, this eliminates one round-trip during the ad load sequence — which matters in time-sensitive environments like live streams and CTV ad breaks.
The spec is explicit: “The recommendation is to make this as small as possible. Once the size of the data URI becomes prohibitively large, use a URL to save the response size of the VAST, itself.”
<!-- Standard URL — works in all versions -->
<InteractiveCreativeFile type="text/html" apiFramework="SIMID">
<![CDATA[https://example.com/interactive.html]]>
</InteractiveCreativeFile>
<!-- Inline data URI — new in VAST 4.3 -->
<InteractiveCreativeFile type="text/html" apiFramework="SIMID">
<![CDATA[data:text/html;base64,PCFET0NUWVBFIGh0bWw+...]]>
</InteractiveCreativeFile>The element type remains xs:anyURI in the 4.2 XSD. Data URIs are syntactically valid URIs per RFC 3986, so no XSD change was needed. Validators must not flag a data: scheme URI inside <InteractiveCreativeFile> as invalid.
[PLAYBACKMETHODS] macro value 7
A new value was added to the [PLAYBACKMETHODS] macro, substituted at impression time to describe how the player initiated playback:
| Value | Meaning |
|---|---|
| 1 | Auto-play, sound on |
| 2 | Auto-play, sound off |
| 3 | Click-to-play |
| 4 | Mouse-over |
| 5 | Entering viewport, sound on |
| 6 | Entering viewport, sound off |
| 7 | Continuous play — back-to-back episodes or content without user interaction between them (new in 4.3) |
This is a macro substitution value, not an XML element or attribute. It has no impact on VAST document linting.
<JavaScriptResource browserOptional> recommended
The browserOptional attribute on <JavaScriptResource> was added in 4.1 but has a vastlint rule that flags its absence. For CTV and non-browser delivery contexts, this attribute tells the player whether the JavaScript resource is strictly required or whether the ad can still play without it.
<JavaScriptResource apiFramework="omid" browserOptional="false">
<![CDATA[https://example.com/omid.js]]>
</JavaScriptResource>→ Rule reference: VAST-4.3-js-resource-browser-optional
What did not change
Every rule and structure from VAST 4.2 applies to VAST 4.3 documents without modification:
<AdServingId>required in<InLine><UniversalAdId>value in text content (notidValueattribute)<Mezzanine>typed element with requireddelivery,type,width,height<ExecutableResource>in<Verification>adTypeon<Ad>,renderingModeon<Companion><ClosedCaptionFiles>in<MediaFiles><ClickThrough>allowed in Wrapper<VideoClicks>(restored in 4.2)<IconClickFallbackImages>for icon disclosureinteractiveStarttracking event
Migration checklist: VAST 4.2 → 4.3
- Update
versionattribute on<VAST>to"4.3" - If serving SIMID creatives: consider using inline
data:URIs for small payloads to reduce request latency - Ensure
<JavaScriptResource>hasbrowserOptionalattribute set for CTV contexts
Validate your VAST 4.3 documents at vastlint.org/validate. See the full rule reference or go back to the VAST 4.1 to 4.2 migration guide.