Browser games have no store billing, no store-attached ad SDK and no algorithmic recommendation feed. Everything that turns a session into revenue is something the developer wires in. That is the cost of the platform, and it is also the reason web monetization economics can be better than mobile: there is no 30% store cut sitting between the player and the publisher. This guide covers which formats work in the browser, what they pay, which networks actually serve web, and how to decide whether rewarded video belongs in your game at all.

What is browser game monetization?

Browser game monetization is the practice of generating revenue from a game that runs in a web browser — HTML5, WebGL, Unity WebGL, Godot web export or plain JavaScript — using advertising, in-game purchases, subscriptions or platform revenue share, rather than app store billing. Three structural differences separate it from mobile game monetization. First, there is no store payment rail, so purchases run through Stripe, PayPal, a payments provider or a portal’s own wallet. Second, there is no bundled ad SDK: the networks that ship with mobile builds target iOS and Android apps, not browsers. Third, discovery is distributed across search, social, portals and direct links, which means a single game can have traffic on several domains at once, each monetized differently. The practical consequence is that web monetization is a stack decision, not a checkbox. A typical browser game earns from some combination of rewarded video on its own domain, revenue share on portals where it is also published, and direct payments for cosmetics, currency or ad removal. The economics of game monetization across models and metrics apply to web the same way they do elsewhere; only the plumbing changes.

How much do browser games earn per format?

Web game revenue per format varies by an order of magnitude. Rewarded video is the top of the stack: AppLixir delivers $4+ CPM on web rewarded video, while typical web display inventory on game sites runs roughly $0.50–$2 CPM. The gap exists because a rewarded impression is opt-in, fully viewable, sound-on and completed — the three signals advertisers pay the most for.

Format	What it pays on web	Player impact	Best fit
Rewarded video	$4+ CPM delivered by AppLixir	Opt-in; player initiates, so no forced interruption	Games with currency, lives, hints, continues or boosts
Display / banner	~$0.50–$2 CPM typical web inventory	Passive; competes with gameplay for screen space	Portal pages, menus, lobby and between-level screens
Interstitial video	Above display, below rewarded in most web setups	Forced; risk to session length if over-frequent	Natural breaks only — level end, death, map change
In-game purchases	No CPM; ARPPU-driven, no 30% store cut on web	None for non-payers	Progression, cosmetics, ad removal
Subscription / ad-free pass	Recurring; replaces ad revenue for that user	Positive for committed players	Daily-habit games with strong D30 retention
Portal revenue share	Set by the platform, on the platform’s traffic	None on your domain	Audience acquisition alongside owned traffic

The arithmetic that matters is not CPM alone. Daily rewarded revenue is approximately: DAU × share of players who opt into at least one ad × ads watched per engaged player × CPM ÷ 1,000. A $4 CPM against a 15% opt-in rate earns less than a $3 CPM against a 45% opt-in rate, which is why placement design outranks network shopping. For the full calculation with worked examples, see how much rewarded video ads pay on web games, and for target benchmarks, what counts as a good eCPM for rewarded video on the web.

Why rewarded video ads lead web game monetization

A rewarded video ad is a full-screen video a player chooses to watch in exchange for an in-game benefit — currency, an extra life, a hint, a revive, a time skip. The player opts in, the ad plays to completion, a callback fires, and the game grants the reward. Nothing is interrupted, because nothing started without the player’s tap. That structure is why rewarded video outperforms other web ad formats on three axes at once:

• • Yield. Opt-in, completed, viewable video is the most valuable web inventory a game publisher has. $4+ CPM versus $0.50–$2 for display is a 2–8x difference on the same session.

• • Retention. Forced formats push sessions shorter. A rewarded placement attached to a failure state (“continue?”) does the opposite — it extends the run the player was already invested in.

• • Compatibility with purchases. Rewarded video monetizes the 95%+ of players who will never pay, without removing the reason to pay. Watching three ads for 300 coins tells a player what 3,000 coins would feel like.

