How to Hit Playable Ad Size Targets: Why Smaller Wins

Size caps differ by network: Meta holds the index.html inside its ZIP to 2 MB, most other networks publish 5 MB, and a few publish no figure at all. The current figure for each network, with the documentation it came from, is in the playable ad size limits by network table. This post is about the number you should actually build to, which is far lower. A 4.9 MB creative and a 450 KB creative can both be 'compliant', and they play very differently. On a mid-range Android phone on LTE, a 5 MB file takes 3–6 seconds to load. Half a megabyte loads in under a second. You see that gap in viewability and interaction rates.

Why the Cap Is the Wrong Target

A network's cap is the point at which it rejects the file; it says nothing about how well the file performs below that point. Build to the strictest cap among the networks you are shipping to, measure the thing each network measures (single-file networks weigh the .html, ZIP networks weigh the archive, Meta weighs the index.html inside its ZIP), and then aim well under it. Some networks say so themselves: AppLovin notes that smaller files perform better.

Measure the File the Way Each Network Does

Size disputes between a build tool, a QA checklist and a network's upload screen almost always come down to measuring different things. Before you compare any number against a cap, be clear which of three measurements you are taking.

• The single HTML file. Networks that take one inlined document, such as Unity and AppLovin, weigh that file as it sits on disk. Everything inside it counts, including base64 images and inlined scripts.
• The ZIP archive. Google, TikTok, Pangle and Mintegral weigh the archive you upload. Zipping shrinks text a little and already-compressed images hardly at all, so do not count on the archive being much smaller than its contents.
• A file inside the archive. Meta checks the ZIP and, separately, the index.html inside it. A creative can pass the first and fail the second, which is why a Meta build that inlines every image into the HTML is the most common way to trip its limit.

Your operating system can mislead you too. Some file browsers report sizes in units of 1,000 bytes and others in 1,024, and the gap between the two grows with the file. When a build sits close to a cap, read the exact byte count rather than the rounded figure, and leave enough headroom that the rounding never matters.

What Actually Eats Your File Size

Images are nearly always the biggest part of the file, especially once base64-encoded. A 1200×2000 PNG background image might be 800 KB as a file; as base64 it becomes ~1.1 MB of text in your HTML. Two or three uncompressed images and you're at 3 MB before adding any code.

• Background images: largest single contributor in most end cards.
• Custom fonts: a full TrueType font file is 100–500 KB. Use a subset or switch to a system font.
• Multiple large images: app icon + background + button texture adds up fast.
• Particle FX: the system is lightweight JavaScript; image-based particle textures add weight.

Compression and Format Techniques

1. Convert PNGs to WebP before uploading: WebP is typically 25–35% smaller at equivalent quality.
2. Resize images to your canvas dimensions. A 3000px image displayed at 1080px is 8x the pixels you need.
3. Use JPG instead of PNG for photographic backgrounds: JPG at 80% quality is a fraction of PNG size.
4. Use CSS gradients or solid colors instead of image backgrounds where art allows.
5. Use the export-time compression in Playable Ads Maker. It applies additional image optimization during the HTML generation step.

One Creative, Several Networks

When the same design goes to several networks, the size question becomes which build is the tightest. A single-file network counts every inlined byte, a ZIP network counts the archive, and Meta counts both the archive and the HTML inside it. Size the art once against the strictest of these and every other export inherits the margin for free.

Trimming a heavy master separately for each network gives you creatives that look slightly different on each, which muddies any comparison of results. If one network's build really needs something the others do not, such as a larger asset for a landscape layout, decide that at the design stage rather than discovering it on the upload screen.

Practical Size Targets by Creative Type

• Simple end card (1 background, text, CTA button): target under 300 KB.
• End card with app icon and particle FX: target under 600 KB.
• Video playable with end card (video referenced separately, not embedded): end card HTML under 500 KB.
• Game Template mini-game end card: target under 1.5 MB (game logic adds weight).

A Worked Size Budget

Treat size as a budget you spend before you design, not a bill you discover after export. As an illustration, take an end card aimed at 500 KB. The framework and interaction code are a fixed cost you cannot design away, so set aside a slice for them first. What remains is the art budget, and it has to cover everything the viewer sees.

1. Background: the largest single allowance. A full-screen photographic background saved as a well-compressed WebP or JPG at the canvas's own resolution usually fits in a few hundred kilobytes; an illustrated one with flat colour often needs far less.
2. App icon: small and fixed. Export it at the size it is actually drawn, not the store-listing master.
3. Buttons, badges and props: individually tiny, collectively significant. Five small PNGs at full source resolution can cost as much as the background.
4. Fonts: a custom face subset to the characters you use is modest; a full family is not. See custom fonts in playable ads.
5. Headroom: keep a margin for late changes. A rewritten headline or a translated variant adds glyphs and sometimes art.

If an asset will not fit its allowance, the choice is to cut its resolution, change its format or remove it, not to borrow from the headroom. Teams that spend the headroom during design end up over the target the first time someone asks for one more variant.

Common Size Mistakes

• Building to the loosest cap. A creative sized for a 5 MB network has to be rebuilt the day Meta joins the media plan. Build to the strictest measurement you will ship to.
• Optimising the wrong asset. Shaving a few kilobytes off scripts while a 2,000-pixel background sits untouched. Sort assets by size and start at the top.
• Uploading store-listing masters. Icons and key art prepared for a store page are far larger than any playable needs.
• Embedding the same image twice. Two scenes using visually identical backgrounds saved as separate files pay for both.
• Checking size once. A file that passed at first export grows with every revision. Re-check after each change, not only before the first upload.

The reduce playable ad file size guide walks through the optimisation workflow step by step, and the asset formats guide covers which format suits which kind of art.