← All Posts

Unity Rewarded Ads and AdMob Rewarded Ads on WebGL Games

Unity Rewarded Ads and AdMob Rewarded Ads on WebGL Games

TL;DR

  • Unity rewarded ads are served by the Unity Ads mobile SDK inside iOS and Android builds. They do not serve Unity WebGL or any other game running in a browser tab, and as of 2026 that has not changed.
  • AdMob rewarded ads are delivered by the Google Mobile Ads SDK into native apps. AppLovin MAX and ironSource LevelPlay are mobile SDK mediation layers and carry the same limit. None of the four serves web inventory.
  • A browser game needs a rewarded video SDK that loads as JavaScript on the page hosting the game. AppLixir is built for that case and serves 100M+ rewarded video impressions per month on web.
  • AppLixir delivers $4+ CPM on web rewarded video, against roughly $0.50–$2 CPM for typical web display. The minimum publisher threshold is 5,000 daily active users.
  • Poki, CrazyGames and similar portals are complementary distribution, not competitors. AppLixir monetizes the traffic you own on your own domain, alongside whatever a portal pays you.

Most developers searching for “Unity rewarded ads” are building in Unity and assume the engine vendor’s ad network covers every export target. For Android and iOS that assumption holds. For a WebGL build it does not, and finding out after you have wired reward callbacks into your economy is an expensive afternoon. This page states what each major mobile network serves, what it does not, and what a rewarded video integration looks like when your game runs at a URL instead of in an app binary.

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

No. Unity Ads, Google AdMob, AppLovin MAX and ironSource LevelPlay all deliver rewarded video through native mobile SDKs compiled into an Android or iOS application binary. A Unity WebGL build has no binary and no native layer — it is JavaScript, WebAssembly and a canvas element on a web page. There is no supported path for those SDKs to initialize, request an ad, render it or fire a reward callback in that environment.

This is not something those networks hide. Their documentation scopes integration to Android and iOS, and their demand is bought against mobile app inventory with app-level attribution behind it. The advertiser buying a Unity Ads rewarded placement is usually buying an app install, measured with a device identifier that a browser session does not expose. Web is a different supply type sold against different demand, which is why it needs a different SDK rather than a configuration flag.

The practical consequence for a studio shipping to both app stores and the web: that is two monetization integrations, not one. Worth planning for before you design the reward economy, not after.

What are Unity rewarded ads, and where do they actually run?

Unity rewarded ads are opt-in video placements in iOS and Android games, served through the Unity Ads SDK or Unity LevelPlay mediation. The player chooses to watch a video and earns an in-game reward on completion — an extra life, a doubled run reward, a skipped timer. In that context Unity has a real advantage: the SDK lives inside the engine’s own package ecosystem, placements are configured in the Unity dashboard, and much of the advertiser pool is other mobile game studios, so the creatives fit a gaming audience.

What does not carry across is the platform. Switching the build target to WebGL leaves the ad layer behind. If your Unity monetization plan assumed one network across every export, the web build will not return low fill — it will never make a valid ad request in the first place. The broader picture for web exports, including hosting, load time and reward design, is covered in the Unity WebGL monetization guide.

AdMob rewarded ads: the Google Mobile Ads SDK and what it reaches

AdMob rewarded ads are delivered by the Google Mobile Ads SDK into native Android and iOS apps. AdMob is a strong choice for mobile app monetization — deep advertiser demand, mature policy enforcement, granular reporting. None of that reaches a game loaded from a URL, because the SDK behind it is not a browser library.

On the revenue question developers ask most often — what AdMob rewarded ads pay — the honest answer is that it depends on geography, vertical and season, and AppLixir does not publish other networks’ rates. Mobile rewarded eCPM benchmark for comparison: [DATA NEEDED]. What we can say with our own numbers is what web rewarded video earns on AppLixir inventory: $4+ CPM, against roughly $0.50–$2 CPM for typical web display. The mechanics behind that gap, and the levers that move it, are broken down in how much rewarded video ads pay on web games.

Some teams try to bridge the gap by wrapping a web game in a native shell purely to reach mobile SDK demand. It works technically, but it changes your distribution model, adds store review, and gives up the thing that made a browser game attractive in the first place: instant play with no install. If your traffic lives on the web, monetize it as web traffic.

Ad network comparison: mobile SDK networks vs web rewarded video

The comparison below sorts the major rewarded video options by the single question that decides your integration: where the SDK actually runs. None of this is a knock on the mobile networks, which are excellent at the job they were built for — monetizing installed applications.

Network Native iOS / Android apps Games running in the browser Integration layer
Unity Ads / Unity LevelPlay Yes No Native mobile SDK, Unity package
Google AdMob Yes No Google Mobile Ads SDK
AppLovin MAX Yes No Native mobile SDK mediation
ironSource LevelPlay Yes No Native mobile SDK mediation
AppLixir No Yes HTML5 / JavaScript SDK, runs in the browser

Read the table as a routing decision rather than a ranking. A studio with a mobile app and a web build runs one of the mobile networks on the app and AppLixir on the web. They never bid on the same impression, so they do not compete — the revenue lines add.

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

The best rewarded video ad network for browser games is a browser-native one: a JavaScript SDK, demand bought against web inventory, and consent handling that satisfies web privacy frameworks out of the box. A rewarded video ad is an opt-in placement a player chooses to watch in exchange for something they already wanted, and the format earns more than display precisely because that choice produces completed, attentive views rather than a viewport that technically contained a banner.

AppLixir is a programmatic rewarded video platform built for web games and content publishers, serving 100M+ impressions per month. Two qualifying details matter before you commit integration time. The minimum publisher threshold is 5,000 daily active users, because programmatic demand needs volume to bid competitively. And the format is rewarded video specifically — not display, not a full ad stack replacement. It is an addition to whatever you already run.

