How to measure your playable ad's real size before submitting

Why "check the ZIP size in Finder/Explorer" is misleading

The file size your OS shows you is the size of the archive you're about to upload. What a network actually evaluates is the converted output it unpacks from that archive — and those two numbers are frequently not close.

Two things move the number in opposite directions during conversion:

• Base64 inflation. Networks like AppLovin, Meta, Unity Ads, and Vungle require a single self-contained HTML file with zero external requests — every image, audio clip, and font has to be embedded as base64 (or base122) data rather than referenced by a relative path. Base64 encoding itself adds roughly 33% overhead on top of each asset's raw bytes, and once everything is inlined into one HTML document, a build that looked comfortably under budget as a ZIP can land meaningfully larger after conversion.
• Cache and asset trimming. A raw Playworks/Luna export sometimes carries unused cache generations or engine files that a real conversion pipeline drops. So it can also go the other way — a converted single-HTML file coming out smaller than the ZIP you dragged in.

Either direction, the raw upload size doesn't reliably predict the number a reviewer's tooling will actually check. For more on why the base64 step specifically inflates things, see how base64 encoding inflates file size, and for what happens once you're over budget, see what to do when a playable ad exceeds the 5 MB limit.

Why per-network measurement matters

"Is my playable under 5 MB?" isn't a single question with a single answer — because "5 MB" isn't even the same rule everywhere, and the packaging that gets measured isn't the same shape everywhere either.

Google and Mintegral let you keep assets loaded from files inside a ZIP; AppLovin, Meta, Unity Ads, and Vungle require every asset to be embedded inline in one HTML document — which is exactly the packaging shape that triggers base64 inflation. The practical result: the same source build, run through two different network conversions, produces two different byte counts. A build can pass Google's ZIP-based limit comfortably and still land over Meta's recommended 2 MB once everything is inlined. There is no single "size" for a playable — there's a size per network.

How the free Size Checker actually measures this

PlayableKit's free Size Checker doesn't estimate anything from your uploaded ZIP. When you drop in your Playworks/Luna export, it spawns the same conversion engine PlayableKit uses for paid builds into an isolated temporary directory, runs your build through the real per-network packaging step, and reads the resulting conversion-report.json that conversion actually produces.

What comes back for each network is a real measured result — network name and label, the actual output byte count, that network's actual maxBytes ceiling, a pass/fail against it, and any findings from the conversion itself. Nothing in that response is inferred from your raw upload; it's the output of running the real conversion, discarded afterward, for every supported network in one pass.

How to read and act on the results

Each network row shows a bar filled to the percentage of that network's limit your converted output actually used, plus the two raw numbers — your real bytes and that network's real ceiling — so you can see margin, not just a pass/fail badge. A network sitting at 90% of its limit today has much less room for the next asset update than one sitting at 40%, even if both currently pass.

If a network fails, the fix is almost always the same: trim or compress the heaviest assets (audio and images first, since they dominate the base64-inflated total), then re-run the check rather than guessing. Because the checker runs the real pipeline, a re-check after trimming tells you definitively whether you're now under budget for that specific network — no need to submit and wait on network review to find out.