How to Submit an HTML5 Game to Web Game Platforms

Submitting an HTML5 game should be the easy part. The hard part is choosing a platform that fits what you want from the release.

Do you need a public page you control today? A curated portal with a large audience? A distribution network that can syndicate the game? A place to test the playable hook before a wider launch? Those are different jobs, and the right submission path depends on which one matters most.

How do you submit an HTML5 game?

Prepare one clean, platform-neutral web build first. Then choose one or two platforms based on your goal, adapt the build to their technical rules, and measure what happens after launch.

Platform requirements last verified: September 9, 2026. Recheck each platform's linked documentation before submitting; upload limits and integration rules can change.

At minimum, your submission package should have:

• an index.html entry point
• relative, case-correct file paths
• HTTPS for any external request
• a responsive canvas or viewport
• controls that work on the devices you claim to support
• a fast path from loading to actual play
• a title, short description, control instructions, and clean cover art
• clear rights to every asset and piece of music in the build

Do that work before adding a platform SDK. It gives you a stable base you can test locally and adapt without letting one portal's code spread through the whole project.

Step 1: Make the build portable

A browser game is still a website. Small path and hosting mistakes can break a build that worked perfectly on your own machine.

itch.io's HTML5 upload guide is a useful general checklist even if you plan to publish elsewhere. It requires an index.html file for ZIP uploads, warns that hosted paths are case-sensitive, and recommends relative paths because the project may run from a subdirectory. It also explains why external resources need HTTPS.

Before submitting, test the production build from a local web server rather than opening index.html directly. Then test it inside an iframe. Check:

• first load in a clean browser session
• keyboard, mouse, touch, and controller input where supported
• audio after the first user interaction
• focus loss, pause, resume, and tab switching
• fullscreen and changing viewport sizes
• save behavior in a restricted or sandboxed environment
• errors and failed network requests in the browser console

If you host the build yourself, confirm that its response headers allow the platform to embed it.

Check what the host allows your build to load

HTTPS is only the first check. A platform may still block a request that works on your own site. Before exporting each platform's version:

• Bundle fonts, images, audio, and libraries when the host requires local assets.
• Check whether analytics, multiplayer servers, and leaderboard services need approval.
• Keep each platform's SDK and ad configuration separate, so the wrong ad system never loads.
• Test saves when browser storage is unavailable, and tell players when progress will not persist.

For example, Poki's external-resources policy blocks third-party requests by default. External assets must be bundled; eligible analytics, multiplayer, and leaderboard services need explicit approval. Google Analytics cannot be approved. Check this before carrying your website's tracking setup into a Poki build.

Step 2: Get players into the game quickly

Check the exported files against your destination's limits before uploading. These are different measurements: an extracted build's size, its file count, and the download needed before someone can play.

Poki's current requirements ask for small downloads and progressive loading without specifying a universal MB cap. Its separate engine-selection guide recommends an initial download no larger than 5 MB and 8 MB total as performance goals. Keep that guidance distinct from a hard upload limit.

Passing an upload check does not mean the game loads quickly. Ship the smallest first playable chunk you can, then load optional levels, music, cosmetics, or high-resolution assets. Poki's onboarding guide explains this progressive-loading approach. CrazyGames' Full Launch gameplay rules also require players to reach gameplay immediately, or within one click when immediate play is not feasible.

Our Arcade-readiness guide covers the design side of that first minute.

Step 3: Choose the route that matches your goal

itch.io: a flexible, self-serve home

itch.io is a strong first stop when you want a public project page, control over presentation, and a low-friction way to share the game with a community.

It supports a ZIP containing the full project or a single self-contained HTML file. You can run the game inside the page or launch it fullscreen. It is also useful for game-jam entries, devlogs, prototypes, and projects where donations or a downloadable edition sit alongside the browser build.

The tradeoff is that a page existing does not create distribution by itself. You still need a community, promotion plan, jam, collection, or external audience to help people find it.

CrazyGames or Poki: curated portal reach

Curated portals can put a game in front of an existing player base, but acceptance and integration matter.

CrazyGames uses a two-stage process. Its SDK is optional for Basic Launch, and ads are disabled at that stage. Games selected for Full Launch must meet the broader requirements and use the SDK. The team reviews the build, metadata, controls, cover art, and player experience. Use CrazyGames' current publishing guidance before you submit.

