Web-Native Game Distribution in 2026: Portals, Revenue & Playbook

For a long time, “web game” was something you said apologetically. The implication was: lower-fidelity, ad-supported, sitting on a portal that paid pennies, used as a last resort before sunsetting a title.

That framing is now obsolete for an entire class of mobile titles — and the operational and monetisation maths have changed enough that web-native deserves a seat at the same table as alt-store and OEM strategies for most ad-driven publishers.

What changed: the browser stopped being a constraint

A note on the 30%/15% baseline. That pairing still describes the App Store. It no longer describes Google Play in the EEA, UK and US: since 30 June 2026 Play charges 10% on your first $1M of annual earnings, then 20% or 25%, and 15%/20% under Games Level Up. Where a comparison below reads against 30%/15%, read it as the App Store, and check Play’s current rates before applying it to Android.

Three independent capability shifts converged in the 2022-2025 window and made web-native commercially viable for serious mobile titles.

WebGL 2 became universal, and WebGPU is mainstream — with caveats worth reading. WebGL 2 is supported in every modern mobile browser. WebGPU is the newer story, and the shipping scope is narrower than the headline suggests: per Google’s own browser-support tracking, “support for Android was added in Chrome version 121 for devices running at least Android 12, and with Qualcomm/ARM GPUs”, and on Apple’s side “WebGPU is available in macOS Tahoe 26, iOS 26, iPadOS 26, and visionOS 26”. Firefox has it on Windows since 141 and on ARM64 macOS since 145, with Android still in development. So: broad, but not universal, and your device-coverage assumption should be tested rather than assumed. On performance, the honest framing is that for the kinds of titles that work on the web (casual to mid-core 2D and stylised 3D) the native-versus-web gap on mid-range mobile is usually small enough not to drive the design — but nobody publishes a credible cross-engine benchmark, so measure it on your own build rather than trusting a percentage. Which titles actually clear the delivery gates is a separate question; see our WebGPU readiness guide for the genre-by-genre breakdown.

WebAssembly matured into a real runtime. Engines including Unity (via the WebGPU backend), Godot, Cocos, PlayCanvas, Babylon.js, Defold and Construct now produce web builds that ship within reasonable size budgets. The “Unity Web” pipeline that ate 100 MB and 30 seconds to start in 2020 is no longer the relevant benchmark.

Where each major engine stands in 2026. The build-size column is our own indicative planning range from project work, not a vendor-published figure — treat it as a starting hypothesis to measure against, not data:

Engine	Web Backend	Typical Initial Build	Best Web Use Case
Cocos Creator	Wasm + WebGL/WebGPU	5–15 MB	Casual 2D, hyper-casual
PlayCanvas	WebGL/WebGPU native	10–25 MB	Mid-core 3D, branded interactive
Construct	Wasm (no-code)	5–12 MB	Casual 2D, rapid prototyping
Godot 4	Wasm + WebGL/WebGPU	15–35 MB	Casual to mid-core, versatile
Babylon.js	WebGL/WebGPU native	20–40 MB	Mid-core 3D, branded campaigns
Unity (WebGPU backend)	Wasm + WebGPU	30–60 MB	Mid-core 3D, existing Unity codebase

PWA install flows removed the friction. Modern web games can install to the home screen on iOS and Android, behave like native apps to most users, work offline if the developer wires service workers properly, and trigger system notifications. The “going to a website” friction that defined web games’ user experience for two decades is now optional.

The result is a distribution layer that didn’t really exist five years ago: web-native, frictionless, monetisable, and crucially, not gated by the dominant storefronts. We touch on this from a different angle in our alt-stores 2026 overview, but web-native deserves its own treatment because the mechanics are genuinely different.

The web-native distribution surfaces in 2026

A non-exhaustive map of where web-native titles get installs in 2026:

Dedicated game portals

Poki, CrazyGames, Coolmath Games, Y8, Kongregate, itch.io (HTML5 section), Game Distribution, and a long tail of regional portals (Crazy Games BR, Y8 Latin America, several Asia-Pacific portals). Poki and CrazyGames in particular have grown into substantial discovery surfaces with their own internal recommendation algorithms and revenue-share economics that compete favourably with mobile ad networks for ad-driven titles.

