2026-08-16 · Dan Clark

How to Disable Incognito Mode (Every Browser, 2026)

Read This Before You Change Anything

Most parents come to this question in a moment of quiet panic. You found an incognito window open. Or you checked the browser history and there was a suspicious gap - two hours of the laptop being on, and nothing recorded. The natural conclusion is that your child has found a way to browse invisibly and that everything you set up has been defeated.

That conclusion is almost certainly wrong, and it's worth fixing before you touch a single setting.

Incognito mode does not hide browsing from network-level or system-level filtering. It stops the browser writing history, cookies and form data to the local disk on that device. That is essentially the whole feature. It does not encrypt anything extra, it does not anonymise the connection, and it does not make requests invisible to anything outside the browser process.

So if you run a DNS filter, a router-level filter, or a system-level parental control that inspects requests at the OS layer, that layer sees an incognito request exactly the same way it sees a normal one. A blocked site stays blocked. A logged request stays logged. Google itself says as much on the incognito splash screen - the text about your activity still being visible to your school, employer or internet service provider is doing a lot of quiet work that most people skim past.

This matters for two practical reasons:

You are probably less exposed than you fear. If you already have filtering at the system or network level, incognito changed nothing about what your child could reach.
Disabling incognito is a visibility fix, not a safety fix. It restores your ability to review history on that browser. It does not add any blocking you didn't already have.

Plenty of articles on this topic imply that turning off incognito closes a security hole. It doesn't. It closes a record-keeping hole. Both are worth having, but confusing them leads parents to do the fiddly registry work, feel finished, and skip the thing that would actually have protected their child.

With that framing in place, here's how to do it properly on each browser - and then the structural approach that makes browser-by-browser work far less important.

What Incognito Actually Does and Doesn't Do

Incognito does	Incognito does not
Skip writing pages to local browsing history	Hide traffic from a DNS or system-level filter
Discard cookies and site data when the window closes	Hide traffic from your router or ISP
Discard form entries and search box autofill	Hide traffic from a school or work network
Start the session logged out of most sites	Hide traffic from monitoring software running on the device
Usually disable extensions by default	Prevent downloads being saved to disk
	Prevent bookmarks created during the session persisting

Two details parents often miss. First, downloads survive. Files downloaded in an incognito window sit in the Downloads folder like anything else - the download list is cleared, the files aren't. Second, extensions are usually disabled in incognito unless explicitly allowed, which is why browser-extension-based parental controls fail in private windows while system-level tools don't. If your current control is an extension, incognito genuinely is a hole in it, and that's the real reason this query gets asked so often.

Before You Edit Anything: The Safety Rules

Two of the methods below involve editing the Windows registry or writing system-level configuration files. These are legitimate, vendor-documented mechanisms, but a mistyped path in the registry can cause real problems.

Back up first. In Registry Editor, select the key you're about to change, choose File > Export, and save a .reg file somewhere you'll find it. Double-clicking that file restores what you exported.
Create a system restore point on Windows before your first registry edit if you've never done one before.
Only edit the exact keys named here. If a walkthrough anywhere tells you to delete a key you don't recognise, stop.
Do this from a parent account. All of these methods require administrator rights, which is the point - a child on a standard account can't undo them.

If you're not comfortable with the registry, skip to the structural section. A non-administrator child account plus system-level filtering gets you most of the benefit with none of the risk.

Chrome on Windows

Chrome exposes an enterprise policy called IncognitoModeAvailability. It's the officially documented method and it's the one every reliable guide uses.

Steps:

Press Windows + R, type regedit, press Enter, and approve the admin prompt.
Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Policies.
Look for a Google key, and inside it a Chrome key. On most home machines neither exists yet. To create them: right-click Policies > New > Key > name it Google. Then right-click Google > New > Key > name it Chrome.
Select the Chrome key. Right-click in the empty right-hand pane > New > DWORD (32-bit) Value.
Name it exactly IncognitoModeAvailability (capitalisation matters).
Double-click it and set the value data to 1.
Close Registry Editor and fully restart Chrome - all windows, and check the system tray for a background Chrome process.

The values are: 0 = incognito available (default), 1 = incognito disabled, 2 = forces every window to be incognito. Never set 2 by accident; it does the opposite of what you want and wipes history on every close.

