Chrome Incognito Leaves Windows DNS Cache: Check With ipconfig

Chrome Incognito Limits What Stays on the PC, and Google Says So Plainly​

Google's Chrome Help page for Incognito is clear about what the mode is for. Opening an Incognito window starts a separate browsing session, and that session ends only when you close all Incognito windows. If one Incognito window is still open, even a forgotten one behind other apps, the session is still running. While it runs, Chrome keeps cookies and site data temporarily so websites work normally. It removes that information when the session ends.

Google gives two examples of where Incognito helps: a shared computer, and shopping for a gift. Both are about other people using the same device. Google's page states that Incognito "doesn't make you invisible." It also names who can still see your activity: the websites you visit (Google sites included) and any organisation that runs your network, such as a school, employer or internet provider.

Some things also survive the session by design. Chrome keeps bookmarks and reading-list items you save in Incognito, and they show up in your normal browsing sessions. Files you download stay on disk until you delete them. Google's enterprise documentation says the same: bookmarks created in Incognito remain after the session ends, browsing history is not saved, and closed Incognito tabs can't be reopened.

The MakeUseOf piece summarises Incognito as clearing "history, cookies, form data, the local cache." Google's current wording is narrower. Chrome doesn't retain site data or a record of the sites you visited after the session. Stick to Google's wording. It describes Chrome's own profile data, not every trace a browsing session can leave on a Windows PC.

The ipconfig /displaydns Test Shows Where Chrome's Reach Ends​

The most useful part of the MakeUseOf explainer is a demonstration any Windows user can repeat. Browse normally in an Incognito window, close all Incognito windows, then open Command Prompt and run ipconfig /displaydns. The output may include domain names that were looked up while you were browsing, including during the Incognito session.

Here's why. Microsoft's documentation for ipconfig, which covers Windows 10, Windows 11 and Windows Server 2016 through 2025, says /displaydns shows the contents of the DNS client resolver cache. That cache holds entries preloaded from the local Hosts file plus recently obtained records for name lookups the computer has done. The Windows DNS Client service uses it to answer repeated lookups quickly without asking the configured DNS servers again. The cache belongs to Windows, not Chrome, so closing Incognito windows doesn't clear it.

MakeUseOf is explicit that this is not a Chrome bug or deception. It shows how narrow Incognito's scope is. Incognito controls data stored inside the browser. It has no control over a cache the operating system keeps for every program on the machine.

Be careful about how you read the output. It is not a browsing history. Any program's lookups can end up there: other browser windows, background services, update agents, and entries from the Hosts file. A domain in the list doesn't prove it came from an Incognito tab. A domain missing from the list doesn't prove nobody saw the connection, because entries expire and the network sees lookups whether or not your PC caches them. What the test does show, cleanly, is that Windows keeps its own record of name lookups, separate from anything Chrome deletes.

Running the check on Windows 10 or Windows 11​

1. Open Chrome, press Ctrl+Shift+N to open an Incognito window, and visit a few sites.
2. Close every Incognito window. If a number appears next to the Incognito icon at the top right, more than one Incognito window is open.
3. Open Command Prompt and run ipconfig /displaydns.
4. Scroll through the output and look for hostnames from sites you just visited, keeping in mind that other software adds entries too.
5. To empty the cache, run ipconfig /flushdns. Microsoft documents this as flushing and resetting the DNS client resolver cache.

Microsoft describes /flushdns as a DNS troubleshooting tool, used for things like clearing out stale "not found" entries. It is safe to run, and Windows simply rebuilds the cache as lookups happen. Flushing is not a privacy fix, though. It clears one local cache on one PC and does nothing to what your DNS provider, router or network operator has already seen.

The original piece also says crash-recovery files can stay on disk briefly if the browser crashes mid-session, and that routers can hold the same DNS lookups. Neither point is backed by the Google or Microsoft documentation used here. Treat both as plausible but unverified, not as documented behaviour.

Brown v. Google Put a Legal Price on the Incognito Misunderstanding​

The misunderstanding described above led to a major lawsuit. Brown v. Google was a class action filed in 2020 over data collected while people used Chrome Incognito and other private-browsing modes. The plaintiffs said Google collected identifiable browsing data, including sites visited, IP addresses and device details, through Google services and integrations running on the websites they visited.

The case ended in a settlement, not a court ruling. In the settlement agreement filed in court, Google committed to revising its Privacy Policy to clarify that using Incognito or another private mode does not prevent data collection when you visit third-party websites that use Google services. Google estimated that the remediation would affect billions of event records. The Associated Press reported that the deal required Google to delete billions of records and make its disclosures more prominent. AP also noted that the large dollar valuations in circulation were plaintiffs' lawyers' estimates, not cash payments to consumers.

The case was not about cookies left on anyone's computer. Incognito's local cleanup works as described. The issue was the data a website, or a service embedded in it, receives while you browse. Google's current Help page now says so directly: sites that use Google services share information about your activity on their sites with Google, including for advertising purposes.

Settlements don't establish liability, and this one doesn't show that all Incognito browsing was recorded. What it shows is that Incognito's privacy stops at your own device, and Google's own disclosures now say that. The settlement's main visible legacy is how directly Google's help page now spells out the limits.

Networks, Employers and ISPs Sit Outside Incognito Completely​

Incognito is a browser-side setting. Your router, your ISP, your office network and a coffee shop's Wi-Fi handle your traffic the same way whether the tab is private or not. Google's own wording lists schools, employers and internet providers as parties that may be able to see your Incognito activity.

