HTML5 Game Ad SDKs Compared (2026): CrazyGames, Poki, Playgama

HTML5 Game Ad SDKs Compared (2026): CrazyGames, Poki, Playgama

Honesty note: I integrated the CrazyGames SDK into my game (Merge Fish 2048) and designed it to degrade to a simulated mode when the SDK isn’t present. This comparison comes from that integration plus 2026 public SDK docs. Where I’m citing third-party numbers, I say so.

TL;DR

1. All HTML5 ad SDKs share the same shape — an iframe-injected SDK object you call to request ads, with callbacks for results — but they differ in integration model (direct SDK vs. a bridge like Playgama), mode detection, and requirements.
2. Design for the SDK being absent. Your game runs on 50+ portals with different SDKs; a reward manager that detects the SDK and falls back to a simulated grant works everywhere and lets you develop without waiting for portal approval.
3. The 2026 reality is consolidation around bridges. Playgama Bridge, GameDistribution and similar let one build reach many portals with one integration — at the cost of a share of revenue (see the monetization guide for splits).
4. Callbacks, not promises, dominate. SDKs use callback-style APIs; your manager should wrap them so the rest of your game never touches SDK specifics.

The common shape of an ad SDK

Every HTML5 portal SDK does roughly this:

1. You include a script tag (or it’s injected into your iframe by the platform).
2. You call lifecycle signals: game loading start/stop, happytime moments.
3. You request an ad with a type (rewarded, interstitial) and get a success/failure callback.
4. Optionally you get user/player info and payment APIs for IAP.

The differences are in the details — and the details determine how much code you need to write and maintain.

How the main options differ (2026)

Two practical takeaways:

• Direct SDKs (CrazyGames, Poki) give you full control and the best revenue share, but you maintain one integration per portal.
• Bridges (Playgama, GameDistribution) cut integration to one build for many portals, at the cost of share and a layer you don’t control.

Mode detection: make the SDK optional

The single most useful pattern from my integration — detect the SDK, and if it’s missing, run a simulated mode:

_detectMode() {
  try {
    if (window.CrazyGames && window.CrazyGames.SDK) return 'crazygames';
  } catch {}
  return 'simulated';
}

Why this matters:

• You can develop and playtest the full game before the portal approves you — the reward flow works, just with a fake 2s delay instead of a real ad.
• The same build runs on any portal or even your own site — no SDK, no crash, the reward simply grants.
• Platform review is faster — reviewers see a game that works without their SDK too, which is what they test.

A RewardManager that isolates the SDK

Keep the SDK behind one class so the rest of the game never touches it:

showRewarded(callback) {
  if (this.busy) { callback(false); return; }
  this.busy = true;
  if (this.mode === 'crazygames') {
    try {
      window.CrazyGames.SDK.ad.requestAd('rewarded',
        () => {},
        (success) => { this.busy = false; callback(!!success); },
        { adType: 'rewarded' }
      );
    } catch { this.busy = false; callback(false); }
  } else {
    setTimeout(() => { this.busy = false; callback(true); }, 2000);
  }
}

Three details worth copying:

1. busy guard — prevent re-entrancy so a player can’t stack reward requests (and portals can’t flag your game for spamming ad requests).
2. try/catch around every SDK call — if the SDK throws, your game must not crash; degrade to callback(false).
3. Callback style throughout — the game calls showRewarded(cb) and doesn’t care whether the backend is CrazyGames, Poki, or simulated.

Lifecycle signals: the part everyone forgets

Portals use these to measure load time and engagement — getting them wrong costs you placement:

gameLoadStart() { /* SDK.game.gameLoadingStart() */ }
gameLoadStop()  { /* SDK.game.gameLoadingStop() */ }
happytime()     { /* SDK.happytime() */ }

Call gameLoadingStart as early as possible and gameLoadingStop when your main scene is interactive. Call happytime on genuinely satisfying moments (a big merge, a level up) — portals reward games that reward the player.

Pitfalls

1. Calling ads before init/loading signals — several SDKs (Poki especially) require init and loading progress before any ad call; read the init contract first.
2. External network calls in the iframe — portals block them; analytics SDKs and raw fetch calls are the top rejection reason (see the marketing guide).
3. Ad-blocker script naming — scripts whose file names contain “ad” can get blocked by URL-pattern blockers; name your integration files neutrally (more in the monetization guide).
4. No degradation path — if your game hard-crashes without the SDK, you can’t test locally, demo on itch.io, or survive a portal’s review flow.
5. Ignoring the busy flag — rapid repeated ad requests look like abuse to portals and players alike.

Bottom line

The SDK landscape in 2026 is: pick a direct SDK (CrazyGames, Poki) for control and best share, or a bridge (Playgama, GameDistribution) for reach with one integration. Whichever you choose, isolate it behind a manager with mode detection and a simulated fallback — that single pattern keeps your game portable, testable before approval, and review-friendly on every platform. Revenue math and realistic expectations are in the income breakdown.