Why Incognito Mode Does Not Protect Against Fingerprinting

Private browsing, which Chrome calls Incognito and Edge calls InPrivate, is often described as a way to browse without being tracked. The feature is narrower than that. A private window keeps the browser from storing local history, cookies, site data and form entries once the session ends. It does not change the IP address that a site sees, and it does not change the signals the browser exposes about its hardware and software while a page is open. Chrome's own help page says that Incognito does not make you invisible, and that the websites you visit and the organizations that manage your network may still observe your activity.

The sections below separate the local effects of private mode from the effects that happen on the site side. They cover the storage and API differences that private mode can add, the reason core fingerprint signals stay the same, a practical comparison between a regular and a private session that use the same profile, and isolation choices that work without private mode. They also state what BotBrowser covers and what it leaves to you.

What a private window changes and what it leaves alone

A private window starts with an empty, temporary session. It does not load the cookies, local storage or signed-in state of the regular profile, and when the last private window closes the browser discards what the session created. That is useful on a shared computer, when checking how a public page behaves without an existing site session, or when finishing a one-time task that should not enter the normal history. Downloads and bookmarks are not part of that cleanup, and neither is anything a service has already recorded on its own servers.

Chrome's help page adds detail about what changes inside a private window. Chrome does not retain site data or a record of the sites you visited after the session ends, third-party cookies are blocked by default, and you are not signed in to accounts automatically. Bookmarks you save and files you download stay on the device. All of these are local effects. They describe what the browser keeps on your machine, not what a website or a network can observe while you are connected.

The limits matter as much as the benefit. The IP address that reaches a site is decided by the network and not by the browser mode, so a private window uses the same connection as any other window on that machine. Employers, schools and internet providers that manage a network can still see the traffic that crosses it. A site you sign in to still knows who you are. And the browser still reports its normal user agent, screen size, fonts, graphics behavior and audio behavior to every page it loads, because those values describe the device and the browser build, not the session.

• Local history, cookies, site data and form entries are removed when the private session ends.
• The IP address, the network route and what the managers of that network can observe stay the same.
• A signed-in account stays known to the service for as long as you remain signed in.
• Fingerprint signals describe the device and the browser build, so they stay the same.

People sometimes read "private" as "unlinkable". Those are different properties. Unlinkable would mean that a site cannot connect two visits. A private window only means that the second visit does not carry the cookies of the first. If the same device shows the same fingerprint in both visits, a site that collects those signals can still connect them without any cookie. The article on private browsing in everyday use describes the everyday side of this boundary, and the article on what browser fingerprinting is explains the signals themselves.

Storage and API differences a site could observe

Because a private session keeps its data in temporary storage, browsers sometimes behave a little differently inside it. MDN's guide to storage quotas and eviction criteria notes that in private browsing mode, which Chrome calls Incognito and Edge calls InPrivate, browsers may apply different quotas, and stored data is usually deleted when the mode ends. A page can read the quota and the current usage for its origin through navigator.storage.estimate(). The same MDN page cautions that this method returns an estimate and not an exact figure, and that browsers may pad the size of cross-origin data when they report total usage.

Quota is the most discussed difference, but it is not the only one. Over the years browsers have changed how some storage related interfaces respond in private mode. Examples include older file system interfaces, how requests for persistent storage are answered, how service workers register and whether they survive, and how IndexedDB behaves when it cannot write to disk. These details differ by browser and by version, and a behavior that existed in one release can be gone in the next. Treat any such difference as something that may exist, not as a rule that holds everywhere.

Each browser also makes its own choices about quota even outside private mode. MDN lists different limits for Firefox, Chrome and Safari, expressed as different shares of total disk space, and notes that the numbers depend on how the storage is used. That spread is part of the reason a single quota value is a weak signal. A small value can come from a private session, from a nearly full disk, from an embedded web view or from a browser that simply sets a lower limit.

