Private Mode Detection Test

A private or incognito window is a session with amnesia. It starts with no cookies and no stored site data, keeps everything it does in memory, and throws the lot away when the last private window closes. That is a useful property and it is genuinely all the mode promises.

It is not a disguise. Your IP address is unchanged, so the network still sees the same connection. Your device is unchanged, so a browser fingerprint computes to exactly the same value as it does in a normal window. What changes is only what has been written to disk, and only for the length of the session.

Three techniques were once reliable, and all three are age-checked above rather than merely reported.

• Storage quota. Chromium normally grants an origin a large share of the free disk. A private window gets a much smaller fixed cap, so a script reading navigator.storage.estimate() could compare the two. The raw number is still readable — it is just no longer conclusive, because a nearly full disk produces a small figure as well.
• A refused local storage write. Safari in private mode used to throw a QuotaExceededError on the first write. The test performs that write and reports whether it threw, which on any current browser it will not.
• The old webkit quota call. navigator.webkitTemporaryStorage.queryUsageAndQuota exposed a granted figure on early Chromium and Safari builds. Most browsers have removed it, so its absence is itself the answer.

The right-hand rows grade each one for this browser, so you can see which are still live and which are history.

Each of these was closed deliberately, and the pattern is the same: the browser had been leaking an implementation detail that happened to correlate with private browsing, and it normalised the two modes so they behave alike.

Quotas were made consistent so that a private window would not report a conspicuously small number. Safari made private storage writable and simply discard it on close, which removed the exception that gave it away. The legacy quota API was retired as part of the same tidy-up. This is the normal shape of browser privacy work: remove the observable difference rather than ask sites to ignore it.

The useful consequence is that the modes are now close to indistinguishable from script. The awkward consequence is that people often overestimate what a private window protects against, because the feature’s name suggests more than the mechanism delivers. The permissions test shows a related area where a private session does still start from a clean slate.

Even without a direct signal, behaviour gives things away. A private window arrives with no cookies, so a site that recognised you yesterday sees a stranger today. That pattern — a known device, a completely fresh session — is itself a weak hint, and the same trick works for anyone who simply clears cookies rather than using private mode.

Anything a site already knew from your address is also unaffected. Your IP can still place you in a city, and if you signed in, the account ties the session to you regardless of which window it is in. Private mode protects the local trace, not the connection.

So the correct reading of the verdict above is narrow. “No signal” means these particular checks read as normal, not that the site believes you are in a normal window. It has other ways to guess, and it can be wrong in both directions.

Yes, in the ways that matter for a shared or borrowed computer. Nothing you do lands in history, in autofill or in the site-data store, so closing the window removes the session and leaves nothing for the next person to find. That is a real benefit and it is worth using for it.

It is not a defence against being identified. The device fingerprint is identical in both modes, so a tracker that recognises you by your hardware recognises you in private mode just as easily. If the goal is to be less identifiable rather than merely to leave no trace, take a look at the fingerprint test and the privacy signals test to see which parts a private window does not change.