The portal model in 2026 looks closer to “publisher-developer relationship” than the pure CPM marketplace it used to be. Portals offer revenue-share deals, featured placement, audience targeting, and even modest minimum guarantees for promising titles. What they mostly do not offer is a public rate card, and that matters more than the industry’s habit of quoting a flat “50/50” suggests — Poki, the one major portal that publishes its terms, splits revenue differently depending on who sourced the player. We put every published split, payout threshold and purchase gate side by side in what each HTML5 channel actually pays. For publishers who’d rather not sign each portal individually, Playgama Bridge’s aggregator SDK bundles a set of these destinations behind one integration and publishes its own revenue ladder up front — though Poki and CrazyGames are explicitly not among the portals it publishes to, and ads, payments and analytics all have to run through the Bridge rather than each portal’s own plumbing.

A snapshot of the leading portals in 2026, restricted to terms and audience figures each platform actually publishes:

Portal	Published audience	Developer terms (as published)	Best For
Poki	”Over 100 million monthly active users across more than 100 countries”	100% of revenue on players you bring; 50/50 on players Poki sends you	Casual to mid-core, global
CrazyGames	Not published	Ad revenue share; no fixed percentage published — its developer terms tie compensation to the traffic and ad impressions your game generates, plus a 50% uplift for two months of portal exclusivity	Casual, mid-core 2D, EU-heavy
Coolmath Games	Not published	Negotiated	Educational casual, US
itch.io (HTML5)	Not published	You set the cut: “decide how much you want to support itch.io by choosing what percentage of your sales” goes to the platform	Indie, premium / pay-what-you-want
Game Distribution	Not published	Negotiated syndication share	Wide syndication reach

On relative scale, the most recent independent read is the Similarweb traffic data in Poki’s 2026 State of Web Gaming Report, which ranks the top five web gaming platforms by deduplicated desktop and mobile web audience visits in May 2026 as Poki, CrazyGames, Friv, Coolmath Games and Playhop. Note what that means for planning: itch.io and syndication networks like Game Distribution serve real but structurally different audiences, and no portal outside Poki publishes an absolute player count you can put in a model.

On CPMs, we deliberately don’t print a number here. No portal publishes a rate card, ad rates swing hard by geo, genre, season and fill, and any single range quoted as an industry average is more likely to mislead your model than help it. The reliable shape holds — tier-1 geos (US, UK, Germany, Japan, Australia) monetise at a large multiple of emerging markets, and rewarded video clears well above display — but get your actual numbers from a portal’s own projections during onboarding, or from your first month of live data.

Embedded distribution

TikTok mini games — which TikTok’s developer documentation describes as launching “directly in TikTok without downloading them” and lists as live in markets including the US, Japan, Indonesia, Turkey, Saudi Arabia, Thailand, Brazil, Malaysia, the Philippines and Vietnam — plus Snapchat Snap Games, Instagram in-feed playables, and ad-network playables that double as distribution (Mintegral, IronSource, Liftoff Playable). The line between “playable ad” and “embedded game” continues to blur, and the publishers who lean into this hybrid get distribution as a by-product of their UA spend. For publishers building specifically on Telegram, TikTok, and Messenger — where the game lives inside the messaging thread — we broke out the instant-games channel playbook in detail.

First-party web

Your own URL or PWA. This is the most underrated surface for studios with existing audiences. A web build of your title, hosted on your domain, with social-share metadata and a PWA install prompt, is essentially zero marginal distribution cost. Studios with newsletter audiences, Discord communities, or strong organic search profiles often see surprisingly serious volume from first-party web.

Branded experience hosting

Brand integrations, agency-led campaigns, in-context promotional games on news sites, retail microsites, sports league platforms. This is closer to the agency business than to publishing, but it generates real revenue for studios that can position themselves as the technical partner for brand interactive work. For studios interested in this side, our interactive practice covers the operational model.

Where web-native shines

