VPAID vs SIMID Compares an Executable in the Player With a Sidecar Beside the Media File

VPAID vs SIMID is the comparison trafficking sheets still ask when a creative needs a click or an overlay. The IAB Tech Lab's answer is on the standards pages: VPAID is deprecated and replaced, SIMID is the interactive piece, and OMID is the measurement piece that used to be tangled inside VPAID. Google's IMA documentation draws the runtime line in public: only the HTML5 SDK supports VPAID 2 JavaScript creatives. SIMID support is documented separately. The two strings are not interchangeable values of one apiFramework attribute.

The architectural difference is who owns the video. A VPAID creative can be the playback engine. The player hands it a slot, and the unit loads its own media, draws its own controls, and emits its own events. A SIMID unit is a sidecar. The player plays a media file it selected, and the interactive document talks to that player over a defined channel. If the sidecar fails, the media file can still play. If a VPAID unit fails, there is often no separate media file left to play.

That is why "fall back to VPAID" on a CTV or SSAI tag is not a compatibility plan. Those runtimes do not want an arbitrary executable in the player, and a stitcher cannot splice an executable into a content stream the way it splices a media file. Remove the names and an executable that replaces the player is still a different object from an interactive document that sits beside a file the player already owns.

What VPAID puts in the tag

In the VAST document, VPAID usually appears as a media file whose API framework says VPAID, often a JavaScript resource. The player that supports it loads that resource and expects the VPAID interface: init, start, and a stream of events the creative chooses to emit. Quartiles and impressions can be fired by the creative rather than by the player's own playhead. Measurement code bundled inside the same executable was the historical reason verification vendors shipped VPAID. The creative, the playback, and the measurement were one object.

That object depends on a browser-like JavaScript environment. Google's IMA docs limit VPAID 2 JavaScript support to the HTML5 SDK. A television player, a native mobile player, and a server-side stitcher are outside that environment even when they play ordinary MP4. A tag that offers only a VPAID media file has not offered those platforms a file. The error the device returns is a media-file miss. The trafficking sheet still said the line item had a creative.

Deprecation does not delete old tags. IAB's label means new work should not start there, and existing work should move. A 2026 wrapper that still prefers VPAID because "some web players need it" keeps an executable on a path that also serves CTV. The web player that needed it is a shrinking set. The television that cannot run it is not.

What SIMID puts in the tag

SIMID is an interactive creative file, identified in VAST with apiFramework SIMID, alongside media the player can play without it. The player owns duration, quartiles, and the decision to start. The SIMID document loads in a sandboxed frame and exchanges messages with the player. Clicks, overlays, and other interaction go through that channel. If the frame never loads, the media file is still a media file. Measurement vendors are directed to OMID, not to code hidden inside the interactive unit.

IAB's SIMID page describes that split as the point: SIMID for interactivity, OMID for measurement, and a better fit for mobile, SSAI, OTT, and live than a single executable was. A stitcher can transcode the media file and still leave the interactive sidecar for a client that supports it, or ignore the sidecar and play the file. It cannot transcode a VPAID script into an MPEG segment and preserve the script's behavior.

The tag-level mistakes are specific. A SIMID URL that is empty, not HTTPS, or pointed at a VPAID payload will fail the players that implemented the new interface and will not revive the old one. Putting SIMID only in a nonlinear iframe when the linear creative has no media file repeats the VPAID failure mode: nothing to play if the interactive part fails. The preferred shape is a real media file plus the interactive file, with OMID in AdVerifications rather than inside either one.

Why the fallback story keeps the deprecated path alive

A fallback is supposed to widen the set of devices that can play the ad. Offering VPAID as the alternative to SIMID narrows it. Devices that run SIMID already have a media file to play if you gave them one. Devices that run neither will not run VPAID either, if they are televisions and native apps. The only runtime that uniquely wanted VPAID was a browser SDK, and that SDK's vendor now documents SIMID on its own page.

Measurement is the part people smuggle back in. A VPAID unit that "also does viewability" feels like one tag instead of two. The replacement is two explicit nodes: the media file, and an OMID verification. Collapsing them again into an executable recreates the security and the SSAI problems VPAID created, in exchange for a shorter trafficking form. The form is not the measurement. OMID in AdVerifications is the measurement. A script that happens to emit a quartile is a creative claiming it played.

Wrappers hide the choice until the last hop. The wrapper you QA can look like a simple MP4. The inline it fetches can be VPAID-only. Or the inline can be SIMID with a broken media file and a healthy interactive URL. Hop-one inspection that stops at the wrapper will bless both. The comparison that matters is in the inline the player or the stitcher finally parses.

What to do with the two frameworks

Treat VPAID as a legacy web path you still have to detect, not as a format you add for safety. New tags get a playable media file, SIMID only when there is a real interaction, and OMID when a vendor must measure. If a screen does not need interaction, it does not need either framework. The media file is the ad.

On old tags, find every MediaFile and InteractiveCreativeFile whose apiFramework is VPAID or SIMID, and check that a non-executable file remains. A SIMID file with no sibling media file is the VPAID shape wearing the new name. A VPAID file as the only media file is the shape televisions already drop.

vastlint checks those structures for VAST 2.0–4.4: apiFramework values, secure URLs, and whether a linear creative still has something a player can render. It does not execute VPAID and it does not open a SIMID session. The check is there so a deprecated executable is visible before a CTV player is the first system to refuse it.

What to look for in the inline

• A media file the player can decode without loading JavaScript.
• SIMID only as an interactive file beside that media, when interaction is actually required.
• OMID in AdVerifications, not inside the creative executable.
• Any remaining VPAID media file, treated as legacy web compatibility rather than as a CTV fallback.
• The inline after wrappers, not the wrapper you were handed in QA.