Playable Ad File Size Limits by Network: 2026 Guide

Updated September 2026

Playable ad file size limits look deceptively simple. Most major ad platforms work somewhere around the 5 MB mark. But a playable that passes one network’s validation can still fail on another because file size is only one part of the specification.

Google, Meta, TikTok, Unity Ads, and AppLovin differ in how they expect the creative to be packaged, how assets may be loaded, which API should handle the install button, and how portrait and landscape layouts are treated.

So if you plan to run the same playable concept across several acquisition channels, “under 5 MB” is not a complete production specification.

Here is the practical comparison.

Playable ad size limits at a glance

Google currently allows an App Campaign HTML5/playable asset to be uploaded as a ZIP of up to 5 MB containing no more than 512 files. TikTok also uses a compressed package under 5 MB, but its package structure and click-through integration are different. Unity and AppLovin both accept playables around the same 5 MB ceiling while requiring self-contained HTML builds and MRAID integration.

That is the first important lesson: the same maximum size does not mean the same deliverable.

At Alconost, this is why a finished playable ad production should be packaged and tested for the specific networks where the campaign will actually run rather than treated as one universal HTML file.

Why the 5 MB limit does not mean you should build a 5 MB playable

A network’s maximum is a rejection threshold, not a production target.

If a platform accepts a 5 MB package, it means a creative at or below that size may satisfy that particular validation rule. It does not mean that pushing every build to 4.9 MB is a good idea.

Playable ads are consumed in mobile advertising environments. The user does not open the creative because they have consciously decided to wait for a game to load. The experience competes for attention immediately.

Every extra image, animation frame, audio file, library, and font increases the payload. It can also increase parsing time, memory pressure, and startup work once the file reaches the device.

A leaner playable therefore gives the production team more room for:

• differences between network packaging;
• localization;
• additional characters or skins;
• fallback assets;
• later creative iterations;
• unexpected compression overhead.

In practice, treating 5 MB as emergency headroom instead of a design budget makes cross-network production easier.

Google Ads playable ad requirements

For Google App Campaigns, playable assets are HTML5 creatives delivered as a ZIP file.

The current Google specification allows a ZIP of up to 5 MB and no more than 512 files. Google also expects the creative to declare its orientation in the HTML. A playable can specify portrait, landscape, or both. Responsive design is recommended because the asset can be rendered at different full-screen sizes.

For a custom CTA, Google documents its Exit API. The exitapi.js script is included in the HTML and the CTA can invoke ExitApi.exit().

Google notes that if the creative does not include the Exit API or an equivalent MRAID framework, Google Ads may add an Install CTA itself.

Google App Campaign checklist

A practical Google build should therefore be checked for:

• ZIP size at or below 5 MB;
• no more than 512 files;
• correct orientation metadata;
• responsive rendering;
• correct relative paths for packaged assets;
• the required click-through implementation;
• correct behavior inside Google’s sandboxed environment.

Google provides an HTML5 Validator, which is worth running before the asset reaches the campaign manager. Google also notes that HTML5 App Campaign assets run in a sandboxed iframe, which can expose problems that were invisible when the creative was tested as a normal web page.

Do not confuse App Campaigns with Google Display HTML5 ads

This is an easy mistake to make when discussing “Google playable ad size.”

An App Campaign playable and a standard uploaded HTML5 display ad are not the same specification. Google’s current uploaded display ad documentation lists a 600 KB maximum for HTML5 display creatives, while the App Campaign playable documentation allows a 5 MB ZIP.

Always identify the actual campaign format before giving a developer a file-size requirement.

Meta playable ad requirements

Meta deserves extra attention because you may encounter both a single-HTML constraint and ZIP-based packaging references depending on the workflow.

A commonly documented Meta setup keeps the HTML entry file below 2 MB, while ZIP packages can be up to 5 MB with the entry index.html remaining under the smaller limit. Current Alconost production specifications also use 2 MB as the Meta single-HTML target.

For click-through, Meta playables use Meta’s own callback: FbPlayableAd.onCTAClick().

That is an important difference from MRAID networks. A CTA left over from an AppLovin or Unity build should not simply be assumed to work on Meta.

This is also why file size should be measured after the Meta-specific export, not only in the source project. Inlining images, audio, CSS, and JavaScript can materially change the final HTML size.

Our practical recommendation for Meta

Even when an available upload workflow gives you more total package space, keeping the core playable around the 2 MB range is a useful production discipline.

It reduces the risk that a creative becomes dependent on one particular packaging method and makes it easier to produce localized or reskinned versions without repeatedly fighting the size ceiling.

Meta’s playable implementation and upload surfaces have changed over time, so the final pre-launch step should always be to confirm the requirements visible in the current Meta account and creative uploader.

TikTok playable ad requirements

TikTok’s current requirements are more specific than “send us an HTML5 ad.”