The format also fails in predictable ways. A reward that is too generous collapses the purchase economy. A reward nobody wants produces a 2% opt-in rate and a dead placement. An unlimited rewarded loop invites farming. The difference between the formats, and where each belongs in a session, is covered in rewarded versus interstitial ads on web games.

Do Unity Ads, AdMob or AppLovin work for browser games?

No. Unity Ads, Google AdMob, AppLovin and ironSource are mobile application SDKs. They serve ads inside native iOS and Android apps and they do not serve browser games. If you export a Unity project to WebGL, the Unity Ads package does not come with it — the ad calls have no native layer to bind to, and the build will not fill. This surprises studios porting from mobile more than anything else in the web stack. The game runs. The analytics run. The monetization does not. There is no misconfiguration to fix; the networks simply operate on a different surface. AppLixir exists for the surface they do not cover: rewarded video served in the browser, delivering 100M+ monthly impressions across web games and content sites. A practical reading of the landscape:

• • Mobile network SDKs (Unity Ads, AdMob, AppLovin, ironSource): native app inventory. Keep them for your iOS and Android builds.

• • Web display networks and header bidding wrappers: page-level banner and video inventory, typically around $0.50–$2 CPM on gaming traffic.

• • Web rewarded video (AppLixir): in-game, opt-in, player-initiated inventory on your own domain, at $4+ CPM.

These are additive, not alternatives. A web game can run display in the page shell and rewarded video inside the canvas on the same session. The detailed network-by-network breakdown is in whether Unity rewarded ads and AdMob work on WebGL.

How Poki, CrazyGames and your own domain fit together

Poki, CrazyGames, Newgrounds and similar portals are distribution channels, and they are complementary to a direct monetization stack rather than competitive with it. They bring audience a solo developer cannot buy — millions of players browsing for exactly the kind of game you built — and they monetize the sessions that happen on their domains under their own terms. What they do not monetize is your traffic. The players who arrive from a Google search for your game’s name, from a YouTube video, from a Discord link or from your studio’s site are playing on your domain, and that inventory is yours. For most web studios the healthy pattern is both: publish to portals for reach, run rewarded video on the owned build for margin. That split also changes how you read your numbers. Portal revenue is reported by the portal and moves with their fill and their audience mix. Owned-domain rewarded revenue moves with your opt-in rate, your reward design and your geo mix, all of which you control. Treating them as one line item hides which lever is actually working.

In-game purchases, subscriptions and hybrid monetization

Hybrid monetization — rewarded ads plus in-game purchases in the same economy — is the default model for successful free-to-play web games, because the two formats serve different populations. The large majority of players will never make a purchase; rewarded video is the only way they contribute revenue. The small minority who do pay generate most of the direct revenue, and on the web they do it without a 30% store commission. Three rules keep the two from cannibalizing each other:

• • Different currencies or different tiers. Rewarded ads pay out soft currency and consumables; purchases cover hard currency, cosmetics and permanent unlocks.

• • Cap the ad path. A daily ceiling on rewarded views per player protects the purchase economy and reduces farming.

• • Price the ad-free pass honestly. If a subscription removes interstitials, keep rewarded video available as an opt-in — subscribers often still want the reward.

Design patterns and the failure modes to avoid are set out in hybrid monetization combining rewarded ads and IAP.

When rewarded video is the wrong call for a web game

Rewarded video is not a universal fit, and integrating it into the wrong game wastes an afternoon and produces a placement nobody uses. AppLixir’s publisher threshold is 5,000 DAU, which is itself a useful filter: below that, the compounding return on retention and distribution work is larger than anything an ad stack can add. Skip or defer rewarded video when:

• • There is no reward sink. A narrative game, a puzzle with no currency and no fail state, or a tool-like experience has nothing meaningful to grant. Inventing a currency purely to host an ad is visible to players and performs badly.

• • Sessions are under a minute with no repeat loop. A 30-second novelty game cannot support a 30-second ad; the ratio reads as a toll, not a trade.

