What is a captive portal? How WiFi login pages work
You join the WiFi in a hotel, an airport or a coffee shop, and before any website loads, a page appears asking for an email address, a room number or a tick against the terms. That page is a captive portal. This guide covers what happens on the network between joining and browsing, why the page sometimes fails to appear, the standards that are replacing the old interception method, and what a venue needs to run a portal well.
It is written for owners and managers of hospitality venues, shops and gyms, and for whoever looks after their network. The technical detail is current as of October 2026 and comes from the IETF standards and the Apple, Google, Microsoft and Mozilla documentation listed at the end.
What a captive portal is
A captive portal is a web page that a WiFi network shows a newly connected device before it lets that device reach the internet. The device is on the WiFi from the moment it joins. Until the person holding it completes the page, the network holds back every request for the wider internet or sends it to the sign-in page, which is where the word captive comes from.
The page has several names. Venue owners call it a splash page, a WiFi login page or a guest sign-in page. Network vendors call it a hotspot portal, a guest portal or a web portal, and Ruckus calls its external version a WISPr hotspot. A network that uses one is often called captive WiFi or a captive network. Strictly, the captive portal is the mechanism that holds and redirects the device, and the splash page is the page the guest lands on. Most people use the two terms for the same thing.
What the page asks for depends on why the venue runs it. A train operator may only need passengers to accept an acceptable use policy. A hotel may ask for a surname and room number, or sell a faster connection. A pub or restaurant usually asks for a name and email address so it can keep in touch after the visit, with a separate box for marketing consent.
How a captive portal works, step by step
UniFi, Omada, Meraki and the other vendors name their settings differently. Underneath, the network goes through the same nine steps each time a new device joins.
- The guest picks the network name (the SSID) and joins. Guest networks with a portal are usually open, or use Enhanced Open encryption, so there is no password to type.
- The router gives the device an IP address and a DNS server, as on any network. On newer setups the same DHCP reply also carries the address of the portal's API, which the standards section below explains.
- The device starts in a pre-authentication state. The gateway or controller allows DNS lookups and traffic to a short list of permitted hosts, the walled garden, which holds the addresses the sign-in page needs to load. Everything else is blocked or redirected.
- Within a second or two the operating system sends a test request to a known address to check whether it has a working internet connection.
- The gateway intercepts that request and replies with a redirect to the portal. The operating system sees an answer it did not expect and concludes that the network has a captive portal.
- The device opens the portal on its own, usually in a small built-in browser window. Apple calls this window the Captive Network Assistant; Android and Windows have their own versions.
- The guest completes the page: a form, the terms, a voucher code or a payment.
- The portal tells the network to let that device through. Depending on the hardware it does this through the controller's API, a RADIUS reply, or a one-time grant address the browser is sent back to. The network usually identifies the device by its MAC address.
- The gateway moves the device to full access for the session length the venue has set. When the session ends the device goes back to the portal, and a portal that recognises a returning device can let it straight through.
From the guest's side, steps two to six take a few seconds and feel like one event: they join the WiFi and the sign-in page appears.
Step eight raises a common question about privacy features on phones. iPhones and Android phones give each WiFi network a private MAC address in place of the hardware one. Android keeps one address per network by default. Apple's security guide lists open networks, Enhanced Open and captive portals among the connections where an iPhone on iOS 18 or later uses a rotating address by default, and its guide to private Wi-Fi addresses says a rotating address changes every two weeks. So a portal can recognise a returning device for a while, but an iPhone on a guest network can look new after a fortnight. The guest's identity comes from what they typed on the page, which does not change. The MAC address randomisation entry covers each system.
How phones and laptops detect a captive portal
Step four is what makes the page appear without the guest opening a browser. Each operating system checks a different address and expects a specific reply. Any other answer, including a redirect, tells it a portal is in the way.
| Device | Test address | Reply that means it is online | What the guest sees on a portal network |
|---|---|---|---|
| iPhone, iPad and Mac | A page on captive.apple.com | Apple's expected "Success" page | The sign-in page opens in a small window by itself |
| Android and ChromeOS | connectivitycheck.gstatic.com/generate_204, plus an HTTPS check to www.google.com/generate_204 | An empty reply with HTTP status 204 | A notification to sign in to the network, which opens the page |
| Windows 10 and 11 | www.msftconnecttest.com/connecttest.txt | A text file reading "Microsoft Connect Test" | A browser window opens on the page |
| Firefox, on any system | firefox-portal-detection.com (detectportal.firefox.com before Firefox 155) | Mozilla's expected page | A bar saying the network needs a login, with the page in a new tab |
Each system's main check uses a plain http:// address, because an encrypted request cannot be redirected; Android and ChromeOS add an HTTPS check alongside it. The same limit causes the most common captive portal fault, covered next.
Why the login page sometimes does not appear
A gateway can only redirect a request it can read and answer. A plain HTTP request is unencrypted, so the gateway can answer it with a redirect to the portal and the device follows it. An HTTPS request is encrypted and comes with a certificate check. If the gateway answers in the real site's place, the certificate does not match, and the browser shows a security warning where the portal should be. Sites that use HSTS go further and tell the browser never to load them over plain HTTP, so it never sends a request the gateway could redirect.
The IETF's captive portal architecture, RFC 8952, treats interception itself as the problem: solutions "MUST NOT require the forging of responses from DNS or HTTP servers or from any other protocol", and a redirected HTTP check is exactly that kind of forged answer. That is why the API in the next section exists. Until networks and devices use it, the operating system's plain HTTP check carries the whole process. When it reaches the gateway, the portal opens by itself. When something stops it, the guest opens a browser, their home page tries to load over HTTPS, and they get an error or a blank page.
On a venue network the usual causes are a walled garden that lets the operating system's test address through (so the check passes and nothing opens), a walled garden missing a host the page needs (so the page opens and never finishes loading), a VPN or content filter on the guest's phone that starts before the portal, and a guest who dismissed the sign-in window. A guest can bring the page up by opening any address that starts with plain http://, such as http://neverssl.com. Our guide to fixing a captive portal that is not showing goes through each cause and the setting to check. Chromecasts, smart TVs and card machines are a separate case, because they cannot show the page at all; the guide to Chromecast and smart TVs on guest WiFi explains how to let them skip it.
The newer standard: RFC 8910 and the Captive Portal API
Interception is a workaround, and in 2020 the Internet Engineering Task Force (IETF) published a cleaner design in three documents. RFC 8910, from September 2020, lets a network announce its portal when the device joins. The address of a captive portal API travels in the network's setup messages: DHCP option 114 for IPv4, DHCPv6 option 103, or option 37 in an IPv6 Router Advertisement. It replaced the earlier RFC 7710.
RFC 8908, published the same month, defines the API itself. The device queries it over HTTPS and gets back a short JSON document with the media type application/captive+json. Its one required field, captive, says whether the device still has to sign in. Optional fields give the address of the sign-in page (user-portal-url), a page about the venue (venue-info-url), the seconds and bytes left in the session, and whether the session can be extended. RFC 8952, from November 2020, sets out the architecture the other two fit into.
Apple added support for the DHCP and Router Advertisement options in iOS 14 and macOS Big Sur, and its developer post How to modernize your captive network asks companies that build captive networks to "start supporting the latest standards". Android 11 reads DHCP option 114 and the venue-info-url field. Android's documentation also says the old method stays in place: if the API is missing or no portal is advertised, the system "will continue to detect portals and verify internet connectivity using HTTP/HTTPS probes, as before."
For a venue, interception-based portals keep working on every current phone and laptop, and most controllers in the field still depend on them. Where a controller supports option 114, switching it on gives supported devices a sign-in that does not rely on intercepted traffic, and lets the network send session status to the device.
What a captive portal can ask guests for
The portal decides what a guest has to do before getting online. Each method costs the guest a little effort in return for something the venue learns or controls, and the choice usually follows the venue's reason for running a portal.
| Sign-in method | What the guest does | What the venue gets | Typical users |
|---|---|---|---|
| Click-through | Taps to accept the terms | Accepted terms, no contact details | Transport, councils, hospitals |
| Email form | Types a name and email, and ticks a separate marketing box if they want offers | A contact with a consent record | Restaurants, pubs, cafes, shops |
| Phone number | Types a mobile number | A number for text messages, with consent recorded | Venues that market by SMS |
| Voucher code | Types a code from a receipt or table card | WiFi for paying customers only | Cafes, hotels |
| Paid pass | Picks a pass and pays by card or phone wallet | Revenue, plus the buyer's name and email | Hotels, holiday parks, coworking |
| Social login | Signs in with an existing Google, Apple or Facebook account | Whatever profile fields the provider shares | Some hospitality and retail |
| Account login | Types a username and password, or a room number and surname | Access tied to a known account or booking | Hotels, universities, offices |
On CaptiFi, guests sign in with an email address or a phone number on your branded form, and you can add a date of birth with a minimum age or a question of your own. WiFi vouchers and paid passes are separate access modes you switch on per venue, and returning devices are recognised and let straight through. The comparison of guest WiFi login options weighs each method in more detail, and the guide to what to show after WiFi login covers the screen guests see once they are online.
Why venues run a captive portal
The oldest reason is the terms. A portal makes every user accept the venue's acceptable use policy before going online, and gives the venue a record that they did. It also controls access: the venue sets how long a session lasts, can limit the WiFi to paying customers with vouchers, and can keep guest traffic away from the staff network and the tills.
For hospitality and retail, the larger reason is knowing who came in. Without a portal, free WiFi is an anonymous cost. With one, every sign-in can add a named guest to a list the venue owns, with their marketing consent recorded against them. Across CaptiFi venues, 40 to 60% of connections typically opt in, and a single venue collects 400-1,200 new guest contacts a month, depending on setup and footfall.
On CaptiFi's Growth plan and above, the list drives the follow-up: a welcome email after the first visit, a review request the day after, and a win-back offer when a regular has not been in for a while, without staff having to remember any of it. The complete guide to WiFi marketing covers what venues do with the list. Hotels, holiday parks and coworking spaces can also sell faster or longer access through paid WiFi.
Captive portal or WiFi password?
A shared WiFi password keeps strangers off the network and tells the venue nothing about who joined. A captive portal on an open network tells the venue who joined and leaves the radio link unencrypted. Venues can combine the two, and newer encryption closes most of the gap.
| Setup | How guests connect | Radio link encrypted? | What the venue learns |
|---|---|---|---|
| Shared password (WPA2 or WPA3 Personal) | Type a password from a sign or a member of staff | Yes | Nothing about who joined |
| Open network with a captive portal | Join, then complete the sign-in page | No, though HTTPS sites stay encrypted end to end | Whatever the page asks for |
| Enhanced Open (OWE) with a captive portal | Join with no password, then complete the page | Yes, per device | Whatever the page asks for |
| Passpoint (Hotspot 2.0) | The phone joins by itself using a stored profile | Yes | The account the profile belongs to, with no page |
A portal can run on a password-protected network, but a password the guest has to ask for adds a step. The bigger leak is a second network: when staff hand out the password to a network that has no portal, those guests never see it. Most venues run an open or Enhanced Open guest network with a portal, and a separate password-protected network for staff and the till. The portal works above the encryption layer, so moving the guest network to WPA3 or Enhanced Open does not break it. The guide to WPA3 and Enhanced Open for guest WiFi covers the 6 GHz rules that make the move necessary on newer access points, and the guide comparing a captive portal with a WiFi password covers security.
Is WiFi with a captive portal safe?
The portal itself is an ordinary web page, so its safety depends on the network underneath and on what the page asks for. On an open network, traffic between the phone and the access point is not encrypted. Most websites and apps now use HTTPS, which stays encrypted end to end whatever the WiFi, and Enhanced Open encrypts the radio link as well.
The main risk for guests is a fake hotspot: someone nearby broadcasts a network with the venue's name and a lookalike sign-in page to collect passwords or card numbers. A venue's portal should never ask a guest to type the password for their email account into the page itself; where social sign-in is offered, it happens on the provider's own page. For the venue, the safeguards are client isolation on the guest network, so guests cannot reach each other's devices, a separate network for staff and payments, and a portal served over HTTPS.
Captive portals and data protection law
A portal that collects names, email addresses or phone numbers collects personal data, so data protection law applies. In the UK and the EU that means the GDPR (the UK GDPR in the UK) alongside the rules on electronic marketing, which in the UK are PECR. The ICO's guidance on when consent is appropriate uses a cafe that makes marketing consent a condition of its free WiFi as its example of consent that is not valid.
In practice the portal should give WiFi access on one decision and marketing on another. That means a clear privacy notice, a marketing box that is not pre-ticked and is not required to get online, a record of when each guest agreed, and an unsubscribe link in every message. Other countries set their own rules for marketing email and texts, including CAN-SPAM in the United States, CASL in Canada, the Spam Act 2003 in Australia and the Unsolicited Electronic Messages Act 2007 in New Zealand, so a group with venues in several countries should check each one; the guide to guest WiFi marketing laws by country sets them side by side. This is general information, not legal advice.
The guest WiFi GDPR compliance checklist goes through the UK rules point by point. CaptiFi's GDPR tools keep a time-stamped consent record for every guest, apply opt-outs at once and include deletion tools for erasure requests.
A built-in portal or a captive portal platform?
Most business WiFi systems include a basic portal. UniFi's hotspot portal can show a terms page, a voucher box or a password field. Cisco Meraki offers a click-through splash page and a sign-on page backed by RADIUS or a directory. Aruba Instant On's guest page carries a logo, a few colours and a tick-box for the terms. DrayTek's Hotspot Web Portal supports click-through, social login, SMS PIN and RADIUS, and MikroTik RouterOS ships its own hotspot. On the open source side, pfSense has a captive portal that takes a username and password, a voucher code or a click-through agreement, and openNDS is a captive portal for OpenWrt routers.
These portals control access well. None of them, as shipped, builds a marketing list with consent records or sends anything after the visit. A captive portal platform fills that gap. The controller still runs the network and decides who is online; its external portal setting sends guests to a page the platform hosts, and the platform authorises each guest back through the controller once they have signed in.
| Capability | Built-in controller portal | Captive portal platform (CaptiFi) |
|---|---|---|
| Sign-in page | A basic template on the controller | A branded page from a visual builder, one per venue if you like |
| Guest contact list | Not kept for marketing | Every sign-in added, exportable as CSV |
| Marketing consent | Not recorded | Recorded per guest with a timestamp |
| Follow-up emails and review requests | None | Automated after each visit, on Growth and above |
| Several venues | Configured per controller | Every venue under one login, even on different hardware, with combined figures on Pro |
| Cost | Included with the hardware | A monthly subscription, from $69/mo on Essentials |
For a venue that only needs guests to accept terms, the built-in portal is enough. The comparison of free captive portal software and paid platforms looks at where each one stops and what it costs to run.
How to set up a captive portal on your WiFi
With CaptiFi, a venue goes from a plain guest network to a branded portal in five steps. The exact settings for each brand are in the hardware guides linked after the list.
- Choose your route. CaptiFi runs as an external captive portal on ten hardware ecosystems: UniFi, TP-Link Omada, Cisco Meraki, Cisco Catalyst 9800, Aruba, MikroTik, Ruckus, Fortinet, Cambium and DrayTek. If your network has none of these, the included plug-and-play CaptiFi device (refundable deposit) plugs into your existing network by Ethernet and, once you enter its activation PIN, has a guest network live in about five minutes from start to finish, with no controller, static IP or firewall change.
- Point the controller at CaptiFi. Set the guest network's portal to external, enter the portal address from your my.captifi.io dashboard and add the walled garden entries for your hardware. On UniFi most of this is done for you: create an API key, connect the controller from the dashboard and CaptiFi writes the hotspot portal settings itself.
- Design the splash page. Paste your website address into Auto-brand to pull in your logo, colours and fonts, choose the fields you want, and leave marketing consent on: CaptiFi asks for it separately from getting online, with nothing chosen in advance.
- Test from real phones. Forget the network on an iPhone and an Android phone, switch off mobile data, rejoin and complete the page on each.
- Check the result. Open Guest Visits on my.captifi.io; if your test guest is listed, the portal is live.
The setup guides cover UniFi, TP-Link Omada, Cisco Meraki, Aruba Instant On, Ruckus, FortiGate, DrayTek and MikroTik. The hardware page lists every supported system. Plans start from $69/mo, shown in your currency on the pricing page, and every plan comes with a 30-day free trial.
Sources: IETF RFC 8910, RFC 8908 and RFC 8952 (September and November 2020); Apple Developer, How to modernize your captive network (22 June 2020); Android Developers, Captive portal API support; Microsoft Learn, Network Connectivity Status Indicator FAQ; Mozilla Support, Captive portal detection, and the Firefox 155 release notes; the Android NetworkStack default probe addresses; the ICO's guidance on when consent is appropriate; and CaptiFi's hardware setup pages and platform figures, October 2026. UniFi, Omada, Meraki, Aruba, Ruckus, FortiGate, DrayTek, MikroTik, pfSense and the other product names here are trade marks of their owners; CaptiFi is not affiliated with or endorsed by them.
Frequently asked questions
Quick answers to the most common questions about this topic.
What is a captive portal in simple terms?
How does a captive portal work?
Why does the WiFi login page not pop up?
What is the difference between a captive portal and a splash page?
Is a captive portal the same as a WiFi hotspot?
Does a captive portal slow down WiFi?
Is it safe to use WiFi with a captive portal?
Can a venue collect email addresses through a captive portal legally?
Do I need new hardware to run a captive portal?
The CaptiFi Editorial Team writes about guest WiFi marketing, captive portals, GDPR-compliant data capture, and local SEO for venue operators. We base our recommendations on real customer outcomes and verified third-party reviews from G2.com.
Ready to turn your guest WiFi into a marketing engine?
CaptiFi captures customer data from every WiFi login, automates Google reviews and email follow-ups, and plugs into the tools you already use. Hardware included (refundable deposit), transparent pricing, 30-day free trial.