Incognito tab feature testing, the version that admits where it lies.

What private mode actually does, line by line

Browsers describe private mode in marketing-friendly language ("your activity won't be saved") that hides the engineering. The accurate version is more useful for testing: a private window opens a separate session-scoped storage partition. Cookies, Web Storage, IndexedDB writes, and HTTP cache entries created in that window live in that partition. When the last private window in the session closes, the partition is destroyed.

Two consequences fall out of that model. First, opening a second private window from the same browser does not give you a second clean partition; it joins the existing private session and shares storage with the first window. If you want two truly independent fresh visitors at the same time, you need two different browsers, two different profiles, or two different machines. Second, a long-lived private session that you forget to close accumulates cookies and storage just like a regular session would; only the close-window event resets it. People who leave incognito open for a day and assume each new tab is fresh are testing wrong.

The honest mental model is "a temporary parallel browser instance", not "a clean room every time you open a tab".

What a private window clears, and what it leaves on the floor

Two columns. Left, things you can rely on private mode to wipe between sessions. Right, things people assume it wipes that it does not. The right column is where every flaky test lives.

The right column is the part competing guides skip. Most flaky "but it worked in incognito" bug reports trace back to one of those rows: an extension that was on, a fingerprint-based cohort that stuck, a server-side flag the user's account still carries, or a download that was not actually fresh. Read the column before you trust the test.

The four-step recipe

One discipline that catches most mistakes: do not skip the verify step. People open private mode, click around, see the right thing, and ship. The right thing is sometimes the cached thing the regular session remembered, served from the browser's shared HSTS list or DNS cache. Verify on the network panel before you call it done.

Total wall-clock for one pass: about 90 seconds. The slowest part is reading the network panel for the request you actually care about. If you find yourself running the recipe more than three times in a session, save the URL plus the prereqs in a sticky note; you are testing the same flow repeatedly and a Playwright script will pay for itself within an hour.

The shortcuts, every browser

Worth committing to muscle memory if you are testing across browsers regularly. Two shortcut families cover everything: Chromium-derived browsers use Cmd/Ctrl+Shift+N, and Mozilla-derived plus Safari use Cmd/Ctrl+Shift+P. The notes are the small differences that sometimes matter.

Two practical notes. Brave's Tor private window is not the same as a regular private window; it actually does change your IP path through the Tor network and is slow but useful for geo-tests. Firefox's Total Cookie Protection isolates first-party data per top-level site, which makes some cross-site flows behave differently in Firefox private mode than in Chrome incognito; if you see a discrepancy across browsers, that is usually the cause.

What happens when you open mk0r in a private window

As a worked example: mk0r persists a session identity by writing a UUID to localStorage under the key mk0r_session_key on first page load. The logic lives in src/app/(landing)/page.tsx around line 32, in a function called getSessionKey. Open the regular tab and the function reads the existing key. Open in incognito and the function gets null, generates a new UUID with crypto.randomUUID(), writes it back, and the rest of the page treats this browser as a brand-new visitor. A fresh sandbox is claimed via the prewarm endpoint, and a session_started event fires in PostHog with the new key.

Two seconds, no signup, no logout, no profile switch. The whole point is that the private window naturally produces the empty-storage state that page.tsx is designed to handle, so the first-time visitor branch of the code is exercised verbatim. If you are iterating on a generated app inside mk0r and you store anything in localStorage yourself (a user's draft, a tutorial-completion flag, a cached preview), open the published preview URL in private mode to verify what a stranger's first visit actually looks like, before you ship the share link.

The five pitfalls that make private-mode tests lie

Each one of these has caught me, and each one looks innocent until you remember it.

Real scenarios where private mode is the right answer

The tool fits a specific shape of testing problem: you need to see a logged-out, no-storage state from your normal machine without losing your real browser session. That covers more day-to-day tasks than people credit it for.

The pattern across all of these: you need empty client storage and an unbiased first-visit path, but you do not care about IP isolation or fingerprint reset. If your test does care about those, escalate to a fresh profile, a fresh VM, or a residential proxy.

When to graduate from incognito to something stronger

Three escalation paths, in increasing order of overhead. None of them replace incognito for the day-to-day; they fill the holes incognito leaves.

First, a fresh browser profile. Open Chrome's profile menu, create a new profile pinned to the dock, and use that profile for testing. Heavier than incognito (you have to log in to extensions and dev tools again) but lets you see real browsing history, run extensions, and persist a stable cookie identity across sessions. Useful when you want to come back tomorrow and still be the same test user.

Second, a Playwright script with storageState set to an empty object on each run. Reproducible, scriptable, runnable in CI. The cost is about an hour of setup the first time, then it amortizes across every future test. mk0r uses this internally to verify generated apps before showing them back to the user; the same approach works for any web app you are iterating on.

Third, a fresh cloud VM with its own residential IP. Heaviest, slowest, but the only way to truly simulate a different device on a different network. Worth it when the feature you are testing depends on geo-routing, IP-based rate limiting, or any system that fingerprints the network rather than the browser. mk0r's own VM mode runs Chromium inside an E2B sandbox with an optional residential IP layer; the same primitive works as a one-off test rig.

Frequently asked questions