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.

The direct answer

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: July 19, 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.

Step 2: Get players into the game quickly

The portal requirements below differ, but they share one practical priority: get the build loaded and the player into the game quickly.

CrazyGames' current technical requirements allow up to 250 MB total, but the first playable download must be 50 MB or less, or 20 MB or less for mobile-homepage eligibility. Without the SDK, CrazyGames treats the entire bundle as that initial download, so the whole build must stay within the 50 MB limit. Its full-launch gameplay rules also ask games to start play immediately or within one click.

Poki's current submission requirements set a much tighter target, asking developers to keep the initial download under 8 MB. Its developer guide treats fast access as a design problem as well as a compression problem.

Those limits are platform-specific, not universal targets. The useful lesson is broader: ship the smallest first playable chunk you can. Load optional levels, music, cosmetics, or high-resolution assets after the player can begin.

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. A Basic Launch can go live with lighter integration, while games selected for Full Launch must meet its 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.

Poki also reviews submissions before moving a game into full integration. Its requirements emphasize small downloads, broad device support, privacy, and a polished web experience. If accepted, the Poki SDK and platform requirements become part of launch preparation.

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. Read the current agreement too, especially any rules around distribution, monetization, advertising, and platform-specific builds.

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.

You can link an HTTPS build you already host or upload a host-agnostic HTML5 ZIP. For uploaded builds, index.html must be at the root; current limits are 64 MB per file, 250 MB total, and 160 files. Linked games keep their own domain and build, while uploaded games are hosted by Bounty Board. After review, the game gets a public Arcade page, play tracking, and a weekly player-activity leaderboard. The studio dashboard reports plays, unique players, and playtime.

The difference is what can happen next. An approved Arcade game can also be listed on the Bounty Board marketplace, where a studio can run paid creator campaigns around something people can already play. That makes the route useful for teams trying to connect a playable hook with creator videos, streams, or posts and measurable player behavior.

The optional Bounty Board Arcade SDK adds score reporting for Bounty-hosted uploads and approved URL embeds, but it is not required for the first submission. Cloud save and load are available for logged-in players in hosted uploads; URL embeds need their own same-origin save fallback.

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. 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

Submission is the beginning of the useful part.

For the first 30 days, track the signals each route can genuinely provide:

• 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
• GamePix: Developer partner program
• Bounty Board Arcade: Submit your game