Incognito mode prevents cookies and local storage from persisting, but hardware-bound and most engine-bound browser signals are still readable. A well-constructed fingerprint survives private browsing on every major desktop browser, with one notable caveat on iOS.
The direct answer
Yes. Device fingerprints work in incognito mode on Chrome, Firefox, Safari on macOS, and Brave. The `hardwareFingerprint` produced by `getFingerprint` will match between a user's normal session and their incognito session on the same device. The per-browser `fingerprint` will also match in most cases, with some minor drift in specific browsers.
The rest of this post explains why, covers the one meaningful platform exception, and explains what `result.incognito.incognitoLikelihood` is and how it should (and should not) be used.
What incognito actually changes
Incognito mode (also called Private Browsing in Firefox and Safari, or Guest Mode in some contexts) is a storage isolation feature. When you open an incognito tab, the browser creates a temporary storage partition: cookies, localStorage, IndexedDB, and sessionStorage are all either blocked or written to a temporary store that is deleted when the tab closes.
What incognito does not change is how the browser reads hardware and environment properties. The GPU is still the same GPU. The CPU architecture is still the same architecture. The installed fonts are still the same fonts. The timezone, the screen resolution, and the platform string are all unchanged. These hardware-bound properties are readable from JavaScript APIs regardless of storage state.
Engine-bound signals, those that measure how the browser processes content, are also generally unaffected. The audio DSP produces the same floating-point output in an incognito tab as in a normal tab. The canvas rasteriser draws the same pixels. WebGL produces the same GPU output. The browser engine itself has not changed.
What changes in incognito vs what does not
| Changes in incognito | Does not change in incognito |
|---|---|
| Cookies (blocked or temporary) | Installed fonts |
| localStorage and sessionStorage (blocked or temporary) | GPU model and rendering output |
| IndexedDB (blocked or temporary) | CPU architecture |
| Browsing history (not written) | Canvas and audio processing output |
| Download history (not written) | Timezone and locale |
| Cached HTTP responses (separate partition) | Screen resolution and DPR |
| Some browser extensions may be disabled | Hardware-bound signal set |
Why the hardware fingerprint survives
The `hardwareFingerprint` is derived exclusively from hardware-bound signals. Because hardware-bound signals are unaffected by the storage isolation that defines incognito mode, the resulting hash is identical in both normal and incognito sessions on the same device.
This is the core reason hardware-bound fingerprinting is effective as a trial-gate or anti-fraud layer: the identifiers you care about for fraud prevention (is this the same physical device?) are precisely the ones that incognito mode does not clear.
The per-browser `fingerprint`, which includes engine-bound signals, will also match in most incognito sessions. The slight exception is that some browsers apply minor adjustments to certain properties in private mode (for example, some platform strings and storage-quota-adjacent values differ slightly). These adjustments are minor enough that `compareFingerprints` with the `lenient` or `cross-browser` mode will still produce a match.
The iOS and Safari private-mode caveat
There is one platform where incognito mode has a meaningful effect on fingerprint stability: iOS Safari in Private Browsing mode.
On iOS, WebKit applies tighter restrictions in Private Browsing mode that limit or alter several storage-adjacent and timing-sensitive APIs. Some signals that are available in a normal session may return reduced-fidelity values or be blocked entirely in private mode. The practical result is that the `hardwareFingerprint` may still match, but the full `fingerprint` and the `crossBrowser.stableSignals` count may be lower in iOS Safari private mode than in a normal session.
This does not mean fingerprinting fails on iOS in incognito: the hardware-bound signals that drive `hardwareFingerprint` remain accessible. It means the confidence score (available in `getDeviceId` as the `confidence` field) may be lower, and you should account for that when calibrating match thresholds on iOS.
import { getFingerprint } from 'doorman-benny';
const result = await getFingerprint();
// incognitoLikelihood: 'low' | 'medium' | 'high'
// This is informational context, not a fraud signal.
console.log(result.incognito.incognitoLikelihood);
// The hardware fingerprint is stable regardless of incognito state.
console.log(result.hardwareFingerprint);
// crossBrowser.stableSignals tells you how many hardware signals
// contributed to the hardwareFingerprint on this collection pass.
// A low count in iOS Safari private mode is expected and not an error.
console.log(result.crossBrowser.stableSignals);
console.log(result.crossBrowser.unstableSignals);Read incognitoLikelihood for context, but do not use it as a fraud gate. A user in private mode is not necessarily an abuser.
A quick test you can run
To confirm the fingerprint survives incognito on your own device, collect a fingerprint in a normal session, store the `hardwareFingerprint` value, then open an incognito tab and collect again. Pass both results to `compareFingerprints` with the `cross-browser` mode. You should see `hardwareMatch: true` and a high `matchScore`.
On iOS Safari in private mode, check `result.crossBrowser.stableSignals`. If the count is lower than in the normal session, the iOS private-mode restrictions are applying, and you may want to lower your match threshold for sessions where a high incognitoLikelihood coincides with a lower stable-signal count on a mobile Safari user agent.
import { getFingerprint, compareFingerprints } from 'doorman-benny';
// Collect once in a normal session and save the result to your backend.
const normalResult = await getFingerprint();
// Later, collect in an incognito session and compare.
const incognitoResult = await getFingerprint();
const comparison = compareFingerprints(
normalResult,
incognitoResult,
{ mode: 'cross-browser' }
);
console.log(comparison.hardwareMatch); // Should be true on the same device
console.log(comparison.matchScore); // Expect high on desktop; may be lower on iOS Safari private mode
console.log(incognitoResult.incognito.incognitoLikelihood); // 'medium' or 'high' in private modeUse cross-browser mode when comparing across incognito boundaries. It restricts the comparison to hardware-bound signals and is not affected by engine-bound differences between normal and private-mode sessions.
Frequently asked questions
Does the fingerprint change every time an incognito window is opened?
No. The fingerprint is derived from browser APIs, not from a stored identifier. Each call to getFingerprint runs fresh collection, and the result will be essentially the same across normal and incognito sessions on the same device. There is no session-scoped randomness in the hardware-bound signals.
Does Brave's fingerprinting protection break the hardware fingerprint?
Brave Shields applies per-site canvas and audio farbling in both normal and private-window mode. This may cause the per-browser fingerprint to shift slightly between sites. The consistency scoring automatically detects and accounts for Brave farbling patterns, so the hardwareFingerprint remains stable, and real Brave users with no other spoofing evidence do not read as spoofers. The scoring-consistency docs cover the Brave-aware suppression in detail.
Can a user defeat the fingerprint by using Firefox with resistFingerprinting enabled?
Firefox's resistFingerprinting mode suppresses or randomizes several signals. The consistency scoring will detect the resistFingerprinting signature and report it in the flags list. The hardwareFingerprint may be less stable with resistFingerprinting active because some hardware-adjacent signals are affected. The consistency.spoofLikelihood score will reflect the unusual signal pattern.
Is incognito detection the same as fingerprint collection?
No. They are independent pipeline stages. Fingerprint collection (getFingerprint) runs all configured signal collectors. Incognito detection is a separate check that looks for patterns in storage and quota APIs that are characteristic of private-browsing mode. A high incognitoLikelihood does not change the fingerprint or hardwareFingerprint values.
Should I block users who are in incognito mode?
No. Incognito mode is a standard browser feature used by a large proportion of ordinary users for legitimate privacy reasons. Blocking or restricting based on incognitoLikelihood alone will create a high false-positive rate and degrade the experience for legitimate users. Use it as context alongside other signals, not as a standalone gate.
Get started
See how fingerprinting behaves in private mode
Try the live demo on the landing page in an incognito tab and compare the hardwareFingerprint with your normal session. Or read the getting-started guide and integrate in under five minutes.
Last reviewed June 9, 2026