MakeUseOf adds a technical detail. Even over HTTPS, the domain you connect to is sent unencrypted during the connection handshake in a field called Server Name Indication (SNI). Unless a protection called Encrypted Client Hello is in use, someone watching the network may be able to see which hostname you connected to, even though they can't read the page contents. The piece also says IT departments on managed work laptops or school Chromebooks may install a root certificate that lets them decrypt and inspect traffic. Both points are well-known networking behaviour, but neither comes from Google's Incognito documentation. Either way, the practical conclusion is the one Google states itself: the network sees your Incognito traffic.

Chrome has a separate feature that deals with part of this. Google describes Secure DNS, which uses DNS-over-HTTPS, as encrypting the DNS lookup step so attackers can't easily watch which sites you look up or redirect you to phishing sites. It is a separate setting that has nothing to do with Incognito, and it doesn't hide activity from the site you visit, from software on a managed device, or from the connection itself.

For a while it looked like Incognito itself would gain network protection. Google designed IP Protection to limit availability of a user's original IP address in third party contexts in Incognito mode. The scope was narrow. It applied to domains on the list when they appear in a third-party context (for example if the domain is embedded within another website), while if that domain is accessed in a first-party context it will receive the original unmasked IP address. Google had said the feature would launch to Chrome Stable no sooner than July 2025.

That plan has since been dropped. According to BrowserInsight, on October 17, 2025, Google announced it would retire IP Protection entirely, grouping it with Attribution Reporting, Protected Audience, On-Device Personalization, Related Website Sets, and Topics. MakeUseOf reports the same retirement. For practical purposes, Incognito does nothing to hide your IP address from the sites you visit, and you shouldn't expect it to.

Extensions, Third-Party Cookies and Sign-Ins Decide How Private an Incognito Window Really Is​

Within its narrow job, Incognito does have two real defaults that reduce cross-site tracking. First, Chrome blocks third-party cookies by default in Incognito. Those are the cookies set by embedded domains that ad and analytics networks commonly use to follow people from site to site. You can weaken this yourself: Google's help page explains how to allow third-party cookies temporarily for a specific site that breaks without them.

Second, extensions don't run in Incognito automatically. Google's enterprise documentation says each extension has to be enabled for Incognito individually. That cuts both ways. An extension you have allowed in Incognito keeps whatever access its permissions grant, so a private window is only as private as the extensions you've let into it. Go to chrome://extensions, open an extension's details, and check whether "Allow in Incognito" is switched on.

Your own actions matter most. Chrome won't sign you in to your Google Account or other websites automatically in Incognito, and you can't sign in to Chrome itself there. You can still sign in to Google web services and any other site. Once you do, that site can link your activity to your account. Google's Help page adds that sites may be able to gather information about you even when you're not signed in.

MakeUseOf's author says this is why they stopped treating Incognito as a way to become someone else to the sites they visit. That's the right conclusion. Incognito starts you with no cookies. Logging in puts your identity back on the session.

What IT Admins Can Enforce With the IncognitoModeAvailability Policy​

For Windows administrators, the question is how Chrome behaves on managed devices. Google exposes Incognito through the IncognitoModeAvailability policy. A value of 0 makes Incognito available, 1 disables it, and 2 forces users to browse only in Incognito windows. If the policy is left unset, users can open Incognito windows. On Windows, admins set it with Group Policy under Administrative Templates > Google > Google Chrome, using the "Incognito mode availability" setting. It can also be set from the Google Admin console for enrolled browsers.

Google also documents two other options that are often better choices on shared machines. Guest mode lets people browse without signing in and without touching existing Chrome profiles, and session data isn't written to disk. Ephemeral mode, set with ForceEphemeralProfiles, lets users sign in and sync, then deletes all local data when they sign out or close the browser. Ephemeral mode is only available when policy forces it.

Users need to restart Chrome before policy changes take effect. To check that a policy applied, go to chrome://policy, click Reload policies, tick "Show policies with no value set," and confirm the policy shows a Status of OK with the value you expected. None of these modes changes what the network or visited sites can see. They only control what Chrome keeps on the device between users.

What this means for you​

Use Incognito for the job it does well, keeping a session out of Chrome's local history and cookie store, and use something else when your concern is the network, the websites you visit, or your employer. If you share a Windows PC and want a gift search or one-off login to leave no trace in Chrome's history, Incognito is fine. Close every Incognito window when you're done, and remember that downloads and bookmarks stay. If you're worried about your ISP, your workplace network or advertisers, Incognito doesn't address that, and IP Protection is no longer coming to help. On a work laptop, assume IT can see what you do, private window or not.

• Incognito ends only when all Incognito windows are closed, and only then does Chrome drop that session's cookies, site data and history.
• Windows keeps its own DNS resolver cache that Incognito can't clear. ipconfig /displaydns shows it, ipconfig /flushdns resets it, and neither changes what the network has already seen.
• Signing in to any site in an Incognito window lets that site link your activity to your account.
• Check chrome://extensions for extensions set to "Allow in Incognito," because those keep their access in private windows.
• Third-party cookies are blocked by default in Incognito, but a temporary per-site exception you grant removes that protection for that site.
• Administrators can disable, allow or force Incognito through the IncognitoModeAvailability policy, and can use Guest or Ephemeral mode for shared devices.

Incognito's "private" is local, and Google's own documentation now says so more directly than the feature's name suggests, partly because of the Brown v. Google settlement. Google has retired IP Protection, the one planned change that would have taken Incognito beyond the device. For now, Incognito protects you from the next person who uses your PC. Hiding from the network, the sites you visit or your employer takes other tools, such as Secure DNS, careful choices about signing in, and managed-device policy.