For Poki, prepare gameplay SDK events before Web Fit testing. After clearing its Player Fit test, the Web Fit test measures how the game performs with players on Poki. Correct gameplay events, including gameplayStart(), must already work. Ad events such as commercialBreak() and rewardedBreak() can wait at this stage; implemented ads show placeholders and earn no revenue during the test. Passing sends the game to final review, with release still subject to approval.

Poki's release requirements also cover desktop, mobile, and tablet support, 16:9 canvas scaling, playability in incognito mode, and its external-request and advertising rules. Check these while preparing the test build so later review does not require a larger rework.

These platforms make the most sense when your game already has a clear, repeatable loop and you are ready to adapt it to a portal's standards. Before planning a multi-platform release, read the agreement's distribution, exclusivity, advertising, and revenue terms.

GamePix: distribution through a network

GamePix takes a different route. Developers integrate its SDK and submit a game for hosting and distribution across its publisher network.

That can be useful when syndication is the goal. It also means you should distinguish between a play on a partner site, traffic to your own page, and a direct relationship with a player. They are not the same outcome.

Review the current GamePix developer program for integration, approval, reporting, and commercial terms rather than relying on an old comparison article.

Bounty Board Arcade: playable discovery tied to creators

Bounty Board Arcade submissions are free and do not require an SDK to start.

The path is:

1. Submit. Create a free studio account, then link an HTTPS build you host or upload a host-agnostic HTML5 ZIP, following the limits above. Add the game's title, square thumbnail, and submission details.
2. Review. The team checks playability and content. Submission alone does not publish the game.
3. Go live after approval. The game gets an Arcade page, play tracking, and a weekly player-activity leaderboard. Your studio dashboard reports plays, unique players, and playtime. Linked games keep your domain and build; Bounty Board hosts uploaded builds.

Marketplace listing and paid creator campaigns are separate choices after approval. You can invite creators to make videos, streams, or posts around a playable game. An Arcade listing does not guarantee traffic or creator coverage.

The optional Bounty Board Arcade SDK capability table shows what each hosting mode supports. Score reporting works for Bounty-hosted uploads and approved URL embeds running inside the Bounty Board player when leaderboards are enabled for the game. Cloud save and load work for logged-in players in hosted uploads; URL embeds need their own same-origin save fallback. Hosted uploads run without native localStorage, so test progress saving in that environment. Our leaderboards and cloud-saves guide covers the integration choices in more detail.

Self-hosting: maximum control, no built-in audience

Hosting the game on your own site gives you control over the URL, analytics, release schedule, surrounding page, and player relationship.

It also makes discovery your responsibility. Self-hosting works best when you already have traffic, want a stable home for the game, or plan to send players from social posts, a newsletter, press coverage, creators, or other platforms.

You can combine this route with portals that accept externally hosted builds when your distribution agreement allows it. Keep each platform's SDK, ads, and tracking rules isolated so the same build does not behave incorrectly everywhere.

Step 4: Prepare the submission material once

Create a small release folder that can be reused across platforms:

• a one-sentence hook
• a 50-to-100-word description
• controls in plain language
• genre and device support
• square, landscape, and video cover assets where available
• a short gameplay clip
• privacy policy and support contact if the build collects data
• version number and build date
• known limitations

Do not use the same generic description everywhere without checking the context. A portal player wants to know what happens in the first minute. A creator wants to know what is worth showing. A press page may need the studio story and downloadable assets.

Step 5: Treat launch as a test

For the first 30 days, track the signals available on each platform:

• people who reached the game page
• people who started playing
• time to first play
• session length and replay behavior
• ratings or qualitative feedback
• store, Discord, or creator-opportunity clicks
• technical failures by device and browser

Compare the platforms on those outcomes, not on the size of the audience they advertise. A smaller surface that produces real play, useful feedback, or creator interest may be more valuable than a larger one where the game disappears into a catalog.

For a broader platform comparison, read The best web game platforms for indie developers. Then pick the route whose tradeoffs fit this release, keep the build portable, and give yourself enough data to make the next decision.

Sources worth checking before you submit

• itch.io: Uploading HTML5 games
• CrazyGames: Publishing requirements
• CrazyGames: Technical requirements
• Poki: Developer requirements
• Poki: Web Fit test
• Poki: Engine and loading guidance
• Poki: External resources policy
• GamePix: Developer partner program
• Bounty Board Arcade: Submit your game

Update history2 entries

• September 9, 2026: Rechecked platform documentation, corrected Poki's SDK timing and loading guidance, added a host-limit checklist and external-resource checks, and clarified Bounty Board's review process and optional SDK features.
• July 30, 2026: First published.