SIMID vs OMID lines up a sidecar and a measurement script

SIMID vs OMID is the pair people collapse because both names arrived when VPAID was split. IAB Tech Lab's SIMID page says the replacement is two standards: OMID for measurement and verification, SIMID for interactivity. SIMID is an interactive document beside a media file the player owns. The player loads it in a sandboxed frame and talks to it over a defined channel. OMID is the API a verification script uses once the player has OM SDK. In the tag, that script is a JavaScriptResource with apiFramework omid, inside AdVerifications on VAST 4.1 and later.

They are not two legal values of one attribute. A SIMID URL in the verification node does not measure the impression. An OMID script in InteractiveCreativeFile does not draw the overlay. vastlint checks that split in the VAST 2.0–4.4 document: the interactive file against a real media file, and the verification node a measurement script would have to occupy. It does not open a SIMID session and it does not run OMID.

What each one does when the other fails

If the SIMID frame never loads, the media file is still a media file, provided you gave the player one. Duration and quartiles stay with the playhead. The click layer is gone. That is a failed interaction, not a failed ad, and it is the reason the sidecar exists. If the OMID script never loads, the media file can still play and the SIMID layer can still take a click. The impression is then unmeasured. verificationNotExecuted is the VAST path for that miss. A quartile pixel is not a substitute for it.

IAB's OM SDK page, updated November 4, 2025, lists OMID 1.6 as the current API docs and still documents earlier versions. SIMID 1.2 is the iteration described on the SIMID page. vastlint does not implement either API. A tag can be structurally ready for both and still fail in a player that has no OM SDK, or in a player whose SIMID support stops at a subset of messages. Google's IMA HTML5 guide documents that subset on its own page, separate from VPAID.

The tag-level swaps that look like a migration

The common miss is a single apiFramework cell copied onto the wrong element. SIMID belongs on InteractiveCreativeFile, with type text/html, next to a MediaFile. OMID belongs on the verification resource. Putting either string on a MediaFile and deleting the playable file recreates the VPAID failure: if the script does not run, nothing plays. Putting both jobs inside the interactive file, the way VPAID bundled them, hides measurement in a document the stitcher may ignore.

Wrappers hide the choice until the last hop. The wrapper can look like a plain MP4. The inline can be SIMID with a broken media file, or OMID with an empty resource URL. The comparison that matters is the inline the player or the stitcher finally parses. The two nodes in a VAST 4.3 inline look like this. browserOptional on JavaScriptResource is the 4.3 attribute. Earlier 4.1 and 4.2 documents use the same parent elements without it.

What to look for in the inline

• A media file the player can decode without the interactive frame.
• SIMID only on InteractiveCreativeFile, and only when interaction is required.
• OMID only on the verification resource, inside AdVerifications or a legacy Extension of that type.
• No VPAID media file standing in for either half.
• The inline after wrappers, not the wrapper from QA.