Every Captive Portal Vendor Sells 'Gamification.' iOS's Mini-Browser Is 900×572 Pixels.

Guest WiFi splash pages are a $1.3B market in 2026 and every vendor deck in the category promises gamification. The 900×572 pixel mini-browser Apple opens to display those splash pages will not save a cookie, will not fire window.alert, and will read only a stripped subset of JavaScript. The game you paid to embed either does not load or times the guest out before authentication finishes. This post is about where the game actually belongs in a captive portal flow, and what a venue can measure once it is placed correctly.

The mistake is not the desire to gamify a WiFi login. It is treating the login screen and the post-login landing as the same surface. They are not. One is a sandbox drawn by the operating system to protect the user; the other is a normal browser tab that can do everything a normal browser tab can do. Confuse them and you ship a game nobody plays.

🧾 What the Splash Page Market Actually Buys

The captive portal market is not enormous by ad-tech standards, but it is real and it is growing. Grand View Research puts it at $1.95B in 2024, rising to $6.20B by 2033 at 13.9% CAGR. The Business Research Company's 2026 figure is more conservative at $1.31B, growing to $2.08B by 2030. The two firms are counting slightly different bundles — the wider number includes managed-WiFi analytics and the narrower one is closer to just the login-and-consent platform — but every serious forecast agrees on a low-double-digit growth rate through the end of the decade.

Hospitality is the biggest single vertical, at 26% of Grand View's 2024 revenue. North America takes 40.2% of global spend. The reseller economics MyWiFi Networks publishes for its partners put a typical marketed venue at $100 to $400 per month of recurring services on top of the WiFi hardware itself — email capture, splash templating, campaign analytics, CRM handoff. That is the shape of the buyer: a hotel chain, a retail estate, a coffee group, an airport concessions operator, buying a per-venue monthly package from a reseller who resells a platform like Purple, Cloud4Wi, SplashAccess or Antamedia.

Two things every one of those platforms sells: a branded splash page and "engagement," usually with the word game or spin-to-win somewhere on the deck. The first delivers as promised. The second, on the surface the vendors say it lives on, does not.

📱 The Mini-Browser Is 900×572 Pixels and Refuses Cookies

When an iPhone joins a WiFi network with an active captive portal, iOS does not open Safari. It opens the Captive Network Assistant, a mini-browser the OS built specifically for this authentication flow. macOS behaves the same way; Android has its own Captive Portal Login activity with similar constraints. The Wireless Broadband Alliance's Captive Network Portal Behavior reference catalogues the differences across OS versions and it is not encouraging reading if you were planning a rich interactive experience.

The specific limits documented across Apple developer discussions, Cisco community threads and enterprise onboarding guides:

• The Apple CNA window is fixed at 900 pixels wide by 572 pixels tall. Users cannot resize it. A game designed for a phone-shaped viewport that expects to fill the screen will not.
• Cookies are not persisted across the CNA session. State you rely on for progression, high scores, or session identity is lost the moment authentication completes and the window closes.
• window.alert and window.confirm are non-functional. Any JavaScript library that reaches for the browser confirm modal — for age gates, terms acceptance dialogs, reward claims — silently no-ops.
• Local storage and IndexedDB behave inconsistently between OS versions. Treat them as unavailable.
• Clicking any anchor tag replaces the CNA window rather than opening a new one. There is no target="_blank" behaviour to speak of.
• The CNA closes as soon as the auth flow reports success. A guest mid-game gets ejected without warning.
• Downloads are blocked at the OS level, so any game asset the CNA cannot inline into the page will not arrive.

The overriding constraint on top of all of these: during the pre-authentication window, the device has no general internet access. The whole point of the captive portal is that the guest has not yet been let onto the network. Anything your splash page tries to fetch from a CDN, a Google Font URL, a third-party analytics endpoint, or a JavaScript library hosted anywhere other than a whitelisted walled-garden domain will fail. Purple's own developer guide states the rule plainly: treat the splash page as if it has no internet connection, because during authentication it does not.

🎮 What Breaks When You Put a Game in the Splash