How to verify it worked: open Chrome and press Ctrl+Shift+N. Nothing should happen. The "New Incognito window" item should also be gone from the three-dot menu. You can double-check the policy has registered by visiting chrome://policy - the policy name should be listed with a status of OK.

Confidence note: the key path and the IncognitoModeAvailability name are stable and long-documented by Google in its Chrome Enterprise policy list. The HKEY_CURRENT_USER equivalent of the same path also works but only for the currently logged-in Windows user, so HKEY_LOCAL_MACHINE is the better choice for a family machine.

Chrome on Mac

Same policy, different delivery. macOS reads Chrome policies from a preferences domain rather than a registry.

Open Terminal (Applications > Utilities) and run:

sudo defaults write /Library/Preferences/com.google.Chrome IncognitoModeAvailability -integer 1

Enter your admin password when prompted, then quit and reopen Chrome. Verify at chrome://policy exactly as on Windows.

To reverse it:

sudo defaults delete /Library/Preferences/com.google.Chrome IncognitoModeAvailability

Confidence note: the domain com.google.Chrome and the policy name are the ones Google documents for macOS. Google's own recommended approach for managed Macs is to deploy a configuration profile (.mobileconfig) containing the same key, and on recent macOS versions a profile is the more durable option because it isn't affected by preference caching. If the defaults write route doesn't take effect after a full restart of Chrome, that's the reason - check Chrome's Mac policy documentation for the profile template rather than experimenting with other domain names.

Microsoft Edge

Edge is Chromium underneath, and its equivalent policy is InPrivateModeAvailability.

Windows:

Open regedit as administrator.
Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge, creating the Microsoft and/or Edge keys if they don't exist (same right-click > New > Key process as above).
Create a DWORD (32-bit) Value named InPrivateModeAvailability.
Set it to 1.
Restart Edge completely.

Values follow Chrome's pattern: 0 = available, 1 = disabled, 2 = forced InPrivate.

Verify at edge://policy. Ctrl+Shift+N should stop opening an InPrivate window, and the menu entry should disappear.

Mac: the same policy applies through the com.microsoft.Edge preferences domain:

sudo defaults write /Library/Preferences/com.microsoft.Edge InPrivateModeAvailability -integer 1

Confidence note: the InPrivateModeAvailability policy name and its values are documented by Microsoft in the Edge browser policy reference, and the Windows registry path follows the standard SOFTWARE\Policies\Microsoft\Edge location that all Edge policies use. As with Chrome, Microsoft's preferred macOS method is a configuration profile.

Firefox

Firefox doesn't use the registry by default. It reads a JSON policy file, which is genuinely the easiest method on this page - no registry editor, no Terminal.

Create a file named policies.json containing exactly this:

{
  "policies": {
    "DisablePrivateBrowsing": true
  }
}

Save it to:

Windows: C:\Program Files\Mozilla Firefox\distribution\policies.json (create the distribution folder if it isn't there; you'll need admin rights to write into Program Files)
Mac: /Applications/Firefox.app/Contents/Resources/distribution/policies.json - right-click Firefox in Applications, choose Show Package Contents, then navigate to Contents > Resources and create a distribution folder

Restart Firefox. Ctrl+Shift+P (Cmd+Shift+P on Mac) should do nothing, and "New private window" should be gone from the menu. Verify by visiting about:policies - the active policy will be listed there.

While you're in that file, "BlockAboutConfig": true is a sensible companion policy, because about:config is where a curious child would otherwise go poking.

Confidence note: DisablePrivateBrowsing and the distribution/policies.json locations are documented in Mozilla's official policy templates repository. Firefox also supports the same policies via HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Mozilla\Firefox on Windows, but the JSON file is simpler and less risky, so use it.

Safari on Mac

Safari has no policy switch for private browsing that a home user can reasonably set. What it has is a side effect worth knowing about: turning on Screen Time's web content restrictions removes Private Browsing from Safari entirely.

Open System Settings > Screen Time.
If you manage your child through Family Sharing, select their name from the dropdown at the top first. This is the single most common mistake - editing your own settings instead of theirs.
Go to Content & Privacy and turn it on.
Under Content Restrictions (older macOS: Web Content), set access to Limit Adult Websites.
Set a Screen Time passcode that your child doesn't know, otherwise this takes about four seconds to undo.

