A playable ad has to carry every asset it will ever need inside a single file, because the container it runs in blocks outbound requests. That constraint changes the format calculus completely. On a website, a slightly heavy image costs a little load time; in a playable, it costs a share of a budget measured in single-digit megabytes, and it is encoded into the file at a 33% premium before it even gets there.
Why base64 changes the arithmetic
Inlining an asset as a data URI encodes three bytes as four. A 300 KB image becomes roughly 400 KB inside the file. This is not a detail — it means every kilobyte saved on a source asset saves about 1.33 KB in the export, and it means the intuition you carry from web work systematically underestimates how much a given image costs here.
It also means compression work pays out more than usual. Halving an image from 400 KB to 200 KB removes about 266 KB from the finished file, which on a 2 MB Meta budget is over 13% of everything you have.
Images: WebP first, PNG only when you must
Google's published figures put lossy WebP at 25–34% smaller than a comparable-quality JPEG, and it is supported in every modern mobile webview that serves playables. At around 75% quality the difference is generally not visible at phone size, though that last part is a judgement to make against your own artwork rather than a number to trust blindly.
PNG earns its place in one situation: art with hard-edged transparency and few colours, where lossy compression produces visible fringing around the alpha edge. Even then, run it through a palette quantiser first — an 8-bit PNG with a well-chosen palette is often a fraction of the 24-bit original and indistinguishable at the size it will be displayed.
The bigger lever than format is resolution. An image displayed at 120 logical pixels needs 240 physical pixels on a 2x screen and nothing more. Shipping a 1024-wide source because that is what the artist exported is the most common single waste in a playable, and right-sizing before compressing beats compressing a too-large image every time.
The assets that should not be images at all
Backgrounds, gradients, buttons, panels, badges, progress bars, simple icons and most decorative shapes cost almost nothing when drawn in code, scale to any screen without a second asset, and stay sharp on high-DPI displays where a bitmap would need to be twice the size. A creative that draws its chrome and reserves bitmaps for genuine artwork routinely lands under 500 KB while looking better on a modern phone than a bitmap-heavy build twice the size.
A quick audit
Open your export and list every inlined asset by size. If anything in the top five is a flat colour, a gradient, a rounded rectangle or a solid-colour icon, you have found free budget.
Audio: short, mono, and treated as optional
Audio competes directly with image quality for the same few megabytes, and images do more work in a format judged on its first frame. Short feedback cues — a tap confirmation, a success chime — are worth their bytes. A full music bed usually is not, particularly since a large share of impressions are silent anyway thanks to browser autoplay policies and the iOS hardware mute switch.
Where you do include audio, mono is almost always sufficient for a phone speaker and halves the data. Keep sample rates modest, trim silence at both ends, and encode to a format the target webviews decode natively. The practical rule: if a cue is longer than about a second, ask whether the creative needs it or whether you are decorating.
Fonts: subset or do not embed
A full font file carrying every glyph in a large character set is one of the heaviest single assets people accidentally ship. Subset to the characters you actually use — for an ad that is typically a headline, a CTA label and a handful of numbers, which is a few dozen glyphs rather than a few thousand.
This is also where localisation bites. A subset covering Latin characters renders empty tofu boxes for Cyrillic or CJK, and it fails silently: nothing errors, the text simply does not appear, and nobody notices until someone in that market sees the ad. If you are shipping localised builds, subset per locale rather than shipping one font that covers everything on every impression.
There is a licensing dimension too. A font licensed for use on a website is not automatically licensed for embedding in an ad creative that gets distributed through third-party networks. Check before it is baked into fifty exports.
The compression order that pays best
- Right-size every image to the pixels it will actually occupy on a 2x screen.
- Replace anything a renderer can draw — backgrounds, gradients, panels, simple icons — with code.
- Convert remaining artwork to WebP at around 75% quality and compare against the original at phone size.
- Subset fonts to the glyphs in use, per locale if you are localising.
- Cut audio to short mono cues, or drop it entirely and design for silence.
- Reduce animation frame counts — a 12-frame loop is often indistinguishable from a 24-frame one at ad scale.
Working in that order matters because each step reduces the input to the next. Compressing a 1024-wide image you were about to display at 120 logical pixels is effort spent on bytes you were going to throw away anyway.
How small is small enough
The cap is a rejection threshold, not a target. Around 150 KB is achievable for a simple end card built mostly from shapes and text; 500 KB is comfortable for one with real artwork; 1–2 MB covers most mini-game playables. On mobile data a creative near the cap loads slowly enough that impressions are lost before the ad renders, and in bidding auctions that shows up as reduced delivery at the same bid — which is why several networks, AppLovin among them, explicitly recommend going well below their own published limit.
Create playable end cards in minutes—no code required.
Open Playable Ads Maker