Vungle playable ads: requirements, formats, and the errors that get creatives rejected

Vungle, now Liftoff Monetize

Vungle was acquired by Liftoff in 2021, and its ad network business now operates under the "Liftoff Monetize" brand. Depending on where you look, you'll see either name — some SDK references and legacy docs still say "Vungle," newer material says "Liftoff Monetize." For playable-creative purposes they're the same integration: the same HTML5 spec, the same size cap, the same click-through mechanism carried over rather than rebuilt from scratch. PlayableKit labels this network target Vungle (Liftoff) for exactly that reason. For the specific step-by-step workflow of taking a raw Playworks/Luna export through this pipeline, see our dedicated Playworks/Luna-to-Liftoff export page; this page is the broader spec reference.

Technical requirements

These are the non-negotiable rules a creative has to satisfy before Vungle's review pipeline will accept it:

• Single self-contained HTML file. The deliverable is one .html file, not a ZIP archive with a folder structure. No companion JS, CSS, image, or audio files sitting alongside it — everything lives inside that one document.
• 5 MB maximum. The complete file — markup, inline script, and every embedded asset combined — has to come in at or under 5 MB. There's no separate "recommended" ceiling below that for Vungle; 5 MB is the hard number.
• All assets embedded, no external requests permitted. Every image, audio clip, font, and any library code the playable depends on must be inlined directly into the HTML — typically as base64-encoded data URIs decoded at runtime. Loading anything from an external URL — a CDN-hosted image, a remote font, an analytics beacon — is prohibited, not just discouraged. Vungle's rendering environment often has no network access at all when the ad is served, so an external request doesn't just violate policy, it fails silently at runtime.
• Primary CTA fires window.parent.postMessage('download','*'). This is the click-through call Vungle's ad container listens for. It should fire once, on user interaction with the CTA element — not automatically, and not repeatedly.
• MRAID mraid.open(url) as the fallback. Some Vungle rendering contexts, and some mediation setups routing through MRAID-based SDKs, expect the standard MRAID open call instead of postMessage. A compliant creative wires both, so the click registers regardless of which container actually renders the ad.
• No audio autoplay. Sound cannot start before the user has interacted with the ad. Muted autoplay for background music, then unmuting on tap, is the usual workaround if the creative needs audio from the first frame.

None of this is unique to Vungle in isolation — AppLovin, Meta, and Unity Ads all require the same single-file, fully-embedded structure. What's specific to Vungle is the click-through call. Wiring an MRAID-only handler with no postMessage listener (or the reverse) is one of the most common reasons a creative that renders and plays fine in a desktop browser still gets bounced during network review: the click simply never registers in Vungle's container.

Accepted formats

Vungle's playable format is HTML5 — a single .html document is the only format its pipeline accepts. There's no support for a ZIP bundle with a manifest, no separate video-plus-endcard package, and no native/SDK-rendered format for this creative type. If your source build is a Unity Playworks/Luna export, or anything else that produces multiple files (an HTML entry point plus separate asset folders), that output has to be collapsed into one file before it's a valid upload — a ZIP with an index.html inside it, even a well-structured one, isn't the deliverable Vungle's spec calls for.

Size limits in practice

The 5 MB ceiling applies after every asset is embedded, not before. This matters because base64 encoding — the standard way to inline binary assets into an HTML file — inflates raw asset size by roughly a third. A build that measures comfortably under 5 MB as separate image, audio, and video files on disk can land right at, or past, the cap once those same assets are converted to data URIs and pasted into the document. The number that matters is the size of the actual file you upload, not the pre-encoded source files.

Common upload errors

• Click doesn't register in review. By far the most common failure — usually a CTA wired only to a custom click handler, an MRAID-only implementation with no postMessage listener, or a click-through call that fires on page load instead of on tap.
• External request detected. A URL pointing at a hosted image, a Google Font link, a CDN-hosted library, or a leftover tracking pixel. Vungle's scanners specifically check for outbound network calls, so any one of these can trigger an automatic rejection.
• File exceeds the size cap. Almost always the base64-inflation issue above — a build that looked fine pre-encoding crosses 5 MB once assets are inlined.
• Multiple files submitted instead of one. Uploading the raw multi-file export (HTML plus an assets/ folder) rather than a single merged HTML document.
• Audio starts before interaction. Background music or a sound effect firing on load rather than waiting for a tap — flagged during manual review even when it passes automated checks.
• Broken state after asset encoding. Converting dozens of images and audio clips to base64 by hand is error-prone — one malformed data URI or truncated string can leave the playable rendering a blank frame even though it worked locally.

Best practices

• Wire both click-through calls — postMessage as primary, MRAID open as fallback — rather than betting on which container Vungle uses to render your placement.
• Encode assets last, right before packaging, and re-measure the final file size after encoding rather than trusting the pre-encoded total.
• Keep source assets as compressed and low-resolution as the creative can tolerate before encoding — every kilobyte saved pre-encoding saves roughly 1.3 kilobytes post-encoding.
• Test the exported HTML file in a browser with network throttling or airplane mode on, to catch any external request the playable silently depends on before a reviewer does.
• Gate all audio behind a user-interaction check rather than relying on browser autoplay policy alone to block it.

Export a Playworks/Luna build for Vungle with PlayableKit

If your source build comes out of Unity Playworks/Luna, none of the above has to be done by hand. Upload the export ZIP to PlayableKit, select Vungle (Liftoff) as a build target, and it produces a single vungle.html file with every asset embedded, the CTA wired to postMessage('download','*') with an MRAID fallback, and the result checked against the 5 MB cap before you upload it to Vungle's dashboard. The same source export can be built for Google Ads, Meta, AppLovin, Mintegral, TikTok, and Unity Ads at the same time, each packaged to that network's own rules. For the full step-by-step walkthrough, see Export Unity Playworks/Luna to Liftoff (Vungle).

Vungle/Liftoff builds are available starting on the Studio plan; the entry-level Starter plan covers Google Ads, Meta, AppLovin, and Unity Ads only. Check current plans and network coverage before you plan a Vungle release around a Starter account.