The fit is best when:

Session length is short. Under 5-minute sessions reward immediate playability over deep onboarding. Web-native’s “click and play” pattern aligns with this user expectation directly.

Ad-supported monetisation is the spine. Display ads, rewarded video, interstitials and offer walls all work well on the web, and on premium portals the rates are competitive with mobile-app inventory for comparable content.

The audience is acquisition-cost-sensitive. When paid install costs can’t be justified in your unit economics, organic and embedded web distribution becomes economically meaningful.

The IP or brand can carry the discovery. Playable ads, branded experiences, IP tie-ins where the audience is already on the web and the title piggybacks on existing intent.

Cross-platform parity matters. A single web build that runs on desktop and mobile is often a strategic asset for IP holders and brands who want one creative that travels across surfaces.

Where it doesn’t

Web-native is not a substitute for the App Store everywhere. The fit is poor when:

Sessions are long (20+ minutes). Battery, thermal management, and browser memory pressure all start to bite over long sessions. Native runs more reliably for these titles.

Deep meta-systems are central. Persistent player state, social features tied to platform identity, in-app messaging, achievements that surface in the platform UI — all of these are possible on the web but operationally heavier than the equivalent native flows.

First-party billing economics carry the title. If a meaningful share of revenue depends on Apple Pay or Google Play billing user trust, web-native can complement but not replace that surface.

Premium one-time purchase models generally underperform on the web outside niche audiences (itch.io being a notable exception for indie work).

For mobile-native publishers, web-native is usually a complement, not a substitute, and the studios who think of it that way get the most out of it. We talk about how this stacks with OEM channels, the multi-channel distribution framework, and broader distribution strategy elsewhere.

Monetisation: the honest breakdown

Three layers, each with its own mechanics.

Ad mediation. Web ad mediation is its own art. The relevant players in 2026 are AdSense for Games (Google’s stack for HTML5 publishers), AdinPlay, Snigel, GameMonetize, and direct deals with portals via their own ad SDKs. Rates are not published anywhere reliable, so build your model on two structural facts instead of a quoted CPM: tier-1 geos monetise at a multiple of emerging markets, and rewarded video clears well above display. Mediation across portals via a single ad SDK (AdinPlay, Snigel) is increasingly the default rather than per-portal direct integration.

In-app purchase via web payments. Stripe, Adyen, PayPal, and several emerging web-payment players now offer SDK-level integration for HTML5 games. The conversion mechanics are different from native: no Touch ID/Face ID confirm, longer payment flow, higher abandonment at the payment step. The flip side: no platform fee, no 30% tax. For digital goods in titles where the audience trusts the brand, this can flip the unit economics dramatically.

Subscription models. Web payment infrastructure now supports subscription billing competitive with platform-native billing on mechanical terms (recurring billing, dunning, upgrades). The audience habit gap is the constraint: most mobile users don’t expect to enter card details for a game on the web, and conversion rates reflect that. For audiences that do (PC web crossovers, brand-loyal communities), subscription on the web is meaningful.

Hybrid models (web ads + first-party billing for premium content) are where some of the most interesting experimentation is happening in 2026. The studios who have figured out the right onboarding sequence get the best of both surfaces.

In-app purchases for browser games in 2026

The monetisation section above covers web payments in broad strokes, but IAP for browser-based titles has become specific enough in 2026 to warrant its own map. Three implementation paths exist with very different mechanics and economics.

Digital Goods API + Trusted Web Activity (via Google Play Billing). For PWAs distributed through the Google Play Store as Trusted Web Activities (TWAs), the Digital Goods API enables native-feeling Play Billing inside the web experience. From the user’s perspective, the purchase flow looks like a standard Play Billing sheet. From the developer’s perspective, Play’s 30%/15% commission applies — identical to a native app — but you retain the web-native deployment advantages: instant updates, single codebase, no Play review for content changes. For studios with existing Play audiences, this is the closest thing to native IAP available in a web-native context.

