How the Ezoic Web Games SDK Solves the ads.txt Distribution Paradox
You built a game to reach players wherever they are. Get it embedded on a handful of game portals, and traffic can jump overnight. Get it embedded on a dozen, and it can feel like you finally cracked distribution.
Then you check your ad revenue and none of it moved.
That's the paradox every HTML5 game developer eventually hits. Wide distribution is the whole point of building for the browser instead of a single app store. But the moment your game runs inside an iframe on someone else's domain, you lose the one thing that actually monetizes it: control over ads.txt. You don't own the hosting domain, so you can't sell that domain's inventory. The portal that gave you your best distribution numbers is also the portal keeping your ad revenue.
You shouldn't have to choose between the two. The Ezoic Web Games SDK exists because that choice was never actually necessary. It was just unsolved.
The ads.txt Hurdle, Explained
Ads.txt is an IAB standard that lets a domain declare which sellers are authorized to sell its ad inventory. Advertisers check it before they bid. It's a trust mechanism, and it works exactly as designed: only the domain owner can authorize sellers for that domain.
That's fine for a game hosted on your own site. It breaks down the moment your game is embedded somewhere else. A game portal loads your HTML5 game in an iframe. The iframe's content comes from your CDN, but the page itself, the domain, the ads.txt file, belongs to the portal. Any ad demand your game tries to call in from its own origin has no ads.txt to point to. Advertisers can't verify it, so they won't bid on it, so it doesn't monetize.
Developers have historically dealt with this by picking one lane. Distribute widely across portals and give up on ad revenue from those embeds, or keep the game locked to your own domain and give up on the reach. Neither is a real strategy. It's a workaround for a technical limitation that had nothing to do with how good the game is.
The Solution: A Cross-Origin Bridge
The Web Games SDK (EzGameSDK) solves this by not fighting the ads.txt model at all. Instead of trying to get your game's origin authorized everywhere it lands, the SDK routes monetization through the one domain that's already authorized: the host page.
Here's how it works. The game loads a lightweight script, gamesdk.js, and calls a small JavaScript API. Every call from inside the iframe is proxied over a postMessage bridge to the host page, which runs its own standard Ezoic integration. The host page runs the ad auction and renders the ad, confined to the game's play area, because the host page is the domain advertisers are actually bidding on. Your game never runs an auction itself. It doesn't need its own ads.txt, its own dashboard setup, or its own ad placements. It just needs to be embedded with a data-ez-game attribute on the iframe, which is the flag that tells the host page's bridge to answer the handshake.
That's the entire technical unlock: monetization now travels with the hosting domain's ads.txt, not your game's origin. Distribution and monetization stop being tied to the same piece of infrastructure. Build the game once, let it get picked up by every portal that wants it, and each embed monetizes through that portal's own ad stack. You don't lose revenue for winning distribution. You gain it.
For a developer running a single title, that's convenient. For a studio with a catalog syndicated across a dozen portals, it's the difference between an ad-tech project and an ad-tech headache.
Ready to see how the bridge works? Explore the Web Games SDK Documentation.
Beyond the Bridge: Game-Native Monetization
Solving distribution is only half the problem. The other half is doing it without making the game worse to play. Slapping a banner over the canvas or forcing a video between every action is how you win a monetization argument and lose your player base. The SDK is built around game events, not page-load events, because a game's monetization moments should look like the game, not like a website that happens to have a game embedded in it.
EzGameSDK exposes a handful of triggers built around the actual rhythm of gameplay:
commercialBreak() fires at the pauses a player already expects: level transitions, "game over" screens, a loading pause between stages. Call it with position: 'preroll' before gameplay starts or position: 'midgame' at those natural breaks, and pass an onStart callback to pause the game and mute audio right before the ad displays. You can request format: 'auto' for a video ad with display fallback, 'display' when you want something that resolves quickly between levels, or 'video' when you specifically want video demand.
rewardedBreak() is the value exchange, and it's opt-in by design. A rewarded ad should be offered, never triggered automatically: a button that says "watch an ad for an extra life," a prompt that offers a power-up, a coin bonus a player can choose to unlock. The SDK only tells you to grant the reward when the result comes back rewarded: true, meaning the player actually watched it through. Ezoic's rewarded formats are already the highest-earning format in the platform, at roughly 10x the CPM of standard display, because the player is choosing to engage instead of being interrupted.
showBanner() and hideBanner() handle the passive placements, anchored to the top or bottom edge of the game frame at whatever maximum size you specify, so a game with a HUD or a sidebar can reserve space without guessing at exact ad dimensions.
gameplayStart() and gameplayStop() are the signals that tell the host page a player is mid-session, which suppresses the host page's own page-level interstitials so they never fire on top of active play.
The result is a monetization layer that respects flow state. Players don't get pulled out of a run at random. They get a commercial break where a break was already happening, and a rewarded option where a choice already made sense. That's the difference between ads that feel like a tax on playing and ads that feel like part of the game's own reward loop, and it's the same reason EPMV-minded developers see rewarded formats outperform standard display by that kind of margin.
Scaling Your Game Studio
Once distribution and monetization stop competing with each other, the conversation changes. It's no longer "how do we protect our ad revenue by limiting where the game lives." It's "how many portals can we get this in front of this quarter." That's a scalable business model instead of a technical trade-off, and it's the difference between running ad tech as a side project and running it as infrastructure.
That's the actual job the Web Games SDK does. Rather than a plugin bolted onto a game, it's the infrastructure layer that lets a developer keep building the game while the ad auctions, the cross-origin handshake, the cooldown logic, and the fallback behavior for ad blockers and unfilled inventory all run underneath, out of the way. Every method resolves instead of throwing, so a missing ad or a blocked handshake never breaks the game itself; it just resolves with a reason and moves on.
You built the game. The distribution problem and the monetization problem no longer have to be the same fight.
Solve your ads.txt distribution hurdle. Get started with the Web Games SDK.