Playable Ad Spec Checker

No. The file is read, unzipped and analysed entirely inside your browser using JavaScript — there is no upload step and no server behind this page. You can confirm it by opening your browser's Network tab while you run a check: no request carries your file. This matters because playable creatives are usually a client's unreleased campaign asset.

A single .html file or a .zip archive — the two things ad network dashboards accept, from any tool. Inside a ZIP every text file is read wherever it sits, including scripts nested under folders, because the store-exit call usually lives in a separate .js rather than the HTML. The entry document is found by convention where one exists and by structure where it does not, so no particular filename or layout is assumed.

No. A network shows Pass whenever the upload would be accepted as it stands, and any amber lines underneath are optional improvements: a missing viewport tag, a missing mraid.js on a network that expects one, or a file larger than we would ship even though it is inside the published limit. Only a Fail blocks — that means the upload would be rejected in the shape it is in, because it is over the published size cap, missing that network's store-exit call, packaged in a format the network does not take, or carrying mraid.js where the network forbids it.

All 13: Unity Ads, IronSource / LevelPlay, AppLovin MAX, Chartboost, InMobi, Vungle (Liftoff), Google Ads / AdMob, Meta (Facebook & Instagram), Moloco, Mintegral, TikTok Ads, Pangle, Liftoff. Pick any one or several. Each figure used is taken from that network's own published documentation, and every result card links to the source page so you can check it yourself.

Because a playable targets one container at a time, and the rules genuinely differ. A Unity build calls mraid.open(); a Google build calls ExitApi.exit(); Meta and Moloco forbid the mraid.js tag that Unity requires. Grading every file against all thirteen buried the real answer under irrelevant failures, so you tell the checker where this creative is going and it answers that question. Your selection is pre-filled from the store-exit calls found in the file, and you can change it at any time — the report re-grades instantly.

No, it is a warning. On Unity, IronSource, AppLovin, Chartboost and Vungle the tag is expected, but it is a hook the container fills with its own SDK at serve time rather than a working dependency, and adding it is a one-line change — a file without it is usually a web-preview build rather than a broken creative. The reverse is a failure: Meta and Moloco both document that the creative must NOT include mraid.js, so shipping it to them is a real defect.

It means the HTML references an image, font, script or stylesheet by an http(s) URL instead of embedding it. Ad containers run playables in a sandboxed webview that blocks outbound requests, so the asset never loads and the ad renders broken or blank. Every major network rejects this at review; the fix is to inline the asset as a base64 data URI.

No. This is static analysis — it reads the file without running the ad, so it catches disqualifying problems visible in the source: size, external requests, a missing store exit, no viewport tag. It cannot judge creative quality, gameplay authenticity or policy compliance, and it is not the network's own validator. Read a clean report as 'nothing disqualifying is visible', not as approval.

Most likely your CTA opens a store URL directly with window.open, which works in a browser preview but never reports the click to the network. The checker looks for the specific call each container provides — mraid.open(), ExitApi.exit(), FbPlayableAd.onCTAClick(), window.install(), window.openAppStore(), or a postMessage bridge. It also cannot see a call assembled from string fragments at runtime, so a heavily obfuscated build may report a false negative here.