Chrome Kiosk Mode: Set It Up on Windows and ChromeOS, Exit It and Lock a Fleet

Updated: November 2026

Chrome kiosk mode turns a PC or Chromebook into a single-purpose screen, and the hard part isn't starting it, it's keeping people out of everything behind it. A --kiosk flag hides the browser chrome in ten seconds, and Alt+F4 undoes it in one. This guide covers the Windows and ChromeOS setups that hold, how to get back out for maintenance, and how to lock the same config across a fleet.

TL;DR

• The definition. Chrome kiosk mode runs one web page full screen, with no address bar, tabs or desktop.
• The flag. chrome.exe --kiosk <url> hides the browser, but it doesn't lock Windows.
• The Windows lock. Assigned Access locks the session, Chrome policies lock the browser.
• The ChromeOS lock. A web kiosk app set to auto-launch from the Google Admin console.
• The deadline. Chrome app kiosks lost stable support in July 2026, so move to web apps.

What Chrome Kiosk Mode Does (and Doesn't)

Chrome kiosk mode is a launch mode. Start Chrome with --kiosk and it opens one page full screen, with no tabs, address bar or window controls. That's it. Windows still runs underneath, keyboard shortcuts still work, and closing the window drops the user onto a desktop.

So a real kiosk is three locks stacked on top of each other. The launch flag controls the window. Chrome policies control what the browser will do: which sites load, whether downloads, DevTools or sign-in work. The operating system controls the session: which apps run, whether there's a desktop to fall back to, and what happens on reboot.

Skip a layer and the kiosk leaks. A flag with no session lock is a lobby PC with a very short path to File Explorer. A session lock with no browser policy is a full-screen browser that still opens any website a curious visitor types into a search box on the page.

If the device is an iPad or you're comparing platforms, our iPad kiosk mode guide covers Guided Access and Single App Mode. This one stays on Chrome, Windows and ChromeOS.

Chrome Kiosk Mode on Windows With the --kiosk Flag

The quick version is a shortcut. Create one that points at Chrome and add the flags after the closing quote:

code
"C:\Program Files\Google\Chrome\Application\chrome.exe" --kiosk https://checkin.example.com --no-first-run --kiosk-printing

--kiosk opens the URL full screen. --no-first-run skips the welcome screens. --kiosk-printing skips the print preview dialog and prints straight to the default printer, which is what a receipt or badge kiosk wants. On a touchscreen, add --disable-pinch and --overscroll-history-navigation=0 so a pinch doesn't zoom the page and a swipe doesn't go back.

Two catches trip people on day one. First, Chrome must be fully closed before the shortcut runs. If any Chrome process is alive, the new window joins it and ignores the flag. A dedicated --user-data-dir=C:\Kiosk\ChromeProfile gives the kiosk its own process and its own profile. Second, --app=<url> isn't kiosk mode. It opens a borderless window that the user can still resize, minimize and close.

To make it start on boot, drop the shortcut into shell:common startup and set the kiosk account to sign in automatically. That's fine for a lobby screen nobody touches. It is not a lock. Alt+F4 closes Chrome and leaves a desktop, so anything facing the public needs the next section.

Lock the Session With Assigned Access or Shell Launcher

Assigned Access is the built-in Windows kiosk. It runs on Pro, Enterprise, Education and IoT Enterprise editions, per Microsoft Learn (updated October 2026). Home isn't on the list. It also needs UAC switched on and a console sign-in, because the kiosk experience doesn't run over Remote Desktop.

It comes in two shapes, and Chrome fits both through the configuration XML rather than the Settings app.

Single-app kiosk. A KioskModeApp profile runs one app full screen above the lock screen and restarts it if it closes. Microsoft's docs describe it as a UWP app or Edge, but the Windows 11 schema takes a desktop app path through v4:ClassicAppPath. Microsoft's own example points that at Edge with --kiosk. Pointing it at Chrome looks like this:

xml
<Profile Id="{9A2A490F-10F6-4764-974A-43B19E722C23}">
  <KioskModeApp v4:ClassicAppPath="%ProgramFiles%\Google\Chrome\Application\chrome.exe"
    v4:ClassicAppArguments="--kiosk https://checkin.example.com --no-first-run" />
  <v4:BreakoutSequence Key="Ctrl+Alt+K"/>
</Profile>

Microsoft documents Edge here, not Chrome, so pilot Chrome on one machine before rolling it out. The profile can only be assigned to a user, not a group.

Restricted user experience. An AllAppList profile gives a locked desktop with a short list of allowed apps, enforced with AppLocker rules. Add Chrome as a DesktopAppPath, set rs5:AutoLaunch="true", and pass --kiosk <url> in rs5:AutoLaunchArguments. This shape works for groups and for kiosks that need a second app, like a PDF viewer.

You can apply the XML with Intune, a provisioning package from Windows Configuration Designer, or PowerShell through the MDM bridge, run as SYSTEM:

powershell
$xml = Get-Content C:\Kiosk\assigned-access.xml -Raw
$obj = Get-CimInstance -Namespace "root\cimv2\mdm\dmmap" -ClassName "MDM_AssignedAccess"
$obj.Configuration = [System.Net.WebUtility]::HtmlEncode($xml)
Set-CimInstance -CimInstance $obj

The walkthrough below builds and tests an Assigned Access XML on a Windows 11 workgroup machine, which is the quickest way to see the moving parts before you push anything.

Shell Launcher is the heavier option. It replaces Explorer with your app, so there's no desktop at all. It needs Enterprise, Education or IoT Enterprise, and it can't be combined with a KioskModeApp profile on the same device. Use it when the kiosk app isn't a browser, or when Chrome must survive things Assigned Access doesn't allow.

ChromeOS Managed Kiosk

On a Chromebook, Chromebox or ChromeOS Flex device, kiosk mode is a device setting, not a flag. The device has to be enrolled in your Google Admin console with a license that covers kiosk use. Then:

1. Go to Devices, Chrome, Apps & extensions, Kiosks, and pick the organizational unit that holds the kiosk devices.
2. Add the app by URL as a web kiosk app, or add the Isolated Web App your signage vendor ships.
3. Set it as the auto-launch app. You can deploy several kiosk apps, but only one auto-launches.
4. Under device settings, set a scheduled reboot and the update policy, then re-enroll or reboot a test device.

The deadline to know about: Google is retiring Chrome apps. Admin-installed Chrome app kiosks were switched off by default in ChromeOS 138 (July 2025). The last stable release that supports them was ChromeOS 150 in July 2026, and the long-term support channel runs to April 2027, per Google's end of support page. Signage players from ScreenCloud and Signagelive have moved to Isolated Web Apps for this reason. If a client's lobby screen still runs a packaged Chrome app, it's on borrowed time.

Google also warns that web permissions can be granted in a kiosk session without asking the user. Only add web apps the client fully trusts.

How to Exit Chrome Kiosk Mode

Plan the way out before you lock anything. Every maintenance job, from a Wi-Fi change to a new URL, starts with getting out.

The ChromeOS shortcut is controlled by a device policy that Chromium's policy list calls "Enable bailout keyboard shortcut for auto-login". If it's off, the console is the only exit, which is the point on a public device.

To remove a Windows kiosk for good, clear the Assigned Access configuration (Settings, Accounts, Other users, Kiosk, or an empty Configuration value through the same MDM bridge), then delete the kiosk account.

Lock Chrome Kiosk Mode Across a Fleet

One kiosk is a project. Forty kiosks across six client sites is configuration management. The browser lock is the part to standardize first, because it's the same on every Windows box regardless of how the session is locked.

Chrome reads policy from HKLM\SOFTWARE\Policies\Google\Chrome, from the Chrome ADMX templates in Group Policy, or from Intune's imported ADMX settings. Scope it to the kiosk devices only, because it applies to every Chrome user on the machine.

Here's the allowlist part as a script you can push:

powershell
$base = "HKLM:\SOFTWARE\Policies\Google\Chrome"
New-Item "$base\URLBlocklist" -Force | Out-Null
New-Item "$base\URLAllowlist" -Force | Out-Null
Set-ItemProperty "$base\URLBlocklist" -Name 1 -Value "*"
Set-ItemProperty "$base\URLAllowlist" -Name 1 -Value "https://checkin.example.com"
Set-ItemProperty $base -Name IncognitoModeAvailability -Value 2 -Type DWord
Set-ItemProperty $base -Name DeveloperToolsAvailability -Value 2 -Type DWord
Set-ItemProperty $base -Name DownloadRestrictions -Value 3 -Type DWord

Check it on the device at chrome://policy. Every policy should show as applied with no errors.

Then audit, because kiosks drift. A tech exits for maintenance and forgets to re-lock, a Windows feature update resets a setting, a client swaps a PC without telling anyone. A scheduled script that reads the Chrome policy keys and the MDM_AssignedAccess configuration on every kiosk turns "is it still locked?" into a report. OpenFrame can run that kind of script across a client's devices and collect the output in one job, and the same audit works next to whatever MDM you already run.

Common Chrome Kiosk Breakages

These are the tickets that come back.

The flag is ignored. Chrome was already running, often from a background app or an update task. Use a dedicated --user-data-dir, or set BackgroundModeEnabled to false.

"Restore pages?" after a power cut. Chrome noticed it didn't shut down cleanly. Forced incognito, from the policy table above, means there's no session to restore.

The screen sleeps or locks. The kiosk is fine, the power plan isn't. Set the display timeout to never for the kiosk account; our screen timeout guide has the policy and command versions.

Autologon stops working. Microsoft's docs list two causes: Exchange ActiveSync password rules block the AutoLogonAccount, and accounts hit by conditional access that needs MFA can't sign into a kiosk profile. Moving to Entra-only devices surfaces both. In this r/Intune thread, an admin moving 100+ kiosks to cloud-only during a Windows 11 upgrade hit exactly that wall and fell back to a local account created during Autopilot.

Updates never land. Chrome updates in the background but only applies the new version on relaunch, and a kiosk never relaunches. Schedule a nightly reboot outside opening hours, on Windows and ChromeOS alike.

A Chrome app kiosk shows an error after an OS update. That's the Chrome apps retirement above. Rebuild it as a web kiosk app.

Where to Start

Pick the session lock by the device: Assigned Access for Windows Pro, Shell Launcher for Enterprise boxes that need no desktop, and the Admin console for ChromeOS. Add the Chrome policies on every Windows kiosk, write down the exit before anyone needs it, and schedule the reboot. Then audit monthly, because a kiosk that drifted open looks exactly like one that didn't.

Running iPads next to the Chrome screens? The iPad kiosk mode guide picks up there.