When you play a game on Glaze Games, you will occasionally see an advertisement run inside the game viewport — a pre-roll before the first frame, a 15-second video between levels, or a banner along the bottom of the play area. We want to be completely honest about where each of those ads comes from, which ones we control, which ones we cannot control, and how we protect your browser from the malicious networks that ruin most other game portals on the web. This post is the long, technical version.
The short version is this: every ad you see *around* a game on glazegames.com is ours, and we take responsibility for every line of creative that loads through our slots. Every ad you see *inside* a game iframe is part of the game itself — embedded in the HTML5 build by the original studio and the licensed catalog we sourced the game from. We do not add anything to that stream, but we also cannot strip it without breaking the game and breaking the studio's revenue.
#The technical architecture of the game sandbox
To understand how ads end up where they do, you have to understand how a game gets onto your screen. Glaze Games is a curated portal, not a hosting platform. We do not run servers full of game binaries. Each game lives on the original studio's CDN, served through a licensed catalog feed. When you open a game page, our server picks the canonical embed URL for that title, attaches a few referrer parameters so the upstream catalog can verify us as the publisher, and renders an <iframe> element pointing at it.
That <iframe> is the security boundary. Everything outside of it is our code: our header, our navigation, our description card, our recommended-games rail, our footer. Everything inside it is the game build — including any ad SDK the studio compiled in. Browsers enforce a same-origin policy on top of all of that, which means we literally cannot read, modify, or delete anything that runs inside the game container. We can choose whether to load it, but we cannot edit it.
We wrap the container with the strictest browser policies we can without breaking gameplay. The allow attribute scopes the permissions the game can request:
allow="autoplay *; fullscreen *; gamepad *; gyroscope *; accelerometer *; clipboard-write *"
Each entry is deliberate. autoplay lets the game start audio without a click. fullscreen is required for the expand-screen button. gamepad enables controller input on supported games. gyroscope and accelerometer allow mobile titles to read tilt. clipboard-write lets a few puzzle and creative-mode games copy a save string. Permissions we do not list — geolocation, camera, microphone, midi, payment, persistent-storage — are denied by the browser at the platform level, before the game can even ask.
The single most important thing we do not enable is top-level navigation. The allow-top-navigation and allow-top-navigation-by-user-activation flags are explicitly absent from our sandbox configuration. That one decision is what stops the entire category of "tap anywhere → redirected to a sketchy store" pop-unders. If a malicious ad inside a game tries to navigate your tab away from glazegames.com, the browser silently blocks it. The ad still loads, but it cannot drag you off the page.
#Why the games come with ads already baked in
Most browser games are free to play. The studio that built them is paid by an ad SDK that fires three or four times per session: a pre-roll before gameplay starts, a rewarded video the player can opt into for an in-game bonus, and an interstitial between levels or after a loss. That SDK is part of the game build itself, not something we attach.
If we stripped those ads, the studio would simply pull the title from the upstream catalog within a week — because the SDK is also how they get paid for our players. The honest middle ground is the one every major catalog operates on: the studio keeps their existing ad stream, we vet each title for the *kind* of ad SDK it ships with, and any game using a network on our blocklist (popunder networks, fake-virus-warning networks, drive-by-download networks) never lands on the site in the first place.
About one in twelve titles we evaluate gets rejected at this gate. The most common reasons are: a non-skippable mid-game video over thirty seconds, an audio ad that plays without a mute control, an SDK that opens a new tab on first input, or a creative that imitates a system dialog ("Your device may be infected — click here"). We treat any of those as a permanent rejection. The studio can resubmit if they switch SDKs.
#Ad fatigue: the mathematical reality
Most game portals treat advertising as a short-term optimization game. They inject their own pre-rolls on top of the upstream ones, wrap the iframe with flashing banners, fire interstitials between every page navigation, and let any creative through as long as the eCPM is high. It works for the first session — and then the player never comes back.
Our internal retention model shows the cost of each layer of ad density. A user opening a game on a clean layout has roughly a 2% exit rate in the first sixty seconds. Adding a top-of-page banner adds one to two points. Adding an autoplay audio ad inside the game adds twelve. Adding a non-skippable thirty-second pre-roll on top of the studio's own pre-roll adds another twenty. By the time you stack the four layers a typical aggressive portal runs, you are losing roughly one in three players inside the first minute.
That single statistic is what most operators miss. The aggressive layout earns more per session, but it earns it from a session pool that is shrinking week over week. The restrained layout earns less per session, but it compounds — players come back, they play more games per visit, and they tell other people. The math comes out clearly in favor of restraint at any reasonable discount rate.
Concretely: at our current ad density, our trailing thirty-day repeat-visit rate sits at roughly 2.1x the industry baseline for browser-game portals. We earn 30 to 40 percent less revenue per individual session than an aggressive portal does, but we earn it across a session base that doubles every nine to twelve months. The long-run revenue line crosses theirs around month fourteen and never crosses back.
#Our "clean-chrome" design system
On our side of the iframe boundary — the only side we control — the rule is simple: nothing on top of the play area, ever. No interstitials between page navigations on the same game. No pre-roll we control on top of the studio's pre-roll. No countdown timers blocking the player from clicking back to the catalog. No frequency-capped pop-overs that detect a tab switch and fire on return.
The display slots we do run are placed deliberately. Above the game player, in the breathing room between the navigation pill and the title card, sits a single leaderboard slot — that one is reserved real estate, so the layout never shifts when the creative loads. In the right rail on desktop, we render a 300×250 medium-rectangle that scrolls with the page. On mobile, the rail collapses and we move the rectangle to below the player. That is the full inventory. No floating, no expanding, no sticky pop-overs.
Every slot has a reserved aspect-ratio container with min-height matching the creative size, so the page's Cumulative Layout Shift score never moves when the ad arrives. This is a small detail that compounds: a layout that does not jump under your cursor is a layout you do not accidentally click on, which means our ad-click-through rate is lower than the industry baseline but our genuine click-through rate is higher.
#How we vet the upstream feeds
Every game in our catalog arrives nightly through licensed HTML5 catalog feeds. Each feed gives us a manifest of titles with metadata — title, slug, embed URL, screenshots, categories, rating, play count. Before any new title lands on the live site, it passes through a three-stage check.
Stage one is automatic: we run the embed in a headless browser across five viewports (1440, 1280, 1024, 414, and 360 pixels wide) and capture every network request. Anything that makes a request to a domain on our blocklist of aggressive ad networks gets routed straight to the quarantine queue. Anything that triggers a popup, prompts for permission to send notifications, or invokes geolocation in the first sixty seconds is rejected at this stage.
Stage two is metadata. Titles tagged for gambling, real-money casino mechanics, lootbox-as-core-loop, or any age rating above 12+ are rejected. Titles whose SDK fingerprint matches a known aggressive-ad payload from past rejections are auto-rejected even if the new feed entry looks clean.
Stage three is human. Borderline titles — ones that passed the automation but tripped a soft flag — get hand-played by an editor. Same with everything that lands on a /best/... list or in a /g/... guide. The editor plays for at least three minutes, checks for ad behavior we cannot reproduce in automation (some SDKs only fire after a certain in-game milestone), and writes a one-line decision. About a third of borderline titles get a yes.
#Where the model is still wrong
Two things we want to fix that we have not fixed yet. First, when a game ships with a rewarded video the player opts into for an in-game bonus, we cannot tell from outside the iframe whether the SDK delivered the reward. Roughly one in fifty rewarded-video impressions results in a delivery failure on the studio's side and the player loses their reward. We are talking with our upstream catalogs about a postMessage standard that would let us detect failures and flag them.
Second, mid-game interstitials cannot be cleanly opted out of from our side. The studio decides the frequency in their build. The most aggressive interstitial cadence we have seen — one full-screen ad every twelve seconds of gameplay — would normally be a hard rejection, but a few popular titles ship with it and players ask for them. We have started a project to flag specific titles with a heavy-interstitial warning chip on the game card so players know what they are walking into before they click. That ships next quarter.
#The future: direct indie licensing
The long-term plan is to bypass third-party catalog feeds for our highest-traffic titles entirely. We are quietly running a direct-licensing pilot with a handful of indie studios where we pay a flat monthly licensing fee in exchange for a clean build with no ad SDK at all. Players see no in-game ads. The studio gets a stable, predictable revenue stream that is not tied to bidder fluctuations. We get a small library of premium, ad-free titles we can promote on the home page and in our newsletter without any of the caveats this whole post has been about.
The economics only work if we can offer studios more than they would otherwise earn through SDK ads, which is a high bar — the most popular titles already earn five figures per month through their existing ad stream. So the pilot is starting small. The first three titles signed last quarter. The plan is to grow the ad-free shelf to roughly two hundred titles over the next eighteen months, prioritized by editorial taste rather than by upstream feed availability.
#What you can do
If you see an ad inside a game that crosses a line — an audio ad with no mute, a creative that imitates a system dialog, a non-skippable video over thirty seconds, anything that opens a new tab on its own — please send us the game URL at [email protected]. One reply, no form. We will either fix the configuration on our end, pull the title from the catalog, or get it back to the upstream feed with a removal request. The fastest pull-from-catalog we have done from a player report is forty minutes. Most are resolved within a business day.
And if you find a game on Glaze Games that you genuinely love and want to support beyond just playing it — open the title's detail page, scroll to the credits, click through to the studio's own site, and follow them there. Almost every studio whose game is on our portal also runs a Patreon, a Discord, or a mailing list. That direct support keeps the indie-game web alive far better than any portal ad ever will.