Playable ad compression and size limits, explained honestly

Why size limits matter

Ad networks enforce a hard file-size ceiling on playable creatives, and it's not a soft warning — a build that exceeds the limit gets rejected outright during upload or review, with no partial credit for being "close." Most networks land on 5 MB as that ceiling, which sounds generous until you account for how the creative actually gets packaged.

A Unity Playworks/Luna export references most of its assets by relative path or loads them from a local cache at runtime. Several networks — AppLovin, Meta, Unity Ads, Vungle, TikTok — don't allow that. They require a single, self-contained file (or a package with no external requests) with every image, audio clip, and binary asset embedded directly in the HTML. The standard way to embed arbitrary binary data in text-based HTML/JS is base64 encoding, and base64 is not free: it turns every 3 bytes of source data into 4 bytes of encoded text, an overhead of roughly 33%. A source asset set that was comfortably under budget as raw files can cross the line once it's base64-encoded for delivery.

That's the core tension behind most "why did my build get rejected for size" questions: the number that matters isn't your raw export size, it's the size of the encoded, network-ready package — and those two numbers are often meaningfully different.

The real size ceilings, per network

These are the actual limits PlayableKit checks a converted build against, taken directly from its per-network specification:

Every network in this list uses the same 5 MB hard number — there isn't a network with a materially different byte cap. Where they actually differ is in what counts against that number: a ZIP for Google or Mintegral can spread assets across multiple files, while AppLovin, Meta, Unity Ads, and Vungle require everything — including runtime code and every embedded asset — inside one single HTML file. Meta and Unity Ads both explicitly recommend staying nearer 2 MB even though 5 MB is the hard limit, since network-side review and rendering tend to get less forgiving as you approach the cap.

What actually causes an oversized build

• Unoptimized source assets. Full-resolution PNGs where a compressed JPEG or WebP would do, uncompressed WAV audio instead of a compressed format, or texture atlases sized for a much larger canvas than the playable ever renders at — these are usually the single biggest contributor to an oversized build, and they originate in the Unity project, not in any conversion step.
• Base64 inflation. As covered above, embedding binary assets as base64 text adds roughly a third to their size. A build that's just under 5 MB as raw files can land well over it once every asset is inlined for a network that requires it.
• Embedded video or audio that wasn't compressed at the source. Video in particular is dense — even a few seconds of uncompressed or lightly compressed video can dwarf every other asset in the build combined. If a playable embeds video or a longer audio clip, the bitrate and codec settings chosen when that asset was exported from Unity matter far more than anything downstream.
• Leftover or unused assets. Textures, sounds, or scene data left over from earlier iterations of the creative that never got stripped out before export still get packaged and counted against the limit.

Reducing size before you convert

This is asset-level work that happens in Unity, before export — no conversion step downstream can undo an oversized source asset. Some general, network-agnostic advice:

• Pick the right image format and compression. Use JPEG for photographic content, PNG only where you genuinely need lossless or alpha, and check your Unity texture import settings — compressed texture formats and reasonable max sizes for the target canvas usually cut asset size substantially with no visible quality loss at playable dimensions.
• Compress audio and keep clips short. Lower bitrate, mono instead of stereo for effects and voiceover, and trimming silence or unused portions of a clip all reduce size directly. Playables rarely need audio fidelity beyond what a modest bitrate provides.
• Trim unused assets before export. Remove textures, audio, and scene objects that aren't actually referenced by the playable's runtime path. It's easy for a project that went through several creative iterations to still be carrying assets nobody uses anymore.
• Be deliberate about video and animation. If the playable includes embedded video, re-encode it at the lowest bitrate and resolution that still looks acceptable on a phone screen — the format's efficiency at the source matters more than anything applied after the fact.

This is the part that stays the developer's job. PlayableKit's converter packages a build correctly and measures it accurately, but it isn't an image or audio re-compression tool, and it doesn't quietly shrink your source assets on your behalf. It re-encodes Unity's already-compressed asset cache for browser-safe delivery (decoding Luna's brotli-compressed cache and re-encoding it for the runtime decompressor each network's webview actually supports reliably) and, where a network's spec allows it, uses a slightly more space-efficient encoding than plain base64 for embedded media — but neither of those steps makes an oversized JPEG or an uncompressed audio clip smaller. If your source assets are heavy, the converted output will be heavy too.

How the free Size Checker actually helps

PlayableKit's Size Checker doesn't estimate anything from your raw upload. It runs your Playworks/Luna export through the same conversion engine used for paid builds, in an isolated temporary directory, once per network — and reads the real, resulting file size from the actual conversion report for each one. That's the number that gets compared against the real per-network cap in the table above, and it's the same number a network's own upload would measure.

That distinction matters because raw upload size is not a reliable predictor of converted size — it can go either direction, depending on how much of your export is unused cache versus how much base64/base122 inflation a given network's encoding rules add. The Size Checker tells you, honestly, whether a specific build will pass or fail for each network before you spend time submitting it for review. What it can't do is reach into your Unity project and make your textures or audio smaller — that part is still on you, using the advice above.