Self-hosted PWA + third-party payment processor. Outside Google Play’s TWA wrapper, the realistic IAP options for self-hosted PWAs are Xsolla, Paddle, and Stripe. Each offers SDK-level integration for digital goods, with conversion flows that run directly on your web domain. The economics flip compared to Play Billing: no platform fee, and payment processing in the low single digits — Stripe’s published standard US online card rate is “2.9% + USD0.30”, with its EEA standard-card rate lower still — but lower conversion rates, because users must complete a full card-entry flow without Touch ID or Face ID trust signals. For high-ARPU, subscription-oriented titles with loyal audiences — where the user trusts the brand enough to enter payment details — this path can yield significantly better unit economics than any store path.

Portal distribution: ad-first, IAP gated or absent. Treat portals as an ad-monetisation surface by default, but check each one rather than assuming. Poki’s developer documentation describes an ad revenue-share model with no publisher-facing IAP product. CrazyGames does support purchases, but its documentation states plainly that “in-game purchases are an invite only feature”, processed through Xsolla and restricted to signed-in users. If IAP is a material part of your unit economics and you’re not on that invite list, portal distribution serves discovery and ad monetisation; the purchase step has to happen on your own hosted surface — a redirect to your PWA or a direct purchase URL on your domain.

The hybrid model that increasingly makes sense in 2026: use portals for discovery and ad monetisation (they are very good at that) and route engaged users to your first-party PWA where IAP becomes possible. The conversion to a self-hosted context is the friction point, but studios with brand recognition or retention mechanics — daily rewards, save-state continuity — are making it work.

One comparison that trips up studios new to web IAP: the platform-fee saving from self-hosted payments is real, but so is the conversion-rate difference. The same purchase prompt converts materially worse on an unfamiliar web domain than inside a store’s biometric-confirmed flow — the size of the drop is title-specific and we’ve seen no credible published benchmark for it, so measure it with a split test rather than assuming a number. Model both variables, not just the fee, before optimising for web payments over store billing.

Operational reality

The web-native build pipeline is different from mobile, but in several ways simpler.

One build, many surfaces. A web build can target your own site, ad networks, branded microsites, and partner portals from a single artifact (with light wrapper customisation per surface). Compared to maintaining iOS/Android/OEM-store/console builds in parallel, this is a meaningful operational saving.

No submission lag. You ship when you ship. No App Store review, no Google Play update review queue. For LiveOps-driven titles, this collapses a major source of operational complexity.

Updates are instant. Patch a balance issue, ship a new event, deploy a hot-fix to all players in minutes rather than days. This has real product implications: web-native LiveOps can iterate at a cadence that the App Store flatly cannot.

Analytics need a different stack. Native attribution SDKs (AppsFlyer, Adjust, Singular) have web-native equivalents but the canonical signals are different (URL params, page referrer, browser fingerprinting under tightening privacy constraints). For publishers used to UDID-style fidelity, this is an adjustment.

Ad mediation across web is its own art. Different from mobile ad mediation in non-trivial ways. The publishers who lean into a single mediator (AdinPlay or Snigel are the two most-cited in 2026) and treat it as a real partner relationship tend to outperform those who try to manage portal-by-portal direct deals.

None of these are dealbreakers, they are just different defaults than what mobile-native publishers are used to. The studios who absorb the differences quickly tend to find they reduce operational load overall rather than increasing it.

A 2026 playbook for adding web-native distribution

For a publisher with an existing mobile title considering adding a web-native channel, the shape of a 12-week first pass:

1. Weeks 1-2. Engine and build target audit. If you’re on Unity, set up the WebGPU backend; on Godot, the HTML5 export; on Cocos, the web build target. Measure cold-start size and time-to-playable, and set your own budget from that baseline — the targets we work to are roughly 15 MB initial download and 6 seconds time-to-playable on mid-range mobile, which are operating conventions rather than published standards.
2. Weeks 3-4. Identify your two primary distribution surfaces. For most titles, this is one major portal (Poki or CrazyGames) plus your own first-party web. For brand-driven work, swap one of these for a branded-experience deal.
3. Weeks 5-6. Ad mediation integration. Pick one mediator (AdinPlay or Snigel are the most-cited defaults in 2026) and wire it through. Configure waterfalls for tier-1 and emerging-market geo splits.
4. Weeks 7-8. Portal submission and onboarding. Each portal has its own QA bar; their feedback in this phase is usually the most operationally useful you’ll get because they want the title to succeed on their surface.
5. Weeks 9-12. Soft launch on portal + first-party. Measure session length, retention, ad CPM, conversion to PWA install. Iterate creatives and onboarding based on data.

