Playable ad spec checker
Drop in a finished playable and see whether it meets the network's published requirements — size, packaging, exit call and the rules that get a creative rejected. Then run it in a simulated ad container: rotate it, restart it, tap the call-to-action, and watch which SDK calls actually fire.
Check against
Checking against Unity Ads — 5 MB cap, a single HTML file, and mraid.open(url) for the exit call.
Drop your playable here
A single .html file or a .zip archive. Nothing is uploaded — the file is read in your browser and never leaves this device.
How this works
Nothing is uploaded
The file is read in your browser using the same code the editor uses to open project files. It is never sent to a server, which means unreleased creative stays on your machine and the tool works offline once the page has loaded.
Checked against the real spec
The rules come from the same registry our exporter builds against — each one sourced to the network's own documentation with the date it was last read. There is no separate copy of the numbers to drift out of date.
Run in a simulated container
A playable expects an SDK that does not exist in a browser. We provide a stand-in for MRAID, FbPlayableAd, ExitApi and the rest, so the creative runs as it would in the container — and every call it makes is logged instead of acted on.
Honest about what it cannot see
No file inspection can tell you whether an ad is fun, whether the artwork is yours to use, or whether it runs on a four-year-old Android. Those are marked Manual rather than passed, because a checker believed on things it never examined is worse than none at all.
What gets creatives rejected
Four failures account for most rejections. Each one is checked above, and each is easier to recognise as a symptom than as a rule.
Rejected for file size, but the folder looks small
A single-file playable carries its images and audio as base64 text inside the HTML, and base64 costs roughly a third more than the bytes it encodes. Three megabytes of artwork becomes about four megabytes of document. The cap applies to the finished file, which is what this tool measures.
The ad plays perfectly but the button does nothing
Almost always the wrong exit call. Each network has its own — mraid.open on Unity and AppLovin, FbPlayableAd.onCTAClick on Meta and Moloco, ExitApi.exit on Google — and a creative built for one runs normally everywhere while only installing on the network it was built for. The event log below shows whether anything fires at all.
Upload refused before the creative is even reviewed
The wrong package shape. Moloco rejects a ZIP outright, Google and TikTok accept nothing else, and Mintegral requires the archive, its folder and the entry document to share one name. This is checked before anything else, because nothing else matters if the file cannot be opened.
Approved on one network, rejected on the next
The requirements genuinely differ. ironSource caps at 4 MB where most cap at 5. Unity scans for a store URL in the creative. Mintegral will not approve a playable that never calls gameEnd. Switching the network above re-runs every check against that network's own rules.
Every limit referenced here is listed per network on the ad network specs page, with a link to the network's own documentation.
Common questions
- Is my creative uploaded anywhere?
- No. The file is read in your browser with the FileReader API and inspected in memory. Nothing is transmitted, nothing is stored, and closing the tab discards it. You can confirm this by opening your browser's network tab while running a check, or by disconnecting from the internet after the page loads — the tool keeps working.
- Does passing every check mean my ad will be approved?
- No, and the report says so. This checks the rules that are written down and can be established by reading the file. A network's review also involves a human judging whether the ad represents the product honestly, whether the artwork is licensed, and whether it performs acceptably on real hardware. Those appear as Manual rather than as passes.
- Why does the preview need a fake SDK?
- A playable calls into an ad network's SDK, which does not exist in an ordinary browser. Without a stand-in the creative either throws on its first call and renders nothing, or silently takes a fallback path and behaves like a different ad than the one the network will serve. The stub implements enough of each contract to keep the creative running, and reports every call rather than acting on it.
- Can it check a ZIP with separate asset files?
- The checks run on any archive — size, packaging, entry document, file count and the source of every text file inside it. The interactive preview is the part with a limit: a creative whose entry document loads assets from sibling files cannot be run faithfully without rewriting every relative path, so the preview is skipped rather than shown half-loaded.
- Which networks can I check against?
- All thirteen the exporter targets: Unity, AppLovin, ironSource, Chartboost, Meta, Moloco, InMobi, TikTok, Pangle, Mintegral, Vungle, Liftoff Monetize and Google Ads. Each has its own caps and requirements, so switching the network re-runs every check rather than re-labelling the same result.
Your next playable is one afternoon away.
Open the editor, pick a format and start placing objects. Nothing to install, and nothing to pay.