Why does this matter for privacy? A difference that is visible to a page is a signal. If a script reads a smaller quota than the same browser normally reports, it may guess that the session is private. That guess is not a strong identifier and not a reliable test, because quota depends on free disk space, on the browser version and on how the profile is set up, so ordinary sessions also report a wide range of values. Even so, a feature that people use to look less distinctive should not add a visible difference of its own.

Two cautions keep this in proportion. First, a private-mode difference does not identify a person. At most it places the session in the group of private sessions, which is a smaller group than all sessions. Second, sites have many legitimate reasons to read storage figures, such as deciding how much data to keep for offline use, so reading them is normal behavior and not evidence of tracking. The article on storage quota fingerprinting goes further into how those numbers are used and how stable they are.

Why fingerprint signals stay the same in private mode

A browser fingerprint is a combination of values that describe the device and the browser build. These include how the graphics stack draws shapes and text, how the audio stack processes a test signal, which fonts are installed, the screen dimensions and pixel ratio, the number of logical processors, the platform string and the language list. None of these lives in the profile folder that private mode replaces. They come from the hardware, the operating system and the browser release, and they are the same whether the window is private or not.

This is why a regular visit and a private visit from the same machine can be linked. Suppose someone browses a shop in a normal window, then opens a private window and returns to the same shop to avoid the recommendations that cookies would trigger. The cookies are gone. The fingerprint is not. A site that records fingerprint values for fraud prevention or analytics sees two visits with matching values and can reasonably treat them as one device.

A fingerprint is useful to a site because it is stable. A value that changed on every page load would be worthless for recognition, so the signals a site favors are the ones that stay put across sessions, restarts and mode changes. That stability is exactly what makes private mode ineffective against them. Clearing cookies resets state that the site stored in the browser. It does not reset anything the browser reports about itself.

Extensions that claim to restore privacy inside private windows have a similar limit. A tool that alters a few values in page scripts has to keep every other answer consistent with the altered ones, and the changes can be a visible oddity in themselves. A fingerprint that disagrees with itself is often more distinctive than an ordinary one. This is a reason to think about the browser environment as a whole and not as a list of independent values.

The conclusion for private mode is simple. It handles one class of recognition, the kind that depends on stored state such as cookies. It does not handle recognition that depends on what the device and the browser report. When a task needs control over the second class, a private window is the wrong tool, and a deliberately chosen, internally consistent profile is the right one.

Compare a regular and a private session step by step

When the goal is to learn whether two sessions look the same to a page, a written comparison beats guesswork. The steps below assume one browser build and one profile, so the only variable is the session mode. Use a page you control, or a public fingerprint viewer that you trust, and keep the same page for both runs.

1. Record the baseline. Write down the browser version, the operating system, the profile file name and the launch flags. A comparison is only meaningful when these are identical in both runs.
2. Open the regular session and read the storage quota and usage that navigator.storage.estimate() reports. Note whether persistent storage is granted.
3. Open a private session with the same profile and read the same values from the same page. The values should match, allowing for usage changes caused by data written during the run. This match is expected with a BotBrowser profile; an unmodified browser may report different quotas in private mode.
4. Compare API availability for service workers, IndexedDB, local storage and the Cache API. In both sessions each interface should be present and should answer a simple test write in the same way.
5. Compare the fingerprint values that your viewer reports, such as the graphics renderer, the audio result, the font list, the screen values and the language list. Any difference between the sessions should be explained by the mode and not by a changed profile or flag.
6. Repeat after a restart. Close every window, start again with the same profile and run the same comparison. Results that change from run to run point to a configuration problem and not to a stable property.

Read the results by category. If the quota differs but the fingerprint values match, the difference comes from the storage layer. If fingerprint values differ, check that both sessions use the same profile and the same flags before looking further. If service workers register in one session and not in the other, record the browser version, because a behavior that is normal in an unmodified browser can still show up as a difference in the comparison. Keep the notes next to the profile name so that the next browser update can be compared against them.