For studios with no existing web build, the upfront cost is roughly 4-8 weeks of one engineer plus targeted QA. For studios already shipping a web-capable engine, the cost can be as low as 2-4 weeks.

What’s next

Three things to watch through late 2026 and into 2027.

WebGPU adoption on iOS. Safari’s WebGPU support is the linchpin for performance parity with native on iPhone. As Apple continues to widen WebGPU exposure, the ceiling on what’s commercially viable as web-native moves up.

Portal consolidation and platform-portal hybrids. Poki and CrazyGames have grown to scales where they’re starting to look like platforms, not portals. Expect more portal-led publishing deals and possibly storefront-style featuring economics.

Embedded web games inside alt-stores. Several DMA-licensed marketplaces and OEM stores in Asia have started experimenting with native-installable web titles inside their storefronts. If this lands, the line between “alt-store” and “web-native” will essentially dissolve.

FAQ

Is web-native viable for premium mid-core titles in 2026?

For most premium mid-core titles, web-native is a complement rather than a replacement. The discovery surfaces and audience habits favour casual and mid-core titles with shorter sessions. Premium mid-core titles can use web-native for demos, branded experiences, or cross-promo, but app-native usually remains the primary surface.

What can you actually expect to earn on a portal like Poki or CrazyGames?

No major portal publishes a CPM rate card, and rates swing hard by geo, genre, season and fill — so any single quoted range is more likely to mislead your model than help it. Two structural facts do hold: tier-1 geos (US, UK, Germany, Japan, Australia) monetise at a multiple of emerging markets, and rewarded video clears well above display. On the split, Poki is the one major portal that publishes its terms: you keep 100% of revenue from players who come to your game directly, and 50/50 on players Poki sends you. Get your actual numbers from a portal’s onboarding projections or your first month live.

Can a web build replace an Android build economically?

For specific title types (ad-driven casual, hyper-casual, branded experiences), yes — a well-tuned web build with PWA install support can substitute for an Android build in many emerging markets. For most other titles, the right framing is “additional channel, not substitute”.

What engine produces the best web build quality in 2026?

Engine choice depends on the title. Cocos, PlayCanvas, Babylon.js and Construct are typically strongest for casual and 2D content. Godot’s HTML5 export has matured into a strong general option. Unity’s WebGPU backend is now competitive for mid-core 3D, though build size is still a consideration. The honest answer is “the engine you already ship on, if its web target is mature.”

How does PWA install affect retention?

PWA-installed users behave more like native-app users on most retention dimensions: higher D1, higher D7, more session frequency. The conversion to PWA install is the rate-limiting step — most web sessions don’t install, but those that do retain meaningfully better.

What’s the right ad-monetisation stack for a web-native title?

For most studios in 2026, the recommended default is a single web ad mediator (AdinPlay or Snigel) handling waterfalls across multiple SSPs, plus direct portal integration where one specific portal accounts for significant share. Manual portal-by-portal direct deals make sense only above significant scale.

Are there content categories that don’t work on the web at all?

Long-session multiplayer (60+ minute sessions) and titles with deep platform-identity integration (Game Center, Play Games achievements) remain a meaningful disadvantage on the web. Real-money gaming has its own regulatory layer on the web that’s stricter than native in many jurisdictions. Outside these categories, most title types now have viable web-native paths.

---

If you’re weighing whether web-native fits your title and want a candid read on the unit economics — which surfaces, what ad mediator, what realistic ramp — start a conversation. And for the broader picture, our interactive practice and the founding developer programme cover how we help studios add web-native channels without breaking their existing operations.