What do Vungle, Chartboost and InMobi have in common?

All three are MRAID networks: they expect a tag and wait for MRAID before starting. Chartboost and InMobi take the store exit on mraid.open(); Vungle takes a "download" message posted to its container. One creative concept covers all three, with packaging, the exit call and size being the differences that matter.

What size should a creative be for all three?

Vungle and InMobi publish 5 MB for playables. Chartboost publishes no strict cap at all — its documentation recommends keeping the playable under 5 MB rather than enforcing a number. Because "recommended" is not a guarantee of acceptance, Playable Ads Maker holds Chartboost exports to 3 MB internally, which is a conservative choice on our side rather than a figure Chartboost publishes.

How should you package a Vungle playable?

Vungle expects a ZIP with the HTML entry point (ad.html) at the archive root; Chartboost and InMobi take a single HTML file. Since the packaging differs but the creative does not, build once and export three times rather than rebuilding per network — and size the creative for the tightest budget you plan to serve, so the same source clears all three without a second compression pass.

Which MRAID version does InMobi use?

InMobi's specification calls for MRAID 3.0, with mraid.js in the head, the ad waiting for viewableChange before it starts, and mraid.open() for the store redirect. Builds that follow whichever viewability signal the container actually fires are safer than ones that branch on a version number.

Vungle, Chartboost & InMobi Playable Ads: Export Guide

Most playable ad guides cover Google, Meta, Unity and TikTok, then stop. Vungle, Chartboost and InMobi carry real volume, especially for mid-core titles and non-gaming advertisers, and their requirements differ in ways that cause avoidable rejections. This guide covers what is distinct about each. Current specs: Vungle, Chartboost and InMobi playable ad specs.

What the three have in common

All three are MRAID networks. That means your creative waits for MRAID before assuming it exists and respects viewability before starting content. Chartboost and InMobi take the click on mraid.open(url); Vungle is the exception, with its store exit a "download" message posted to its container. If you have built for Unity, the mental model transfers directly, which is not true of Google, Meta or Mintegral, all of which own the click and take no URL. All three also take an interactive end card after a video, built to the same rules as a playable.

All three also enforce the usual rules (everything embedded, nothing fetched at runtime) but their size guidance differs: Vungle and InMobi publish 5 MB, while Chartboost publishes no strict cap and recommends staying under 5 MB. Check each network's current documentation rather than assuming one number covers them all.

Vungle (Liftoff Monetize)

Vungle is now part of Liftoff, as Liftoff Monetize, and its playable submission requirements are among the more prescriptive. The notable one is packaging: a ZIP with ad.html at the archive root (it also accepts a bare HTML file). A slightly wrong archive, with the entry file one directory down because your zip tool included the containing folder, is a common rejection with an unhelpful error.

Packaged as a ZIP with ad.html at the archive root, not inside a subfolder.
MRAID-based, but the click-through is parent.postMessage('download','*'), not mraid.open.
A playable also posts 'complete' after real play (three or more interactions), never on the click; an end card posts 'download' only.
All assets inlined; no runtime requests.
Test the archive by extracting it fresh: if the first thing you see is a folder rather than the entry file, it is wrong.

The ZIP-root mistake

On most systems, right-clicking a folder and choosing "Compress" wraps the folder inside the archive. Networks that require the entry file at the root will reject that structure. Select the files themselves, not the folder containing them.

Chartboost

Chartboost publishes no strict size limit for an MRAID playable; its exchange documentation, which is what remains published after its advertiser pages moved in the LoopMe acquisition, recommends staying under 5 MB. Playable Ads Maker holds Chartboost exports to 3 MB as a safety margin of its own; that figure is ours, not Chartboost's. The creative must not draw a close button of its own, since Chartboost adds one, and an MRAID end card starts hidden after a video, so it has to wait until it is on screen.

MRAID Playable format; mraid.open for click-through.
No published size cap; Chartboost recommends under 5 MB. Smaller still loads faster between game rounds.
Single self-contained HTML, fully inlined.
Ensure the creative handles the MRAID ready and viewability events rather than starting on page load.

InMobi

Of the three, InMobi matters most to non-gaming advertisers. Unlike networks assembled primarily for game publishers, InMobi runs broad inventory across shopping, finance, travel, entertainment and lifestyle, with interest targeting that spans those categories. That matters for a fintech or retail playable: the same creative on a game-centric network often buys cheap installs that never convert, because the audience was built for game advertisers.

MRAID 3.0 with mraid.js in the head; mraid.open with a store or tracking URL.
Standard single-file, fully-inlined requirements.
Non-gaming interest targeting sets it apart from purely game-focused networks.

Testing across all three

One QA pass covers all three. Run it once before submitting anywhere rather than once per network. Open the exported build on real iOS and Android devices, record the network tab through a complete playthrough and confirm zero external requests, check the file or archive against that specific network's ceiling, verify the archive structure where a ZIP is required, and tap the CTA on both platforms to confirm the right store listing opens.

Where the effort actually goes

None of these requirements are individually difficult. The cost is that they differ per network and must be reapplied to every revision of every creative. Producing the correct packaging, click call and size handling automatically per network is the difference between three submissions and three rounds of rejections.

Choosing between them

For mobile games, Vungle and Chartboost sit naturally alongside Unity and AppLovin in a mediation-heavy buying strategy. For non-gaming apps, InMobi and Moloco are usually the more productive additions to Meta and TikTok. Running one creative across the mix is sensible, as long as the file passes the strictest constraint in the set, not the most generous.

How mediation changes what you should submit

All three of these networks are commonly bought through mediation rather than in isolation, and that has a practical consequence for creative. Your ad competes in the same auction as creatives from advertisers who have optimised for that specific inventory. A creative built to the loosest common denominator (heavy, slow to first frame, portrait-only) competes badly not because it is rejected but because it wins less often and performs worse when it does.

Load time is a real competitive variable. A lighter creative reaches its first interactive frame sooner, and the opening seconds are where playables win or lose.
Covering both orientations widens the pool of placements you can win rather than improving any single one.
Rewarded placements behave differently from interstitials: the user has opted in and will tolerate a longer experience, so the same creative can underperform in one and do well in the other.

A build order that avoids rework

When shipping one creative to several of these networks, the order you work in matters more than it looks.

Identify the strictest size ceiling among your target networks and build to it. Retro-fitting a creative down from a looser limit means recompressing art after the design is signed off, which usually costs quality.
Build and test the MRAID click path once (it is shared across all three) then verify per network in their own preview tools.
Produce the packaging shapes last, and extract each archive fresh to confirm the structure before submitting.
Submit to the strictest network first. Passing there is a strong signal for the rest; passing a permissive one tells you almost nothing.

Keep a per-network note

Current figures for size ceilings and packaging move, and the published documentation is not always in step with what review enforces. A short internal note of what each network actually accepted, updated when something is rejected, is worth more than any external guide including this one.

Create playable end cards in minutes—no code required.

Open Playable Ads Maker

Check a build against these specs

The free Playable Ad Spec Checker grades an HTML or ZIP against every network’s size cap, packaging, MRAID rules and store-exit calls. It runs entirely in your browser — no upload, no sign-up.