Keep the test conditions steady. Use the same window size, the same extensions or none at all, and a similar amount of free disk space, because each of these can move a value for reasons unrelated to the mode. Quota and usage figures are estimates, so compare them in a way that tolerates small changes and treat a large, repeatable gap between the two sessions as the finding worth investigating.

Keep the limits of this check in mind. It compares one session with another. It does not tell you how any particular site scores a visit, and a clean result does not guarantee that a site accepts the session. A site may also use signals that this check does not cover, including the IP address, account history and behavior over time. Treat a match as evidence that private mode added no extra difference, and nothing more.

Choose isolation that does not depend on private mode

If the real need is for sessions that do not share or keep data, a user data directory does that job directly. Chromium based browsers store cookies, local storage, IndexedDB and caches in the directory given by --user-data-dir. Pointing each session at its own directory keeps those sessions apart, and a fresh temporary directory leaves nothing behind once it is removed. That gives the same local non-persistence that private mode gives, with no mode specific differences to compare.

# one session with its own temporary data directory
chromium-browser --bot-profile="path/to/profile.enc" \
                 --user-data-dir="$(mktemp -d)"

Choose by purpose. A separate directory per account keeps cookies, sign-in state and local data apart, which is what multi-account work needs. A temporary directory suits a one-off task that should leave nothing on disk. A persistent directory suits a session that must survive restarts. The article on multi-account browser isolation describes how to plan those boundaries. In every case the directory only decides what is stored. It does not decide what the fingerprint looks like, so the profile is still chosen separately.

Remove temporary directories when the task ends. A script that creates one should also delete it, and a person who creates one by hand should not reuse it for another task. Reusing a directory defeats the point, because the cookies and site data from the first task would then be available to the second one.

Network identity is a different layer again. Neither a private window nor a data directory changes the IP address. A site that sees the same address across sessions can connect them regardless of storage. If separate network identity matters for your task, configure a proxy for that session on purpose and check that its location, language and time zone agree with the profile. Cookies, fingerprint and IP address are three separate surfaces, and each one needs its own decision.

Do not treat any of these choices as anonymity. A temporary directory removes local files. A proxy changes the visible address. A profile keeps the values the browser reports consistent. Together they reduce how much of a session is carried from one visit to the next, but a signed-in account is still known to the service, and a site can still use signals that a local comparison does not cover.

What BotBrowser covers and what stays outside it

BotBrowser can keep fingerprint surfaces, storage quota values and storage API behavior consistent between regular and incognito sessions for the same profile, and the BotBrowser incognito documentation describes this behavior. For the comparison above, that means a private context should show no extra storage or API differences compared with a regular one, so a mismatch is a reason to check the profile and the flags and not something you have to accept. BotBrowser cannot make private browsing hide the IP address or site-side activity, cannot control how a site scores or correlates other signals, and does not replace proxy configuration or account choices.

The documentation also describes --bot-enable-variations-in-context, an option for the X-Client-Data header that Google domains receive in incognito contexts. It is listed as an ENT Tier2 feature and is disabled by default. Most readers do not need it for the comparison in this article, but it shows that the consistency work extends to details beyond storage.

For a practical start, launch BotBrowser with a profile, run the comparison from the previous section, and expect the regular and the private context to agree. If they do not, the documentation's troubleshooting guidance applies: confirm that both sessions use the same --bot-profile and the same --bot-* flags, because a different profile can define different quota values. Session isolation stays your decision, and the data directory options described above are the way to make it.

Keep the role of the product narrow. It addresses consistency between regular and private contexts. Whether a site accepts a session depends on the site, on the network identity and on the history of the account, and none of that is something a browser mode or a profile can promise. Use the comparison as one check in a wider review of your setup, alongside the network and account choices that stay with you.

Public sources

• BotBrowser docs: Incognito mode fingerprint consistency
• MDN: Storage quotas and eviction criteria
• MDN: StorageManager.estimate()
• Google Chrome Help: How Incognito mode works