With that active, Safari's File menu no longer offers a New Private Window, and the shortcut does nothing. It's a slightly odd coupling on Apple's part, but it's reliable and it's the accepted method.

Note that this also applies Apple's own content filtering, which is a real filter but a blocklist one - it catches obvious adult sites and misses a great deal else. Treat it as a bonus, not as your filtering strategy.

Chromebook

On a Chromebook signed in with a supervised child account through Family Link, incognito mode is not available - Google disables it for supervised users rather than exposing it as a parent-facing toggle. If you're seeing incognito on a Chromebook, the most likely explanation is that the child is signed in with an ordinary Google account rather than a supervised one, or is using the guest session. Fix the account type and disable guest browsing (see below) rather than hunting for a setting that isn't there.

Comparison of Methods

Browser / method	Covers	Difficulty	Can a determined kid undo it?	Survives browser updates?
Chrome - Windows registry policy	Chrome only	Medium	Only with admin rights	Yes
Chrome - Mac `defaults write`	Chrome only	Medium	Only with admin rights	Usually; profile is more durable
Edge - registry / defaults policy	Edge only	Medium	Only with admin rights	Yes
Firefox - `policies.json`	Firefox only	Easy	Only with write access to the app folder	Usually, but re-check after major updates
Safari - Screen Time restriction	Safari only	Easy	Only with the Screen Time passcode	Yes
Non-admin child account	All browsers	Easy	No, without your password	Yes
System-level filtering	All browsers, incl. new ones	Easy	No, if tamper-protected	Yes

The pattern in that table is the entire argument of this article. Every per-browser row covers exactly one browser. The last two rows cover all of them, including the browser your child hasn't installed yet.

Why Browser-by-Browser Is Whack-a-Mole

Suppose you do all five sections above perfectly. Chrome, Edge, Firefox and Safari are locked down. Here's what your child can do in the next ten minutes, without any specialist knowledge:

Download Brave, Opera, Vivaldi or any of a dozen other browsers and use its private window, which your policies say nothing about.
Run a portable browser from a USB stick or their Downloads folder - a self-contained executable that installs nothing and inherits none of your policies.
Open a guest session on Chrome, Windows or a Chromebook, which is private by design.
Create or log into another OS user account where your per-user settings don't apply.
Boot the machine from a live USB into a completely separate operating system.

None of these are exotic. They're the top results for the obvious search query. As the table shows, per-browser policies are a fence with a defined perimeter, and the perimeter has a gate marked "install a different browser".

That doesn't make the work useless - the browser your child actually uses every day is worth locking down, and it removes the easy option. But it should be the last thing you do, not the first.

The Two Controls That Actually Hold

1. Make the child's account a standard, non-administrator account.

This is the highest-leverage change on this page and it takes two minutes. A standard user can't install software, can't create new user accounts, can't edit HKEY_LOCAL_MACHINE, and can't uninstall your parental control. That single change kills the "install another browser" bypass, the "new user account" bypass and the "uninstall it" bypass simultaneously. On Windows: Settings > Accounts > Other users, select the account, Change account type, set to Standard User. On Mac: System Settings > Users & Groups, and make sure "Allow this user to administer this computer" is off. Then make sure your own admin password isn't something they've watched you type.

2. Filter at the system level, not in the browser.

A control that operates below the browser - at the OS or network request layer - doesn't care which browser made the request, or whether the window was private. A portable browser on a USB stick still has to make requests through the operating system. This is why the misconception at the top of this article is so consequential: once your filtering lives at the system level, incognito stops being a threat model at all.

3Eyes was built around this specific point. It enforces at the system level on Windows and Mac rather than as a browser extension, and it's allowlist-first - only sites you've approved resolve, which means a newly installed browser or a private window has nothing new to reach. Parents manage it from the iOS app.

How Kids Get Around It, and the Fix for Each

