Poki Blocks All External Requests by Default. Your Own Games Portal Blocks Nothing.

When you license HTML5 games, the build that lands on your server was made for someone else's portal. Publish-side rules tell you exactly what to inspect first.

Buyers spend weeks on the title count and the term, then accept whatever files arrive and hand them to an engineer with two days of ingest budget. The licence gets negotiated. The delivery does not. And a game build is not a document — it is a small application with an integration surface, and that surface was shaped by wherever the build ran last.

The useful thing is that you do not have to invent an acceptance standard. The largest web game platforms publish theirs, in public, in detail, because they receive builds from hundreds of studios and have been burned by every failure mode there is. Read those documents as a buyer rather than as a developer and you have a free specification for what a clean HTML5 build looks like.

🚫 The Strictest Platform on the Web Blocks Outbound Calls by Default

Poki's developer documentation states plainly that Poki blocks all external requests by default, and instructs studios to bundle their fonts, assets and libraries rather than fetch them. The same page lists what must come out of a build before release: all development tools, debug code and testing artifacts; splash screens and outgoing links; third-party ad systems and analytics, except for approved exemptions; and internal ad timers.

Read that list again as a buyer. It is not a wishlist. It is a description of what actually turns up in game builds that have passed through a few hands. Every item on it is something a build does when it was made for a different business model than yours — someone else's ad stack, someone else's measurement, someone else's traffic.

Your own portal almost certainly does none of this. You will drop the build into an iframe on your domain, block nothing, measure nothing, and find out what it calls when a privacy audit or a broken CDN tells you.

🔍 What a Licensed Build Phones Home For

In practice there are five or six recurring offenders, and they are worth naming because each one has a different consequence for the operator:

• An ad SDK or house-ad tag. The most expensive one. Impressions inside your portal, monetised into an account that is not yours, in inventory you paid to license and paid again to fill with traffic.
• Analytics. Usually the developer's, sometimes a previous licensee's. Under most privacy regimes you are the one answering for data collected on your domain by a tag you did not know existed.
• A remote save or leaderboard backend. Your players' progress sits on a third party's server, and disappears the day that server does.
• Fonts and libraries from a public CDN. Harmless until the CDN is slow, blocked in your market, or gone. Then the game hangs on a blank screen and nobody files a bug — the player just leaves.
• Outgoing links and "more games" buttons. A traffic leak painted onto your own page, pointing at whoever the build was made for.

CrazyGames enforces the same principle from a different direction: its technical requirements permit only relative paths, and state that absolute paths will fail to load. A platform that has to ingest thousands of builds does not ask nicely about hardcoded domains. It refuses them at the door. You should at least know where yours are.

📏 "Under 20 MB" Means Three Different Numbers

Size is the most commonly quoted figure in a catalogue spreadsheet and the least useful, because nobody says which size they mean. CrazyGames splits it into three, and the split is instructive. Its requirements allow a maximum total file size of 250 MB and a maximum of 1,500 files, require an initial download of 50 MB or less, and set 20 MB or less as the threshold for a game to be considered for the mobile homepage. Critically, initial download is measured from load start until the first gameplay-start event fires — not the size of the archive.

That distinction is the whole game. A 40 MB ZIP that streams 3 MB before first input is a better product than an 8 MB ZIP that blocks on all of it. Ask your licensor for bytes-to-first-input on a throttled connection, and ask how they measured it.

For scale: the HTTP Archive's Web Almanac 2025 page weight chapter puts the median mobile home page at 2,559 KB in total — 632 KB of JavaScript and 911 KB of images. A 20 MB initial download is roughly eight median web pages before anyone touches the screen. Poki's guidance frames the same problem in time rather than bytes, noting that players tend to move to another game if loading takes more than ten seconds, measured from worldwide locations rather than your office.

If your buyers are in markets where the median connection is not a European fibre line, the ten-second number is the one that decides whether the catalogue you licensed converts at all.

🔒 Sitelock Is a Feature Right Up Until It Points at the Wrong Domain

Domain locking — sitelock — is standard practice in HTML5 game licensing, and sensible: it stops a build being lifted off your portal and re-hosted by someone who never paid for it. CrazyGames' requirements note that sitelock whitelisting is needed for all of its domains and app origins, which tells you how the mechanism behaves in the real world. It is a per-destination list, and somebody has to maintain it.

The failure is mundane and extremely common: the build works on the licensor's demo page, works on your staging server because someone whitelisted it during the pilot, and fails silently the day you move to your CDN hostname, or wrap the portal in a mobile app where the origin is not an http domain at all. Three questions settle it before signature. Is there a lock in these builds? Is the allow-list something you can edit, or a rebuild request with a turnaround time? Does it cover every origin you will serve from — production, staging, CDN hostname, and any app wrapper?

🗂️ Metadata, Thumbnails and Language Files Are Deliverables Too

The build is the part everyone remembers to ask for. The merchandising layer is the part that decides whether the catalogue earns anything, and it is routinely left out of the contract entirely.

