These three acronyms get treated as alternatives, as though a creative is either MRAID or VAST. They are not alternatives — they solve different problems at different layers, and one campaign can involve all three. Knowing which is which matters mostly at one moment: when a network asks for a format and you need to know what they are actually asking for.
VAST: how a video ad is delivered
VAST — Video Ad Serving Template — is an XML document that tells a player where the video file is, how long it runs, what to do on a click, and which URLs to ping at quartile milestones. It is a delivery manifest, not a creative. The creative is the MP4 the manifest points at.
Because it is only a manifest, VAST has no interactivity of its own. The viewer watches; the player reports. That is exactly right for a straightforward video ad and useless for anything the user is supposed to touch.
VPAID: interactivity bolted onto video
VPAID — Video Player-Ad Interface Definition — was the answer to that gap: an executable creative that runs inside the video player and can respond to the user. It made interactive video possible, and it also made video ads slow, inconsistent across players, and a security concern, because it handed arbitrary code a privileged position inside the player.
The IAB deprecated it as of VAST 4.1 and named SIMID as its replacement. If you encounter VPAID today it is usually in older desktop or web video inventory — it never worked well on mobile or in over-the-top — and it is not the right answer for a new build.
MRAID: rich media inside an app
MRAID — Mobile Rich Media Ad Interface Definitions — is the standard that matters for playables. It defines how a creative running inside an app's webview talks to the container around it: whether the ad is currently visible, what state the container is in, how to resize, and critically how to open a store listing through mraid.open().
The mechanism is unusual and worth understanding. The creative includes a script tag pointing at mraid.js — a file that deliberately does not exist at that path. The network's webview intercepts the request and injects its own SDK implementation in its place. That is why validators reject MRAID creatives that omit the tag: without it there is nothing for the container to hook.
Version differences that bite
MRAID 2.0 reports viewability through isViewable() and the viewableChange event. MRAID 3.0 deprecates both — the IAB spec retains them for backward compatibility but adds exposureChange, reporting an exposed percentage from 0 to 100. Because containers vary in how completely they implement the deprecated pair, a creative that listens only for viewableChange can end up never learning it is visible.
Where playable ads sit
A playable is a self-contained HTML5 creative. On networks that implement MRAID — Unity, IronSource, AppLovin, Chartboost, InMobi and Vungle among them — it uses MRAID for viewability and the store exit. On networks that do not, it uses that network's own JavaScript API instead, and those are genuinely proprietary rather than standardised.
Google uses ExitApi.exit(), with exitapi.js loaded as a literal script tag in the head. Meta and Moloco use FbPlayableAd.onCTAClick() and both document that the creative must not include mraid.js at all. Mintegral uses window.install() plus gameReady and gameEnd lifecycle calls. TikTok and Pangle use window.openAppStore(). Liftoff uses a postMessage bridge.
This is the practical consequence of the whole discussion: there is no single build that satisfies all of them, because the store exit differs. One creative, one export per network.
The two standards you may also meet
OMID — Open Measurement Interface Definition — is how third-party viewability vendors measure in-app ads without each needing their own SDK. It sits alongside MRAID rather than replacing it, and for most playable advertisers it is something the network handles rather than something the creative implements.
SIMID — Secure Interactive Media Interface Definition — is the IAB's designated replacement for VPAID. Where VPAID handed the creative full access to the player's DOM and JavaScript context, SIMID runs it in a sandboxed cross-origin iframe that communicates with the player only through postMessage. It works alongside VAST rather than replacing it, and it is aimed primarily at streaming, CTV and OTT rather than in-app mobile.
What to take from this
If you are building a video ad, you need VAST and probably nothing else. If you are building an interactive experience inside a video player on web inventory, you are in VPAID or SIMID territory. If you are building a playable for in-app mobile inventory — which is where playables live — you need MRAID on some networks and a proprietary API on others, and the practical work is making sure each export carries the right one.
Anyone telling you a single file works everywhere is describing a file that reports clicks correctly on one network and silently fails to on the rest.
How to tell which one a network is asking for
The question that resolves it fastest is what the network wants you to upload. If they ask for an XML tag, or a URL that returns XML, that is VAST and the creative is a video file behind it. If they ask for an MP4, it is video and the VAST wrapper is being generated for you. If they ask for an HTML file or a ZIP containing one, you are building a playable — and the follow-up question is which store-exit call their container provides.
That follow-up is the one people skip. A network asking for a ZIP is not thereby asking for MRAID: Google, Meta, TikTok, Pangle, Mintegral and Liftoff all take ZIPs and none of them use mraid.open(). Two of them, Meta and Moloco, document that the creative must not include mraid.js at all, so shipping a generic MRAID build to them is not a harmless extra.
Why one file cannot serve every network
It is tempting to try, and the reason it fails is worth understanding rather than merely accepting. Detecting the container at runtime and branching would in principle work, but it means shipping every network's integration in every file — which costs size on a budget measured in single megabytes, and which puts forbidden code in front of validators that Meta's and Moloco's rules imply are looking for exactly that.
The workable pattern is one project, many exports: build the creative once and let the export step attach the right store exit, packaging and SDK wiring per network. That is the practical reason playable tooling is organised around a network selector rather than a single download button.
Create playable end cards in minutes—no code required.
Open Playable Ads Maker