Bypass	Why it works	The fix
Installs a second browser	Your policy named one browser	Standard (non-admin) account blocks installs
Portable browser from USB or Downloads	Runs without installing; no policies apply	System-level filtering; on Windows, AppLocker or SmartScreen policies for unsigned executables
Guest session or guest profile	Guest mode is private by design	Disable guest browsing: Chrome's `BrowserGuestModeEnabled` policy set to 0; on Windows and Chromebook, turn off guest sign-in in settings
Another OS user account	Per-user settings don't follow them	Only admins can create accounts - so remove admin rights; apply policies at machine level (`HKEY_LOCAL_MACHINE`) not per user
Live USB / booting another OS	Bypasses the installed OS entirely	Set a BIOS/UEFI password and disable USB boot in firmware settings
Phone hotspot instead of home WiFi	Router-level filtering never sees it	Device-level filtering that travels with the laptop
Reinstalling or resetting the browser	Wipes the app folder, and with it `policies.json`	Re-check Firefox after major updates; prefer registry/managed policy where available

Note the repetition in the right-hand column. Nearly every fix reduces to the same two things: no admin rights, and filtering that doesn't live inside a browser.

Should You Tell Your Child?

There's a real argument on both sides here and anyone who tells you it's obvious is selling something.

The case for telling them. They will find out. The moment Ctrl+Shift+N stops working, a curious kid investigates, and discovering it silently frames you as someone who does things to their devices behind their back. That's a worse outcome than the conversation you avoided. Being upfront also lets you explain the reasoning - "I want to be able to see what you're looking at, the same way I'd want to know where you're going after school" - which is a defensible position that most children can at least argue with honestly. And it opens the door to the far more useful conversation about why they wanted a private window, which is often something more ordinary and more addressable than you're imagining.

The case for not announcing it. If you have concrete, current concern about something specific and serious - contact from an adult, self-harm content, a situation where a child might hide evidence if warned - then a short period of quiet observation before you act is a defensible parental judgement. The important word is short. Indefinite covert surveillance of your own child is corrosive to a relationship in a way that's hard to repair, and the older the child, the more true that becomes.

The middle path most families land on: be transparent about the existence of controls and about what you can see, without narrating every technical change. "There are filters on this laptop and I can see the sites you visit" is honest, sets accurate expectations, and doesn't require you to hold a seminar about registry keys.

One thing that is not balanced: if your child is a teenager and the only thing you've done is disable incognito, you've bought yourself a false sense of security. The controls work best as a floor for younger kids and as a conversation-starter for older ones - never as a substitute for knowing what your kid is doing.

FAQ

Does incognito hide browsing from my WiFi router or ISP? No. Incognito only affects what the browser stores on the device. Your router, your ISP, a DNS filter and any system-level monitoring all see the same requests they'd see in a normal window.

Can I see what was browsed in incognito after the fact? Not from the browser - that's the whole point of the mode, and the history genuinely isn't written. You may find traces elsewhere: downloaded files remain in the Downloads folder, and any filtering or monitoring tool that logs at the network or system level will have its own record. If you had no such tool running, that browsing isn't recoverable.

Why did my registry change do nothing? Three usual causes. Chrome or Edge wasn't fully closed - check for a background process in the system tray. The value was created as a String instead of a DWORD. Or there's a typo in the value name, which must match exactly including capitalisation. Check chrome://policy or edge://policy to see whether the browser actually picked the policy up.

Will a Windows or browser update undo this? Registry-based policies survive browser updates. Firefox's policies.json lives inside the application folder, so a major update or reinstall can remove it - worth re-checking a couple of times a year.

My child is on a school-managed laptop. Can I do this? Usually not. Managed devices already have policies applied by the school's administrator, and those take precedence over anything you set locally. Ask the school's IT contact what's enforced; many will add restrictions on request.

Does disabling incognito block anything? No. It only stops the browser hiding its own history. If a site was reachable before, it's still reachable. Blocking requires a filter.

Is there a downside to disabling it? Minor ones. Private windows are genuinely useful for logging into a second account or testing something logged-out. On a shared family computer that occasionally matters. It's rarely a reason not to do it on a child's account.

What about VPNs? A VPN is a different and much bigger problem than incognito, because it does hide traffic from network-level filtering. The fix is the same as everything else here: a non-admin account stops the VPN app being installed in the first place.

Is this the same as parental control software? No, and it's the confusion worth ending on. Disabling incognito restores your ability to review history in one browser. It adds no blocking, no time limits and no visibility into other browsers. It's one small piece of a setup, not the setup.

Locking down incognito in the browser your child uses is worth twenty minutes. Just do it in the right order: standard account first, system-level filtering second, per-browser policies third. If you want the middle piece handled properly across Windows and Mac, 3Eyes does exactly that - see pricing and the 14-day free trial.