Playable materials must be supplied as a ZIP smaller than 5 MB after compression. The main HTML file must be named index.html and sit in the first-level directory. TikTok also requires a config.json file containing orientation information.

The current specification also says:

• dynamic assets cannot be loaded from external networks;
• the playable should not make HTTP requests;
• HTML5 materials must not contain JavaScript redirects;
• the playable should support multiple device types;
• TikTok’s playable implementation should use the platform’s JS SDK rather than packaging mraid.js.

For the app-store action, TikTok documents its own SDK flow and the window.openAppStore() method.

That makes TikTok a good example of why “one 5 MB ZIP for every network” is a dangerous assumption.

Google and TikTok may both accept packages around 5 MB, but they do not expect the same metadata or click-through integration.

TikTok production checklist

Before submitting a playable to TikTok, verify:

1. The compressed package is under 5 MB.
2. index.html is at the correct directory level.
3. config.json contains the correct orientation value.
4. There are no unintended external HTTP requests.
5. The store CTA goes through TikTok’s supported integration.
6. Important gameplay and CTA elements stay inside TikTok safe zones.
7. The creative is tested on an actual mobile device, not only in a desktop browser.

TikTok Ads Manager can validate technical requirements, but TikTok explicitly notes that this validation does not replace checking safe zones and general playability.

Unity Ads playable ad requirements

Unity Ads requires a playable creative to be contained in a single index.html file under 5 MB.

The file should be inlined and minified, with no dependencies on separate folders. Unity currently specifies MRAID 3.0 compliance for User Acquisition playable assets.

Unity also expects the creative to:

• work in portrait and landscape;
• avoid unnecessary network requests;
• avoid automatic redirects to the app store;
• use mraid.open() for the CTA;
• wait for the appropriate MRAID viewability state before starting playable content.

This last point is important.

A creative can work perfectly when someone opens index.html directly in Chrome and still behave incorrectly inside an ad network WebView. The network controls when the ad is actually visible, when its API becomes available, and how the click-through should be handled.

Unity provides an Ad Testing app specifically so teams can preview creative packs on mobile devices before launch.

Unity size optimization has to happen before the final export

Because Unity expects a single inlined file, adding base64-encoded assets late in production can suddenly push a build over the limit.

Do not wait until the final QA pass to discover that your visual direction consumes too much space.

Establish a size budget for graphics, audio, code, and localization while the playable is still being designed.

AppLovin playable ad requirements

AppLovin currently requires an HTML playable to be 5 MB or smaller and delivered as a single HTML file.

All resources need to be embedded in that file; external resources and external network calls are prohibited in the standard specification. AppLovin requires the creative to function in both landscape and portrait orientations.

AppLovin currently specifies MRAID 2.0 for these HTML playables. The CTA should use mraid.open().

The network also requires audio to stay muted until the user interacts with the playable, and the creative must not automatically send the player to an app store.

Why an AppLovin export should be separate

Suppose your source playable was first prepared for TikTok.

The game mechanic and visual assets can remain the same, but the TikTok build may include its platform-specific package structure and SDK interaction. AppLovin expects a single self-contained HTML file and MRAID behavior instead.

This does not mean the creative needs to be developed twice.

It means the production pipeline needs a network adapter layer: one underlying playable concept, exported into several network-compliant deliverables.

What about ironSource / LevelPlay?

ironSource is worth mentioning because its documentation illustrates another issue: different delivery paths can expose different limits.

Current Unity documentation for the ironSource Exchange states that all downloaded assets plus code may total up to 4 MB, supports MRAID 2.0, and uses mraid.open() for click-through.

Elsewhere in the playable ecosystem, 5 MB is often used as the general production ceiling.

For a team distributing through multiple ironSource/Unity paths, the safest approach is therefore not to assume that a build just below 5 MB will be universally accepted. Identify the inventory and delivery route first, then build to the stricter applicable specification.

This is also a good reason to leave meaningful headroom instead of optimizing a creative to exactly 4.99 MB.

Why one playable build cannot simply be uploaded everywhere

There are four separate compatibility layers to think about.

1. File size

The obvious one: the final asset must fit the network limit. But remember to measure the exported network package, not the source project.

2. Packaging

One network may want a ZIP. Another may want one completely self-contained HTML file. A third may require specific metadata files in the root directory.

Changing the file extension does not convert one package into another.

3. Click-through API

This is one of the most consequential differences. For example:

• Google can use ExitApi.exit();
• Meta uses FbPlayableAd.onCTAClick();
• Unity and AppLovin use mraid.open();
• TikTok uses its playable JS SDK.

If the visual CTA works but calls the wrong platform function, your creative can appear completely functional until the user tries to install the app.

4. Runtime behavior

Playable ads run inside network-controlled WebViews and containers, not normal browser tabs.

You need to account for:

• viewability and ready states;
• orientation changes;
• muted audio before interaction;
• safe areas and network UI overlays;
• pause and resume behavior;
• different device performance levels.

