Playable Ad Specs: Requirements by Ad Network

A playable ad can be brilliant creatively and still get rejected in minutes because it’s 300 KB over a size limit or opens the store the wrong way. Every ad network has its own playable ad specs, and they overlap just enough to make you assume they’re identical. They aren’t. This guide covers the requirements most networks share, then walks through what tends to differ network by network.

Network specs change regularly. The limits below reflect what is commonly documented at the time of writing. Always check each network’s current creative documentation before you ship.

The baseline: one self-contained HTML file

Most networks expect a playable to arrive as a single HTML file with everything inlined: JavaScript, CSS, images (usually as base64 data URIs), audio and fonts. A few — Google, TikTok/Pangle, Vungle and Mintegral among them — want a zip archive with an entry HTML file instead. Either way, the ad must run completely offline once it’s loaded.

• No external requests. Don’t load scripts from a CDN, fetch JSON from an API or pull images from a server. Many networks reject creatives that make network calls, and the ones that don’t may serve the ad in an environment where those calls fail. (The exception is a network’s own required script, such as Google’s Exit API or TikTok’s playable SDK.)
• No dependency on cookies or local storage. Treat every session as a fresh, sandboxed WebView.
• Self-contained fonts. Embed what you need or fall back to system fonts.

MRAID: what it is and why it matters

MRAID (Mobile Rich Media Ad Interface Definitions) is an IAB standard that lets an HTML ad talk to the app hosting it. For playables, the parts that matter most are:

• Readiness: wait for the ready state (or check mraid.getState()) before starting the experience, so audio and animation don’t begin before the ad is visible.
• Viewability: listen for viewableChange to pause and resume gameplay correctly.
• Store redirect: call mraid.open(storeUrl) instead of window.open or setting location.href. This is the single most common reason playables fail review.
• Orientation and size: read mraid.getMaxSize() and listen for size changes rather than assuming a fixed viewport.

Most networks that support MRAID work with MRAID 2.0 or later. Some networks don’t use MRAID at all and provide their own JavaScript call for the CTA instead, which is why a “universal” build usually needs a thin adapter layer per network.

File-size limits

Size is where most rejections happen. Many networks commonly cite a limit of around 5 MB for the final file, while some have historically been stricter. Because base64 encoding inflates binary assets by roughly a third, a folder of images that looks small on disk can blow past the limit once inlined.

• Compress textures aggressively and prefer WebP where the target WebViews support it.
• Use short, mono, low-bitrate audio, or skip audio entirely for networks where most impressions start muted.
• Reuse sprite sheets instead of shipping separate frames for every animation.
• Budget for your smallest target network, then you only build once.

CTA and store redirect handling

Every playable needs a clear call to action, and every network has opinions about how it fires. A few rules apply almost everywhere:

• Only redirect on a deliberate user tap on a CTA. Auto-redirects and “tap anywhere” traps are commonly rejected.
• Use the network’s required method (MRAID open, or the network’s own function) and never hard-code a navigation.
• Pass the correct store URL per platform; detect iOS vs Android at runtime if you ship one file for both.
• Keep a visible CTA on the end card, and many teams also show a persistent install button during gameplay.

Orientation and layout

Most networks expect playables to work in both portrait and landscape, or at least to handle rotation gracefully. Build a responsive layout that re-flows on resize, keep tap targets inside safe areas, and test on very tall and very short aspect ratios. If your game only makes sense in one orientation, show a “rotate your device” prompt rather than a broken layout.

Network-by-network notes

Here’s a summary of how the major networks commonly handle playables at the time of writing. Treat it as a starting checklist, not a source of truth.

AppLovin, Unity Ads and ironSource

These three are the closest to a shared standard: single HTML and a size limit commonly cited around 5 MB. AppLovin and Unity redirect through MRAID; ironSource’s playable product uses its own DAPI interface, with MRAID on the exchange side, so check which one your account’s setup expects. AppLovin and ironSource both offer preview or test tools that are worth running before submission.

Meta

Meta does not use MRAID for playables. The CTA is triggered through a Meta-provided JavaScript function, and the size limit has historically been tighter than other networks. Meta also tends to be strict about external requests and about how the end card is presented, so use its playable preview tool before uploading.

Mintegral and Moloco

Both accept HTML playables. Mintegral uses its own install() and gameEnd() calls and wants the zip, folder and HTML named identically; Moloco, despite being a DSP, uses Meta’s FbPlayableAd.onCTAClick() and rejects mraid.js. Confirm the current size ceiling with your account manager.

Google

Google commonly expects an HTML5 zip archive rather than a single file, and the store redirect goes through Google’s Exit API rather than MRAID. There are also limits on file count and on which file types can be included, so a build that works elsewhere often needs repackaging.

TikTok

TikTok also commonly uses a zip format, with a configuration file describing the creative, and the CTA is handled through TikTok’s own SDK call. Check its current playable guidelines for orientation and size requirements.

A pre-submission checklist

1. The file runs with the network disabled and makes no external requests beyond any script the network itself requires.
2. The final file size is under the strictest target network’s limit.
3. The store opens only via the network’s required method, after a real tap.
4. Portrait and landscape both render correctly, including rotation mid-session.
5. Audio is muted or quiet by default and respects viewability changes.
6. The experience pauses when the ad is hidden and resumes cleanly.
7. You’ve tested in each network’s preview tool, not only in a desktop browser.

Exporting without rebuilding for every network

Maintaining eight slightly different builds by hand is where most teams lose time. At PlayableTower, playables built as a Custom Playable, from one of our Instant Playables or with the Playable Wizard export to 16 ad networks, including AppLovin, Unity Ads, ironSource, Meta, Mintegral, Google, Moloco and TikTok, with the network-specific packaging and CTA handling applied at export. Store links are set from the client panel, so you don’t have to touch code to point a build at the right listing.

Want to see a playable exported for your networks? Book a demo and we’ll walk you through the export flow.