• • The game is premium or paid. Players who bought the game should not be asked to watch ads for parity.

• • Traffic is entirely on a portal. If every session happens on a partner’s domain, their monetization already covers it. Build owned traffic first.

Conversely, rewarded video is close to a default when a game has an energy system, a fail state worth retrying, a daily bonus, a gacha or shop economy, or a hint mechanic — all of which give the player a reason to choose the ad. The evidence on whether the format actually clears meaningful revenue on web is in do rewarded ads actually make money on web games.

How to add rewarded video ads to a web game

Adding rewarded video to a browser game is a front-end integration plus a reward-granting path, and for most HTML5 or Unity WebGL builds it is a single working session rather than a sprint. The sequence below is the one that holds up in production.

The integration steps

1. 1. Pick the reward and the moment. Decide what the player gets and where the offer appears — death screen, daily bonus, shop doubler, hint button. Write the cap per player per day before writing any code.

1. 1. Load the rewarded video ads SDK. Add the AppLixir script to the page hosting the game and initialize it with your zone or account identifier. No native layer, no build pipeline change.

1. 1. Wire the call behind a player action. The ad request fires from a button, never automatically. For Unity WebGL this means a JavaScript interop call from the C# layer.

1. 1. Grant on the completion callback only. Handle the distinct states — completed, skipped, error, no fill — and grant the reward on completion. Validate the grant server-side where the economy has real value.

1. 1. Test fill and consent across geos. Check behaviour for EU traffic with the consent dialog, and confirm the game does not block on a no-fill response.

1. 1. Measure ARPDAU, not CPM. Track opt-in rate, ads per engaged player and session length alongside revenue. CPM in isolation will mislead you.

Framework-specific walkthroughs are in the HTML5 rewarded video SDK guide.

Consent and reward abuse

European traffic requires a valid consent signal before personalized ads can serve. AppLixir ships TCF 2.3 and GDPR compliance built in via Didomi, so the consent string is collected and passed to demand partners without the publisher building a CMP. That matters for yield as much as for law: traffic without a valid consent string monetizes at a lower rate. Reward abuse is the other operational risk. Players who discover that a reward can be claimed by replaying the callback, clearing storage or scripting the button will drain the economy quickly. Server-side validation, per-player daily caps and anomaly checks on reward grants handle most of it; the specific controls are described in preventing rewarded ad fraud and reward abuse.

FAQ

What is the best rewarded video ad network for browser games?

The practical shortlist is short, because most large rewarded networks are mobile SDKs that do not serve the browser. AppLixir is built specifically for web games and content publishers, serves 100M+ rewarded impressions a month, and delivers $4+ CPM on web rewarded video. Evaluate any web rewarded provider on three things: whether it genuinely serves browser inventory, what it delivers on your geo mix, and whether consent handling is built in.

How much do rewarded video ads pay on web games?

AppLixir delivers $4+ CPM on web rewarded video, compared with roughly $0.50–$2 CPM for typical web display inventory. Actual revenue depends on how many of your daily players opt in and how many ads each one watches, so a game with 10,000 DAU and a strong reward sink can out-earn a larger game with a weak placement. Calculate it as DAU × opt-in rate × ads per engaged player × CPM ÷ 1,000.

Do Unity Ads or AdMob work for WebGL and browser games?

No. Unity Ads, AdMob, AppLovin and ironSource serve native iOS and Android applications and do not serve browser games. A Unity WebGL export cannot call those SDKs, because the native layer they depend on is not present in a browser build. Web games need a provider that serves browser inventory directly, which is the gap AppLixir fills.

Are rewarded video ads GDPR compliant for players in Europe?

They can be, provided a valid consent signal is collected before personalized ads serve. AppLixir includes TCF 2.3 and GDPR compliance built in through Didomi, so the consent management and the consent string passed to demand partners are handled at the ad layer rather than by the publisher. Enterprise studios should still confirm that their own site-level CMP and the ad layer are not issuing conflicting signals.