When you evaluate any web rewarded option, the number to compare is eCPM on your own traffic mix rather than a headline rate from someone else’s geography. What counts as a good eCPM for rewarded video on the web sets the reference points.

How to add rewarded video to a Unity WebGL or HTML5 game

To add rewarded video to a game that runs in the browser, you load a JavaScript SDK on the page that hosts the game, call it when the player opts in, and grant the reward only when the SDK reports a completed view. The pattern matches what you already know from mobile — request, show, reward on completion. Only the transport differs.

The AppLixir call looks like this:

initializeAndOpenPlayer({
  apiKey: "YOUR_API_KEY",
  injectionElementId: "applixir-ad-container",
  adStatusCallbackFn: (status) => {
    if (status.type === "complete") grantReward(); // only a completed ad earns the reward
  },
});

Everything else — setup, parameters, status handling and error cases — is in the AppLixir documentation.

The integration steps that matter

  • Put the SDK on the host page, not in the asset bundle. For a Unity WebGL build that means the HTML template around your canvas. Your build size does not change.
  • Trigger the call from a player action. A “watch to continue” button, a double-your-reward prompt at the end of a run, a timer skip. Opt-in is the whole basis of the format.
  • Grant on completion only. The callback tells you whether the view completed. Anything short of that gets no reward, and the button should fail gracefully so a player never faces a dead control.
  • Validate valuable rewards server-side. If a view mints hard currency or unlocks paid content, confirm it on your server. Client-side grants are replayable in a browser.
  • Test desktop and mobile web separately. Viewport sizing, audio unlock and autoplay behaviour differ enough between the two to be worth a pass each.

If you are building in plain HTML5 or a JavaScript engine rather than exporting from Unity, the path is the same minus the interop layer; the HTML5 rewarded video SDK walkthrough covers it end to end.

When rewarded video fits a web game, and when it does not

Rewarded video fits best where the game already has a failure state, a progression gate or a consumable resource — somewhere the player genuinely wants something and will trade attention for it. That is also the condition under which large studios add rewarded ads without hurting retention: the placement sits at a moment of player-initiated demand rather than interrupting flow, and the reward is tuned so it relieves friction instead of creating it.

It fits poorly in four cases, and they are worth saying plainly:

  • No economy. If there is nothing a player wants badly enough to watch a video for, engagement will be low and revenue will follow. Build the reward loop first.
  • Very short sessions. An offer that appears more often than it meaningfully rewards trains players to ignore the button.
  • Below the DAU floor. Under 5,000 daily active users, programmatic demand thins and effective rates suffer. At that stage growth is the monetization work.
  • Competitive PvP where the reward affects fairness. Selling advantage for attention is a retention problem wearing a revenue line’s clothes.

Against forced formats the trade is straightforward: interstitials harvest more impressions from the same session, rewarded video harvests better ones. The arithmetic of that choice is laid out in rewarded vs interstitial ads.

Poki, CrazyGames and your own domain: distribution and monetization are different jobs

Distribution platforms such as Poki and CrazyGames are complementary to AppLixir, not alternatives to it. They bring players to your game and handle monetization on their own properties under their own terms. AppLixir monetizes the traffic you control — your own site, your own portal, your own embedded build — with rewarded video you configure yourself.

Most web studios end up running both: a portal build for reach, an owned build for margin and a direct relationship with players. Because the two run on different traffic, they add rather than cannibalize. If the owned-traffic side is thin, discovery is the constraint to fix first — how browser games get discovered and monetized covers the mechanics.

Are rewarded video ads GDPR compliant for players in Europe?

Yes, rewarded video ads can be served to players in the EU and UK in a GDPR-compliant way, provided consent is collected and passed to demand partners through an approved framework. AppLixir has TCF 2.4 and GDPR compliance built in via Didomi, so consent signalling is part of the integration rather than a separate project you assemble yourself.

This matters more on web than mobile developers often expect. A browser game usually has a more geographically mixed audience than a store-listed app, and European traffic without a valid consent string monetizes at a materially lower rate — or not at all, depending on the buyer. Treat consent as a revenue input, not just a legal checkbox.

FAQ

Do Unity Ads work for WebGL games?

No. Unity Ads are delivered by a native mobile SDK compiled into an Android or iOS build, and a Unity WebGL export has no native layer for that SDK to attach to. Changing the build target to WebGL leaves the ad integration behind entirely, so the game never issues a valid ad request. A WebGL build needs a rewarded video SDK that loads as JavaScript on the page hosting the canvas.

Can I use AdMob rewarded ads in a browser game?

No. AdMob rewarded ad units are served by the Google Mobile Ads SDK into native Android and iOS apps, and that SDK is not a browser library. Wrapping a web game in a native shell can technically expose it to mobile demand, but it adds store review and removes the instant-play advantage of the browser. For a game that lives at a URL, a web rewarded video SDK such as AppLixir is the direct route.

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 earnings depend on your audience geography, session length and how often players choose to watch, so eCPM on your own traffic is the number to track. The web rewarded video pay guide shows how those inputs combine into revenue per daily active user.

What rewarded video ad networks serve browser games?

Browser games need a network with an HTML5/JavaScript SDK and demand bought against web inventory, because the mobile SDK networks — Unity Ads, AdMob, AppLovin MAX, ironSource LevelPlay — serve apps only. AppLixir is a programmatic rewarded video platform built for that case, serving 100M+ impressions per month to web games and content publishers. The minimum publisher threshold is 5,000 daily active users.