How to Turn an HTML5 Web Game Into a Playable Ad

If your game already runs in a browser — built with Phaser, Construct, Cocos Creator, PlayCanvas, Three.js or plain canvas — you are closer to a playable ad than a team working in a native engine. The game already speaks HTML5. But a web game and a playable ad live in very different environments, and nearly every conversion hits the same set of problems. This guide goes through them in the order they appear.

Step 1: Cut a slice, not a port

A playable is not your game in a smaller box. It is fifteen to thirty seconds built around one mechanic, with a demonstration, a short turn for the viewer, a win and a call to action. Start by deciding which moment of the game to show, then remove everything else: menus, settings, save systems, progression, accounts, analytics, ads, in-app purchases. What remains is usually a single level or a scripted fragment of one.

It often helps to script that fragment. A hand-authored board that always produces a satisfying result within a few moves beats a random level that might not. Difficulty in playables covers the balance, and pacing the five beats covers the length.

Step 2: Remove every network request

Ad networks require playables to be self-contained and block outbound requests; many reject a creative in review for attempting one. A web game makes requests constantly — loading assets, fonts, analytics, configuration, leaderboards. Every one has to go.

• Asset loading: images, audio, sprite sheets, JSON levels and fonts must be embedded in the file, typically as base64 data URIs, and loaded from there.
• Engine loaders: most engines load assets by URL. Configure them to read from data URIs or preloaded objects, or replace the loader.
• Fonts from web font services: embed a subset of the font instead. See custom fonts in playables.
• Analytics, crash reporting, remote config, ads and social SDKs: remove them entirely.
• Workers and WebAssembly modules fetched by URL: inline them, or avoid them.

Then check: open the file with the browser's network panel recording and confirm that nothing is requested after the document itself. The spec checker flags external references for you.

Step 3: Package the way each network wants

Networks disagree about packaging. Unity and AppLovin want a single HTML file with everything inlined. Google, TikTok and Mintegral want a ZIP with an index.html at its root. Meta accepts a ZIP but limits the index.html itself. Most caps sit around 5 MB, with several networks recommending far less. The size limits by network lists them.

The practical approach is one build that produces a single inlined HTML file, then a packaging step per network that wraps or zips it as required and adds that network's scripts.

Step 4: Wire the store exit per network

A web game opens links with window.open or a location change. Inside an ad container those are blocked or ignored; each network has its own call. MRAID networks — Unity, ironSource, AppLovin and others — use mraid.open(url). Google uses ExitApi.exit(). Meta uses FbPlayableAd.onCTAClick() and must not include mraid.js. Mintegral uses window.install(). TikTok uses window.openAppStore(). Wire the call to action through a small function that picks the right one for the build, and detect iOS versus Android to choose the store URL. What is MRAID covers the MRAID side.

Step 5: Respect the ad lifecycle

A web game starts when the page loads. An ad may be loaded before it is shown, so starting then means the demonstration plays to nobody and the audio starts early.

• Wait for the container: on MRAID, wait for the ready event, then for the ad to become viewable, before starting the game loop and audio.
• Pause when hidden: stop the loop and audio when the ad is no longer viewable or the page is hidden.
• Report lifecycle events where the network asks for them — Mintegral's gameReady, gameStart and gameEnd, for example.
• Respect the device mute switch: on iOS, audio played through Web Audio follows the switch, while media elements do not. See playable ad audio.

Step 6: Fit both orientations and every screen

A web game is often designed for one aspect ratio in a browser window. An ad appears on phones and tablets in portrait and landscape, and networks expect both. Make the layout respond to the viewport rather than scaling one fixed canvas, keep controls away from the edges where network close buttons and system gestures live, and test tall and wide extremes. See portrait vs landscape playables.

Step 7: Get under the size budget

The engine itself is often the largest single item. A full game framework can take a large share of the budget before any art is added, so use a custom or minimal build of the engine where it offers one, and strip unused modules. Then compress assets: WebP for images, compressed audio at modest bit rates, sprite sheets trimmed to the frames actually used, and base64 overhead — roughly a third — counted in the total. See reducing playable file size and asset formats.

Step 8: Performance on the devices that see ads

Ads run on every phone, including old and inexpensive ones, inside a webview that may be slower than the browser you tested in. Cap the frame rate sensibly, avoid large shader effects unless they are the point, and keep the time to the first interactive frame short. Load time and frame rate covers what to measure.

Step 9: Test like the network will

1. Validate the file against each network's specification.
2. Run it in each network's own preview or test tool where one exists.
3. Play it on a real iPhone and a real Android device, in both orientations, with sound on and off.
4. Tap the call to action on each and confirm the right store opens.
5. Record a network log and confirm nothing is fetched.

The device QA guide and the rejection checklist cover each step.

When to rebuild instead of convert

Converting makes sense when the mechanic depends on the game's own code — its physics, its generation, its feel — and the engine can be made small enough. It makes less sense when the slice is simple, when the engine build stays heavy, or when the team needs many variants quickly, because every variant then needs a developer. Many teams convert once to prove the concept, then rebuild the winning slice in a lighter tool for iteration.

Playable Ads Maker is that lighter tool: build the slice from your own art in a visual editor, or start from a genre template with the mechanic already working, and export a file for each network you pick with the packaging, store exits, lifecycle and both orientations handled. From a Unity game to a playable covers the same decision for Unity projects.