Two numbers, two different jobs
Meta's technical spec for a self-contained playable states it plainly: "Single self-contained HTML file, 5 MB or smaller (2 MB recommended)." That's the exact note from Meta's own limits — not a rounded-off summary. Read closely, it's doing two jobs in one sentence:
- 5 MB is the hard technical cap. It's an upload gate. Cross it and the file is rejected outright — the same way any other structural violation (external network calls, a missing CTA handler) would be. There's no partial credit for being close.
- 2 MB is Meta's own recommendation. It's not enforced at upload, and a 4.5 MB build will pass review exactly as cleanly as a 1.8 MB build does. But "passes review" and "performs well in the feed" are not the same claim, and Meta is explicit that the recommendation exists for the second one, not the first.
This is a distinction worth being precise about, because it's easy to read "5 MB or smaller (2 MB recommended)" as marketing filler and optimize only against the number that gates upload. Meta wouldn't publish a separate figure if it didn't materially change the outcome once the ad is actually running.
| 5 MB | 2 MB | |
|---|---|---|
| What it is | Hard technical ceiling | Meta's stated recommendation |
| Enforced at upload? | Yes — exceed it, get rejected | No — not a rejection trigger |
| What it protects | Whether the ad is accepted at all | Load time and delivery performance in the feed |
| Right way to treat it | The absolute ceiling, not the target | The actual target to build toward |
Why load time matters specifically in Meta's feed
A playable ad in Meta's feed isn't opened deliberately the way an app is — it's scrolled past. The user is moving through a feed at speed, and the playable has a narrow window to load, render its first interactive frame, and give the user a reason to stop scrolling. If that window closes before the creative is ready, the impression is effectively wasted: the user has already moved on before there was anything to respond to.
File size is the most direct lever on that window. A single self-contained HTML file at 4.5 MB has to be downloaded and parsed by the webview in full — there's no progressive loading, no lazy-loaded assets, because Meta's own spec prohibits external requests and requires everything embedded inline. Every extra megabyte is time the user spends looking at a blank or half-rendered ad instead of an interactive one, and on a cellular connection or a mid-tier device, that gap is not trivial. A 1.8 MB build clears that hurdle with room to spare; a build sitting near the 5 MB ceiling is spending its entire size budget on the one thing Meta actually measures for delivery: how fast it shows up ready to play.
This is also why a creative can pass review at 4.5 MB and still underperform one built at 1.8 MB in the exact same placement. Review checks whether the file is structurally valid and under the hard cap. It does not — and can't — grade how a slow load translates into lost impressions once the ad is actually serving. That feedback shows up later, in delivery metrics, not at upload.
Practical targets
- Build toward 2 MB. Treat it as the real target, not a nice-to-have — it's the number Meta itself ties to feed performance, and it leaves headroom if a later asset addition pushes the build up slightly.
- Treat 5 MB as the ceiling, not the goal. Getting a build "under 5 MB" is the minimum bar to avoid rejection. It is not evidence the build is sized correctly for how Meta's placement actually works.
- Re-check after every asset change. A build that sat comfortably at 1.9 MB can drift toward 3 MB after one new texture or a slightly longer audio clip, especially once inline base64 embedding — which Meta requires — adds its own overhead on top of the raw asset weight.
- Don't rely on the source export's file size. The number that matters is the size of the final, embedded, Meta-specific HTML file, not the raw Unity Playworks/Luna ZIP it came from.
Check your real size before you upload
The only way to know where a build actually lands between 2 MB and 5 MB is to measure the converted, network-specific output — not estimate from the source files. PlayableKit's free Size Checker runs your export through the same conversion used for Meta specifically and reports the real resulting byte size, so you know whether you're sitting comfortably near the 2 MB target or quietly creeping toward the 5 MB ceiling before a network ever sees it.