The pitch for web game development is usually some version of “zero cost, global reach, instant publishing.” All true — and all irrelevant to the question that matters: does the money arrive? This is a tour of how browser games actually monetize in 2026, with the published splits, documented thresholds and real per-play numbers, rather than a case study about a fictional developer earning a fictional monthly figure.

A person playing a game on a smartphone
Most web game sessions still start on a phone — which is also where ad impressions pay. Image via Wikipedia.

The Core Difference From App Stores

Store games earn per unit and per conversion; web games earn per session. There is no $4.99 download to optimize, so the revenue model is built around what happens during play: advertising shown between runs, rewarded video offered for an in-game benefit, occasional in-app purchases in invited titles, and — at the platform end — a share of everything the portal collects.

That structure has a consequence worth internalizing: volume and session quality both matter. A thousand short sessions and a thousand deep sessions are the same download count and very different revenue.

The Five Real Revenue Paths

1. Portal revenue share (the default)

Portals handle distribution, hosting, payments and ads, and pass a percentage back to the developer.

PlatformDeveloper shareNotes
Poki~50% of ad revenue; 100% on traffic you bring yourselfCurated catalogue, 100M+ monthly players, 1B+ gameplays/month
CrazyGamesNot published in main docs; 60% of ad revenue / 70% of purchase revenue in its 2026 GameMaker web jam terms€100 minimum payout, monthly via Tipalti; no exclusivity required
GameMonetize~45% via SDKWide syndication, monthly payouts
Playgama Bridge~80% statedLocal payment gateways
GameDistributionVaries by dealSyndicates to 4,000+ portals, ~350M monthly reach

Treat the middle column as a headline rate: actual earnings depend on where your players are (CPM varies enormously by geography) and how long they stay.

2. In-app purchase

CrazyGames offers IAP through Xsolla, but only by invitation, to titles that have already proven retention. On Poki, purchase-driven revenue is far less central than ads. For most studios, IAP is a later conversation, not a launch plan.

3. Licensing

White-label and exclusive licenses to portals or aggregators still exist as a one-time model: roughly $300–$800 for a non-exclusive license in the published range, climbing past $5,000 for exclusives. It is cash up front in exchange for giving up the upside.

4. Sponsorship and community

Patreon-style support, tip jars and sponsored builds. Works when the game has a following of its own; rarely works as a first-line strategy.

5. Multi-platform release

Because CrazyGames (among others) does not require exclusivity, the same build can earn on the web while a paid or ad-supported version earns on Steam, mobile and itch.io. The web becomes a discovery channel that pays for itself, not a bet placed alone.

What the Numbers Really Look Like

The long tail, documented. A 2026 revenue analysis of itch.io’s paid catalogue found roughly 80% of games earning $0–$50 a month, about 15% earning $50–$500, around 4% reaching $500–$2,000, under 1% reaching $2,000–$10,000, and fewer than 0.2% above $10,000. Store economics on the web behave like store economics everywhere.

Per-play reality. One developer’s published breakdown across eight WebGL games — 451,327 plays on CrazyGames earning €556.92, roughly €1.20 per thousand plays, plus $163.79 from 104,444 Kongregate plays — is the clearest per-unit figure available. It is old data (the games launched around 2018), but the order of magnitude is instructive: traffic volume is not a rounding error in this business model.

The middle of the market. A well-performing casual title on a major portal typically clears somewhere around $200–$2,000 a month through revenue share.

The top. Poki reports its best developer partners generating up to €1 million a year, and solo developers sustaining themselves entirely from portal income. Those are the outliers by definition — but they exist, and they are documented rather than aspirational.

What the Platforms Require

CrazyGames publishes hard build limits, and they double as performance guidance for any web game:

  • Initial load ≤ 50 MB
  • Total build ≤ 250 MB
  • ≤ 1,500 files

The reasoning is straightforward: every megabyte between click and control costs players, and players are the unit your revenue is denominated in. Lazy-load audio, compress textures, and defer everything that is not visible in the first frame.

Metrics Worth Managing (Our Editorial Benchmarks)

The table below is editorial guidance — the thresholds our team uses when reviewing titles — not a cited industry statistic. Use it as a starting point and replace it with your own baseline as soon as you have data:

MetricRough passStrong
Day-2 retention15%35%+
Average session5 minutes15 minutes+
Share/referral rate3%10%+
Returning play rate (week)20%40%+

If a mechanic cannot move one of these rows in an A/B test, it is not worth building, regardless of how game-like it looks.

Getting Started, Honestly

  1. Ship one complete game, not three prototypes. Portals want finished, tested, stable builds.
  2. Optimize the first frame. Your load time is your marketing.
  3. Pick one portal as home and treat the rest as distribution — splitting attention across five platforms with no data anywhere helps nobody.
  4. Read the payout terms before you read the analytics dashboard. Minimum thresholds, payment processors and exclusivity clauses decide what you actually receive.
  5. Expect the first games to be learning. The economics reward iteration and a catalogue, not a single lucky launch.

Conclusion

Web games are not a path to effortless income. They are the lowest-friction route to testing whether anyone wants what you made — zero launch cost, no review queue, global reach, and a documented revenue share waiting on the other side of genuine retention. Build something people finish, measure how many come back, and let the split do the rest.

Sources