Take a standard HTML5 casual game — a match-three, a runner, a hidden-object level, anything under 5 MB — and look at what it needs to boot inside the CNA. It needs its engine runtime (Phaser, Construct, Pixi, Godot's web export, whatever). It needs a sprite atlas, an audio bundle and probably a font. It needs to save at least one piece of state so the guest can resume. It needs to keep the window open long enough to be played.

Every one of those needs collides with the sandbox. Engine runtimes are commonly loaded from a CDN unless you inline them; that fetch fails pre-auth. Sprite atlases and audio have to be data-URIed or served from the captive portal's own domain and its whitelisted asset paths, which most authoring pipelines do not target. Fonts do the same, though most games survive falling back to system fonts. State cannot use cookies or reliable local storage, so anything past the first level is lost. And the CNA window is going to close on successful authentication regardless of what the game thinks is happening on-screen.

So the guest lands on the splash, sees a "play to win WiFi" button, taps it, watches a spinner that never resolves because the engine is fetching from an external host, and either force-closes the CNA or dismisses the whole thing and taps the network name again. Either way, the venue captured no email, the guest got no game, and the reseller-billed monthly for engagement produced none.

There is a version of this that works — a minimal, self-contained, sub-100 KB single-file interaction, usually a scratch-to-reveal or a two-tap spin-to-win. It runs. It is also not what the word game means to any of the people signing off on the buy. Calling it a game is charitable to the technology and unfair to the guest.

👉 Put the Game After Authentication

The correct place for a real HTML5 game in a WiFi flow is the post-authentication landing page — the URL the captive portal redirects the guest to once the CNA closes and the device is on the internet in the normal way. On that page you are back inside Safari, Chrome or the guest's default browser. Cookies persist. The full JavaScript engine is available. External CDNs load. The viewport is whatever the device is. The game can be a real one.

This is how the sequence should actually be built:

1. Splash page: minimal HTML, inlined CSS, a login method that resolves in seconds. Email capture with a clear separate marketing consent tickbox, unticked by default. No game, no interactive rewards. The splash exists to authenticate and to record consent.
2. Success handoff: the captive portal marks the device authenticated and hands the browser to a post-login URL you control.
3. Landing page: a normal web page on your marketing domain. Now the game lives here — full-screen, with sound, with progression, with a real leaderboard, with a reward the guest can claim by entering an email address if they did not do so at login.
4. The reward and the game itself are the reason the guest went past step 1 in the first place. Told at the splash that the game is coming after login, opt-in rates climb because the guest sees a reason to consent that is not the WiFi itself.

The pattern is the same one an event booth uses when it puts an event game on a landing URL that the QR code on the standee redirects to. It is the same pattern a branded marketing game uses on a campaign microsite. The captive portal case is just the microsite living behind a WiFi login instead of a printed URL.

📊 The Numbers Post-Login Opt-In Actually Moves

Cloud4Wi publishes real customer-level benchmarks for what a properly designed onboarding flow captures. French shopping-centre operator Carmila runs guest WiFi across more than 200 locations and reports an 89% opt-in rate. Guess captures 35,000 new opted-in profiles per month across 750-plus stores using the same platform. Those numbers come out of splash pages that are boring: logo, quick auth, unambiguous consent checkbox, done. The engagement content — offers, games, personalised guides — lives on the redirected landing page, not in the CNA window.

The opt-in rate matters more than the raw WiFi user count. A 40% opt-in rate on a 10,000-guest month produces the same email list as an 80% opt-in on a 5,000-guest month; the difference is that the second venue is not asking guests to consent to marketing just to see a splash spinner. Cloud4Wi's own guidance for high opt-in — offer real value beyond the WiFi, keep the marketing tick separate and unticked, set expectations about frequency — is not novel. It is the same GDPR-compliant pattern any email marketer runs. The captive portal simply happens to be a moment of high venue trust where the ask converts.

Where the game changes the number: at the point of collecting the address on the landing page. A guest who has already had a working WiFi session and is now playing a genuinely playable game is a warmer address than a guest who ticked a box under a spinner. The industry has spent a decade pretending the reverse.

🔌 OpenRoaming Changes Where the Login Even Is

Worth flagging because it is a two-year forward risk on this whole surface: OpenRoaming, the Wireless Broadband Alliance standard, moves the login off the venue's captive portal entirely for devices whose identity provider participates. A guest walks in, their phone silently authenticates against Apple, Google, Samsung or a telecom operator, and there is no splash page at all. HPE's July 2025 acquisition of Juniper explicitly named Aruba plus Juniper Mist plus OpenRoaming as the combined strategic direction, and Cloud4Wi shipped Passpoint and OpenRoaming support in its 2025 platform releases.

If your engagement plan lives entirely inside the splash page, OpenRoaming deletes the plan. If it lives on a post-login landing page that the venue explicitly redirects guests to as part of the welcome sequence, it survives — the venue still controls where the browser goes on a first join, and the landing page is where the game and the address capture are anyway. Designing your WiFi engagement around the mini-browser is designing it around a surface the industry is quietly deprecating.

🌲 What Forestry Games Ships for This Slot

Forestry Games licenses HTML5 titles that are built for exactly the post-authentication landing scenario: self-contained bundles that run inside a normal browser tab, work on the phone the guest is holding, and hand the venue an obvious hook for an email or an offer. Our catalogue of 1,049 titles spans the casual formats a hospitality or retail venue can actually deploy — puzzle, arcade, hidden-object, quiz — and the HTML5 game licences we sell come with the source assets, so a reseller or venue integrator can host them on their own captive-portal landing domain rather than iframing from a third-party host. If you are running a portal for hotels, malls or airport concessions and want a games layer that survives the CNA, that is the shape of the deal.

The next post someone in this space should write is about measuring the lift honestly — comparing opt-in rates for splash-only, splash-plus-post-login-game, and splash-plus-post-login-offer flows across matched venues. Nobody has published that A/B publicly. If you run a portal at scale and want to, the numbers would settle a lot of vendor pitches.