How to Detect Incognito and Private Browsing

Private browsing tells a browser to forget the session when it closes: no persistent history, cookies, or local storage that survives. For most users it is an ordinary privacy choice. For fraud teams it is a meaningful signal, because incognito is disproportionately common in workflows that depend on looking like a fresh visitor every time, such as multi-accounting and promo abuse.

Detecting private browsing has always been a cat-and-mouse game. Browsers introduce private modes, researchers find behavioral differences that expose them, and browsers patch those differences. This guide explains the mechanisms that have worked, why they keep breaking, and how to fold an incognito signal into a fraud decision without over-trusting it or punishing legitimate privacy-conscious users.

Why incognito is a useful signal

An incognito session is not suspicious by itself. Plenty of people use it to check a flight price or log into a shared computer. Its value is contextual: it is over-represented in abuse patterns where the goal is to appear new.

• Multi-accounting relies on discarding state between accounts, and private mode does exactly that; see multi-accounting detection.
• Promo and bonus abuse wants each claim to look like a first-time visitor, a pattern covered in promo abuse prevention.
• Metered-content evasion resets free-article and trial counters by clearing state each session.

The signal earns its weight only in combination. An incognito session that also reuses a device fingerprint across many accounts is far more interesting than either fact alone, which is why incognito detection lives inside a broader device fingerprinting pipeline rather than standing alone.

How detection has worked

Historically, private modes differed from normal ones in observable ways, and detection exploited those differences. The classic techniques cluster into a few families.

• Storage-quota differences. Some browsers reduced the storage quota in private mode, so a script that queried the estimated quota could infer the mode from an unusually low number.
• API availability. Certain storage or filesystem APIs behaved differently or threw errors in private windows.
• Filesystem quirks. In older Chrome, the temporary filesystem API was disabled in incognito, so a failed request revealed the mode.

// Illustrative quota-based heuristic (browser-dependent, patched over time)
async function likelyPrivate() {
  if (!navigator.storage || !navigator.storage.estimate) return null;
  const { quota } = await navigator.storage.estimate();
  // A surprisingly small quota historically implied private mode.
  return quota !== undefined && quota < 120 * 1024 * 1024;
}

The threshold and the very existence of the difference vary by browser and version, which is exactly the problem addressed next.

Why these methods keep breaking

Every published detection method invites a fix. Browser vendors treat reliable incognito detection as a privacy leak, because it can be used to pressure users out of private mode, so they actively close the gaps. Chrome removed the filesystem tell and normalized storage quotas; Safari and Firefox have their own histories of patching behavioral differences.

The practical consequences:

• Version fragility. A method that works today can silently fail after a browser update, returning false negatives.
• False positives. Some legitimate configurations mimic private-mode behavior, flagging normal users.
• Cross-browser divergence. Chrome, Safari, and Firefox implement private mode differently, so one technique rarely covers all three.

This is why an incognito verdict must be probabilistic. Treating it as a hard boolean bakes in the assumption that the detection is perfect, which it never is. The realistic posture matches the one in detecting antidetect browsers: observe behavior, assign a confidence, and expect the ground to shift.

Using the signal responsibly

An incognito signal is an input, not a verdict. The failure mode is blocking or degrading service for anyone in private mode, which harms ordinary privacy-conscious users and misses that the mode alone proves nothing.

Guidelines that keep it useful and fair:

Do	Do not
Feed incognito into a weighted score	Block solely because a session is private
Combine with device reuse and velocity	Treat the verdict as certain
Re-test methods as browsers update	Ship a one-time detection and forget it
Disclose signal collection in your policy	Use it to coerce users out of private mode

Incognito is most powerful next to a stable device ID. Private mode clears storage, but it does not change the canvas, WebGL, and audio characteristics that make up a fingerprint, so you can still recognize the same device across incognito sessions. That combination, incognito plus fingerprint reuse, is what turns a weak individual signal into strong evidence, feeding a suspect score with clear reason codes.

Where it fits in a fraud stack

In practice, incognito detection is one Smart Signal among many, and it does its best work at the moments where fresh-visitor spoofing pays off.

• At signup, incognito plus a device already tied to existing accounts flags likely multi-accounting.
• At promo claim, incognito plus rotating IPs points to organized bonus abuse.
• At login, incognito on an otherwise trusted device is unremarkable and should not raise friction on its own.

The context around the signal, not the signal itself, drives the decision. Handled that way, incognito detection adds real lift without becoming a blunt instrument against privacy. You can see the signal alongside device continuity in the playground, and the glossary defines the related Smart Signals.

Frequently asked questions

Is detecting incognito mode reliable?

It is reliable enough to use as one signal, but the specific detection methods change as browsers patch them. Treat an incognito verdict as a probabilistic input to a score, not a hard fact, because false positives and negatives both occur.

Is it legal to detect private browsing?

Detecting that a session is private is generally permissible because it observes browser behavior rather than reading personal data, but you should disclose signal collection in your privacy policy and avoid using it to defeat a user’s clear privacy intent.

Incognito detection is a genuinely useful signal wrapped in a moving target. The methods break, the browsers patch, and no single technique holds across versions, so the only durable strategy is to treat the verdict as probabilistic and let context decide. Combine it with device continuity, weight it inside a score, and it earns its place without turning private browsing into a reason to punish honest users.