Per title, you need: category and tags that match your own taxonomy rather than the licensor's; a description you can publish without rewriting; orientation and control scheme; supported languages; a device and browser floor; and thumbnails in the exact sizes your grid uses. Both platforms above make the device floor explicit — CrazyGames evaluates performance against a 4 GB RAM Chromebook baseline, and Poki requires builds to scale proportionally to 640x360, 836x470 and 1031x580 with tablet support mandatory. Those are the kinds of fields that belong in a delivery manifest, not in an email thread.

If you are licensing hundreds of titles, this is the difference between a two-day ingest and a two-month content project. Get the manifest format agreed before the first batch lands, and check a sample of it against the actual builds — a populated spreadsheet cell is a claim, not a test result.

💾 Save Data Lives Under a Key You Do Not Control

Poki's requirements include a small, telling instruction: wrap localStorage access in try/catch so that games stay playable in incognito mode. The rule exists because plenty of builds crash outright when storage is unavailable.

For an operator running many titles on one origin, there is a second problem the platforms do not have to care about. Every game in your portal shares a storage namespace if you serve them from the same host. Two builds from different studios writing to a generic key such as save or progress will silently overwrite each other. Ask what the storage contract is: local only, under a per-title key namespace, or a documented API you can point at your own backend.

🧪 A Two-Hour Acceptance Test to Run Before You License HTML5 Games at Scale

None of this needs a QA department. It needs one engineer, one afternoon and a sample of builds — and it should happen during evaluation, not after the invoice.

1. Serve the build from a hostname that is not the licensor's demo domain. A blank screen or a silent failure here is a sitelock finding, and it is better to have it now.
2. Open the network panel and filter to requests leaving your origin. Every one of them is a finding. Note the domain, then ask what it does.
3. Throttle to slow 4G and record two numbers: bytes transferred and seconds elapsed before you can make the game respond to input. Ignore the ZIP size.
4. Grep the build for http://, for the licensor's domain, and for the names of the common ad and analytics vendors.
5. Play once with storage cleared, then again in a private window. Then play two different titles on the same origin and check that the first one's save survived.
6. Resize to a phone in portrait, a tablet, and a 640x360 window. Then try it on the oldest Android device in the office.
7. Click everything that is not gameplay. Logos, splash screens, corner buttons. Where does it go?
8. Take the metadata row for that title and try to publish a real category page from it, with no manual editing.

Whatever this turns up becomes the acceptance clause. That clause is the actual deliverable of the exercise: a written standard the build has to meet, a defined window in which you can reject a title, and a named turnaround for fixes. Most licence agreements have none of the three, which is why "the game is broken" so often turns into an argument rather than a ticket.

🚫 Four Ways Buyers Find This Out Late

• Treating the demo page as the integration test. The demo page is the one environment where every hardcoded path and every whitelist entry is correct by construction.
• Negotiating on title count and ingesting on trust. Volume is the easiest thing to compare between suppliers and the least predictive of how much work lands on your team.
• Meeting the ad tag during a consent audit. By that point the tag has been firing on your domain, in your name, for as long as the portal has been live.
• Having no fix path. A browser update breaks four titles. Without an acceptance standard and a support commitment in the contract, you are asking a favour, not raising a defect.

🎯 What Arrives When You Buy HTML5 Games From a Direct Licensor

Forestry Games has licensed games since 2017 and holds a catalogue of 1,049 titles, developed in-house as well as sourced, which means the delivery questions above have an owner rather than a chain of intermediaries. A catalogue licence covers HTML5 builds for web, portal and embedded use, with Android APK builds available for the same conversation rather than a separate deal, and source code where applicable for titles you intend to modify or reskin.

Delivery options run from self-hosting the builds on your own infrastructure to a hosted white-label game portal carrying your branding, which removes most of the integration surface described here because the hosting and the builds come from the same place. If you want to see the shape of what a catalogue licence covers before you scope one, license HTML5 games by format and use case, or buy Android games as APK builds for stores, preloads and offline markets.

🧸 Licensing Branded Games for Campaigns, Portals and Events

Forestry Games also works with branded IP and has brand partnerships including Disney, Nickelodeon, Cartoon Network and Warner Bros. Businesses can license branded games through Forestry Games for marketing campaigns, portals, live events and apps.

Branded titles carry everything in this article plus an approvals layer, so the delivery questions matter more, not less — asset scope, permitted markets and the process for pushing a fix all need to be settled before a campaign date is committed. The practical next step is the same either way: browse the catalogue, then ask for a licence scope for your specific use case, or request a white-label portal demo.

🧭 Ask for the Deliverables Schedule Before the Next Batch Lands

The gap between a good HTML5 game licensing deal and an expensive one is rarely the price per title. It is whether anyone wrote down what a delivered build must contain, what it must not contain, how it will be measured, and what happens when one fails.

Take the eight checks above, run them against three titles from whichever supplier you are currently evaluating, and send the results back as questions. Suppliers who can answer them quickly are describing a process they already run. Suppliers who cannot are telling you, accurately, how the next two years of your portal are going to go.