That is why cross-network playable production is best treated as one creative source with several validated outputs, rather than one file copied into five dashboards.

How to reduce playable ad file size

If your playable is getting too close to the limit, start with assets rather than deleting gameplay logic at random.

Compress image assets

Images are often the largest part of a playable.

Ask whether every texture really needs its original dimensions and whether lossless PNG is required for every object. Opaque backgrounds and artwork may tolerate more aggressive compression than UI elements with transparency.

Sprite atlases can also reduce duplicated data and request overhead, depending on the production stack.

Reduce animation weight

Do not export dozens of large raster frames if the same motion can be recreated through transforms, skeletal animation, particles, or lightweight code.

Conversely, do not add a large runtime library merely to save a few small sprites. The smallest solution depends on the specific animation. Measure both approaches.

Audit audio

A playable rarely needs a full-length high-bitrate soundtrack.

Trim silence, shorten loops, lower the bitrate where the difference is inaudible on mobile speakers, and avoid including sound files that never play in the final interaction.

Remember that several networks also restrict audio until the user has interacted with the creative.

Subset or remove custom fonts

A complete font file can consume a surprising share of a small playable budget, especially after several weights or character sets are added.

If the creative only contains a few words, consider:

• a system font;
• a reduced glyph subset;
• converting a very small amount of display lettering to vector artwork.

For localized campaigns, however, plan this carefully. A Latin-only font subset is useless when the same creative is later needed in Japanese, Korean, Arabic, or another script.

Remove development code

Production packages should not contain:

• source maps;
• debug panels;
• unused libraries;
• console-heavy logging systems;
• prototype assets;
• dead scenes or mechanics.

Minification alone will not solve a build that contains megabytes of unnecessary content.

Design localization into the size budget

Localization is often introduced after the master playable has already been approved. That can cause trouble.

Translated strings can be longer. Different scripts need different font coverage. A culturally adapted version might require a different image, audio track, or music treatment.

If your English master already sits a few kilobytes below the platform maximum, every localized variant becomes a compression exercise. Leave room from the beginning.

Pre-submission playable ad checklist

Before sending a playable to an ad network, check more than the file-size number.

Package

• Is the final exported file below the applicable network limit?
• Is the required package type correct?
• Is index.html in the required location?
• Are required metadata files present?

Assets

• Are all required assets included or embedded?
• Are forbidden external requests removed?
• Are fonts and audio optimized?
• Have unused production files been removed?

Interaction

• Does the first interaction work on a real phone?
• Does the CTA call the correct network API?
• Is there any accidental or automatic store redirect?
• Does audio follow the platform’s interaction rules?

Layout

• Does the playable survive the required orientations?
• Are CTA and gameplay elements outside network UI overlays?
• Does it work on narrow, tall, and lower-performance devices?

QA

• Has the exact final export — not merely the source build — been tested?
• Has the network’s validator or preview environment been used?
• Has the creative been checked after every network-specific packaging step?

Passing all of those checks matters more than hitting one magic file-size number.

Frequently asked questions

What is the maximum size of a playable ad?

There is no single universal limit. Google App Campaigns, TikTok, Unity Ads, and AppLovin all currently work around a 5 MB maximum, while other networks or delivery paths may impose stricter requirements. Meta also has additional constraints around its HTML entry file and packaging. Always confirm the target network before producing the final build.

Should a playable ad be exactly under 5 MB?

No. The maximum should be treated as a ceiling rather than a target. A smaller build provides more headroom for localization, network-specific packaging, and future creative variants.

Can I upload the same playable ad to every ad network?

Usually not without adaptation. The underlying concept and codebase can be shared, but networks use different packaging, metadata, runtime APIs, and click-through methods.

What makes playable ad files so large?

The most common contributors are images, frame-by-frame animation, audio, font files, large JavaScript libraries, and unused development assets. In single-file playables, embedding resources can also increase the size of the final HTML.

How do I reduce playable ad size without ruining the creative?

Start by optimizing assets rather than cutting the interaction itself. Compress and resize imagery, simplify oversized animations, trim audio, subset fonts, remove dead code, and set an asset budget before production reaches final QA.

Do playable ad specifications change?

Yes. Ad platforms update formats, SDKs, upload workflows, and validation requirements. A specification copied from an old campaign or an old blog post should not be treated as a permanent source of truth. Verify the relevant network documentation before each new production cycle.

Build once, package for every network

The hard part of playable production is not simply getting an interactive ad below 5 MB.

The hard part is creating a concept that stays visually convincing and responsive after it has been compressed, localized, adapted to several device shapes, connected to the correct network APIs, and exported into every format your UA team needs.

Alconost produces playable ads from concept through network-ready delivery, including platform-specific versions for the acquisition channels in your media plan and localized variants for different markets and audience segments.

If you need one playable concept turned into a campaign-ready set of creatives for Meta, Google, TikTok, Unity Ads, AppLovin, and other networks, explore Alconost’s playable ad production service.

Related articles