How Websites Detect Multiple Accounts on the Same Device

You logged out. You cleared cookies. You even opened an incognito window. And the platform still greeted your second account with a verification wall — or banned both accounts an hour later.

This happens because logging out doesn't make you a different person, and it certainly doesn't make your laptop a different laptop. Modern platforms don't rely on any single identifier to spot duplicate accounts. They run a layered detection stack that combines browser storage, network data, device fingerprints, and behavioral patterns into a confidence score — and once two accounts share enough of those signals, they get linked whether you intended it or not.

I've spent years on both sides of this problem: building account-management infrastructure and reverse-engineering why perfectly legitimate second accounts kept getting flagged. This article walks through exactly how websites detect multiple accounts on the same device, layer by layer, with the specific signals involved — and then covers what genuine separation actually requires. No hand-waving, no "just use a VPN."

Why Platforms Hunt for Duplicate Accounts

Before digging into the mechanics, it helps to understand the incentive, because it explains how aggressive the detection is.

For most platforms, duplicate accounts map directly to fraud categories they lose money on: promo abuse (one person redeeming a signup bonus fifty times), ban evasion (a suspended user returning under a new name), fake engagement (one operator running a hundred review accounts), ad policy circumvention, and marketplace manipulation. Facebook alone removes billions of fake accounts per year, and its terms of service — like those of most major platforms — explicitly restrict one person to one personal account.

The important consequence: platforms are optimizing for catching abusers at scale, not for being fair to edge cases. An agency managing ten client ad accounts from one office computer produces almost the same signal pattern as a promo abuser. The detection systems don't ask about your intent. They ask whether two accounts look like the same device and the same human — and if the answer is yes, enforcement follows.

That's why understanding the signals matters even if your use case is entirely legitimate — agencies, e-commerce sellers with regional storefronts, social media managers, QA teams. If that's you, our guide on how to manage multiple accounts without getting banned covers the operational side; this article covers the detection side.

The Detection Stack: Every Signal Websites Actually Use

Think of detection as seven layers, ordered roughly from easiest to hardest to control. Platforms rarely rely on one layer. They correlate across all of them.

Layer 1: Cookies, Local Storage, and the Browser's Junk Drawer

The obvious one first. When you log into account A and then log into account B in the same browser profile, the site can trivially observe that both sessions came from a browser holding the same identifiers.

But "cookies" undersells how much storage a modern browser exposes. A single browser profile carries:

• HTTP cookies — including long-lived tracking cookies set months ago, not just session cookies.
• localStorage and sessionStorage — key-value stores that survive cookie clearing unless you wipe them explicitly.
• IndexedDB — a full client-side database; plenty of sites stash device IDs here precisely because nobody thinks to clear it.
• Cache-based identifiers — ETags and cached resources can be abused to re-identify a browser even after cookies are gone.
• Service workers — persistent scripts that survive tab closes and can hold state.

Here's the pattern that catches most people: a site writes the same device token into cookies, localStorage, and IndexedDB. You clear cookies, log into your second account, and the site's JavaScript quietly reads the token back out of IndexedDB and re-writes the cookie. The two accounts are now linked by a token you thought you deleted. This technique — sometimes called cookie respawning — has been documented for over a decade and is still common.

The only reliable defense at this layer is not cleaning a shared profile but never sharing one: each account gets its own browser profile with its own storage directory, so there is simply nothing to respawn from.

Layer 2: Your IP Address (and What It Says About You)

Every request you make carries your public IP address. On its own an IP is a weak identifier — home connections rotate, offices share one IP across dozens of people — so no serious platform bans purely on a shared IP. But as a correlation signal it's powerful:

• Same IP + same time window + similar accounts is a classic linking pattern. Two "unrelated" seller accounts that always come online from the same residential IP within minutes of each other are not fooling anyone's graph.
• IP reputation matters as much as the address itself. Datacenter IP ranges (AWS, Hetzner, OVH) are published and trivially flagged; a "personal" account logging in from a datacenter IP raises risk scores immediately. This is why cheap VPNs often make things worse.
• Geolocation consistency gets cross-checked against everything else. An IP in Frankfurt paired with a browser reporting an America/New_York timezone and en-US language is a mismatch that fingerprinting systems score heavily.
• IP history per account — platforms remember which addresses each account has used. A new account appearing on an IP that previously hosted a banned account inherits suspicion.

One subtle leak deserves its own mention: WebRTC. Even behind a proxy or VPN, WebRTC's connection-establishment machinery can reveal your real local and public IP addresses to a webpage unless the browser masks them. Any setup that routes traffic through a proxy but leaves WebRTC untouched is leaking the one thing the proxy was supposed to hide.

Layer 3: Browser Fingerprinting — the Quiet Workhorse

This is the layer most people underestimate, and it's the reason clearing cookies achieves so little. Browser fingerprinting builds an identifier out of the properties of your browser and hardware — no storage required, nothing to clear.

The classic signals, all readable by ordinary JavaScript:

• Canvas fingerprinting. The site draws text and shapes to an invisible HTML canvas and hashes the pixel output. The result varies with your GPU, driver version, font rendering, and anti-aliasing settings — producing a hash that's stable for your machine and different from most others.
• WebGL fingerprinting. The GPU vendor and renderer strings (e.g. "ANGLE (NVIDIA GeForce RTX 3060 Direct3D11)") plus dozens of WebGL capability parameters. Rendering a 3D scene and hashing it adds more entropy.
• AudioContext fingerprinting. Processing a silent audio signal through the Web Audio API yields floating-point output that differs subtly across hardware and OS audio stacks.
• Font enumeration. The exact set of installed fonts, measured by rendering text and checking dimensions. Installed-font lists are surprisingly distinctive, especially on machines with design tools.
• Screen and window metrics. Resolution, color depth, device pixel ratio, available screen space minus taskbars.
• Navigator properties. User agent, platform, hardware concurrency (CPU core count), device memory, language list, touch support, plugin list.
• Timezone and locale. Both the reported timezone and the actual UTC offset your JavaScript clock computes.

Individually these are weak. Combined, they're devastating: the EFF's Cover Your Tracks project has demonstrated for years that the combination of these attributes is unique or near-unique for the large majority of browsers. Twenty-odd attributes, each contributing a few bits of entropy, is enough to distinguish one browser among millions.

Now apply that to multiple accounts: if account A and account B both present canvas hash 9f31c2..., the same WebGL renderer string, the same font list, and the same screen geometry, the platform doesn't need cookies to know they're the same machine. Log out, clear everything, switch to incognito — the fingerprint doesn't change, because your hardware didn't change.

We've written a full deep-dive in Browser Fingerprinting Explained (And How to Defeat It) if you want the entropy math and per-signal details.

Layer 4: Hardware and OS-Level Identifiers

Beyond the browser, some detection reaches toward the device itself:

• Client Hints. Modern Chromium exposes structured User-Agent Client Hints — OS version, architecture, device model, full browser version — which sites can request and which must stay consistent with the classic user agent string and everything else. A mismatch here is itself a red flag.
• Media device enumeration. The number and labels of cameras, microphones, and speakers, exposed via enumerateDevices(). A machine with the same unusual audio-device set across two accounts is a linking signal.
• Mobile apps go further. Native apps (and their embedded webviews) can access advertising IDs (GAID/IDFA), device model and build fingerprints, and platform attestation APIs. This is why running multiple accounts through a platform's mobile app is dramatically harder than through the web — the identifiers are stronger and partially outside your control.
• GPU and codec capabilities. Which video codecs hardware-decode, supported WebGPU features, and performance characteristics all describe your silicon.

Layer 5: Network-Level Fingerprints (TLS, JA3, and Friends)

A layer most guides skip entirely: your traffic is identifiable before a single byte of JavaScript runs.

When your browser opens an HTTPS connection, the TLS ClientHello it sends — cipher suites offered, extensions, elliptic curves, and their exact order — forms a fingerprint (commonly hashed as JA3/JA4). Every Chrome 131 on Windows produces essentially the same TLS fingerprint; every Python requests script produces a very different one. HTTP/2 connection settings and header ordering add more.

This matters for two audiences. Automation users get caught when their HTTP library's TLS signature doesn't match the browser it claims to be — the core problem covered in our web scraping without getting blocked guide. And multi-accounters get caught by consistency checks: if your user agent says Chrome on Windows but your TLS handshake says otherwise, the session is flagged before the page loads. The defense is simple in principle: use a real browser, so the network fingerprint is genuinely what it claims to be.

Layer 6: Behavioral Biometrics

Even with a perfectly separated device identity, you are still you. Behavioral systems profile:

• Typing cadence — inter-key timing, burst patterns, your habitual typos and corrections.
• Mouse dynamics — movement curves, acceleration, how you overshoot targets, scroll rhythm.
• Navigation habits — the order you visit pages, how long you dwell, which UI paths you take.
• Session timing — the same two accounts active in alternating 20-minute blocks, every day, from the same city.

Behavioral linking is fuzzier than fingerprint matching and mostly contributes to a risk score rather than triggering bans alone. But it's the layer that catches operators who did everything else right and then managed ten accounts in one two-hour sitting with identical robotic efficiency. It's also why crude automation gets flagged: scripted mouse movements that teleport in straight lines at constant speed look nothing like a human hand.

Layer 7: The Account Graph — Data You Gave Them Yourself

Finally, the layer with the highest-confidence links and no technical mitigation at all: shared account data.

• The same phone number or recovery email across accounts.
• The same payment method — card fingerprints and billing addresses are linking gold, and platforms treat them as near-proof.
• The same shipping address, tax ID, or business registration.
• Social graph overlap — two accounts that friend, follow, message, or transact with the same tight cluster of people.
• Cross-account interaction — account B liking, upvoting, or buying from account A is the oldest self-own in the book.

No browser tool can help here, and it's worth being blunt about that. Perfect technical separation collapses instantly if both accounts share a verification phone number. Real separation is technical and operational.

Quick Reference: Detection Signals Side by Side

Read the middle two columns carefully — they're the whole story. Only one layer out of seven is affected by the things most people try first.

Why the Obvious Tricks Fail

Incognito Mode Doesn't Do What You Think

Private browsing gives you a fresh, temporary cookie jar. That's it. Your IP is identical, your canvas hash is identical, your fonts, screen, timezone, WebGL renderer, and TLS fingerprint are identical. To a fingerprinting system, an incognito window is the same device with suspiciously empty storage — which some anti-fraud systems treat as a signal in itself, since fraud attempts disproportionately arrive with no history. Incognito is a privacy tool against other local users of your computer, not against the website.

Clearing Cookies Only Resets One Layer

Clearing cookies (even "all site data") resets Layer 1 and nothing else. Worse, the sequence is legible: a device that held account A, wiped its storage, and immediately logged into new account B, from the same IP with the same fingerprint, has essentially confessed. Platforms have seen this movie millions of times.

A VPN Alone Makes You Look More Suspicious, Not Less

A VPN changes Layer 2 — partially. Popular VPN exit nodes are shared by thousands of users, sit in published datacenter ranges, and often carry poor reputation. Meanwhile your fingerprint still matches across accounts, and now your IP geolocation may contradict your timezone and language. Two accounts with identical fingerprints hopping between VPN endpoints look more like coordinated multi-accounting, not less. If the goal is separation, each account needs its own consistent, residential-quality IP — not one shared tunnel.

How Linking Decisions Actually Get Made

A misconception worth killing: platforms don't run a single "same device?" check. They compute similarity scores across many signals and act on thresholds, which explains behavior that otherwise looks random.

A typical flow: two accounts share a fingerprint hash → linked as "same device" internally, no action (families share computers, and platforms know it). Add a shared IP pattern and overlapping active hours → risk score rises; one account starts seeing more CAPTCHAs and verification prompts. One account then violates a policy → enforcement propagates across the linked cluster, and the "innocent" account goes down with it. That last step is why people report bans on accounts that "did nothing wrong": the account didn't, but its cluster did.

Two practical consequences follow. First, linking is usually silent and precedes enforcement by weeks — by the time you see a ban, the association was established long ago. Second, separation must be in place from account creation onward. Splitting two accounts after they've shared a device for six months doesn't unlink the history; platforms remember.

This is also why half-measures fail so consistently. Fixing three signals out of seven doesn't give you three-sevenths of the protection — a single high-confidence link (a matching canvas hash, a shared card) is enough to join the cluster.

How to Keep Multiple Accounts Genuinely Separate

Everything above inverts into a checklist. Legitimate multi-account operators — agencies running client ads, brands with regional storefronts, teams doing QA and market research — need every layer handled, because platforms check every layer.

One Profile, One Identity

Each account needs its own complete browser environment: separate cookie jar, localStorage, IndexedDB, cache, and history, stored in its own data directory that never touches another account's. Not separate tabs. Not separate Chrome profiles that still share a hardware fingerprint. Fully isolated environments. This eliminates Layer 1 permanently — there's no shared storage to respawn identifiers from — and it's the foundation everything else builds on.

One Clean Proxy Per Account, Bound Permanently

Assign each profile its own residential or high-quality ISP proxy, in the geography where that account plausibly lives, and never rotate it casually. An account that logs in from the same city every day looks like a person; an account that hops countries weekly looks like a bot. Bind the proxy to the profile so you can't fat-finger a launch through the wrong IP — one mistaken login from your real IP links the account to everything else that IP has touched. And ensure WebRTC is masked to the proxy's exit IP, or the proxy is decorative.

Consistency Beats Randomness

The naive fingerprinting fix — randomize everything on every load — backfires badly. A device whose canvas hash changes hourly, or whose navigator claims Windows while its rendering behaves like Linux, doesn't look private; it looks like evasion tooling, and fingerprinting vendors detect incoherence as aggressively as they detect duplicates.

What works is a fingerprint that is different per profile but internally consistent and stable over time: a plausible GPU string matched to a plausible OS, a screen resolution that exists on real hardware, a timezone and language that agree with the proxy's geography, hardware concurrency that fits the claimed device class — all held stable across sessions so each account appears to live on one ordinary machine. This is precisely the hard part, and it's the difference between tooling that spoofs at the JavaScript layer (detectable by probing for patched functions) and tooling that applies the fingerprint natively inside the browser engine. Our guide on what an antidetect browser is and how it works unpacks that distinction properly.

Behave Like Different People, Not Just Different Browsers

Operational discipline closes the remaining layers:

• Never cross-contaminate declared data — unique emails, phone numbers, and payment methods per account, and no interactions between your own accounts.
• Stagger activity. Ten accounts marching through identical tasks in one sitting is a behavioral signature. Spread sessions across hours and vary what each account does.
• Warm accounts up. New accounts that immediately behave like power users get flagged; browse, idle, and act like a normal user first.
• Keep an assignment log. Which proxy, which profile, which persona details belong to which account — because a single mix-up can link months of careful separation. Platform-specific tactics for the strictest environments are covered in our guide to managing multiple Facebook accounts safely.

Where Antidetect Browsers Fit In

You can attempt all of this manually — separate machines, or virtual machines with separate VPNs — and some operators do. It works, at brutal cost: a VM per account devours RAM, fingerprints inside identical VMs are often themselves identical (and datacenter-flavored), and nothing stops the human error of logging into the wrong account from the wrong place.

An antidetect browser is the purpose-built answer: one application that runs many isolated browser profiles, each with its own persistent storage, its own consistent spoofed fingerprint, and its own bound proxy, launched as a genuinely separate browser process. The good ones apply fingerprints natively in the browser engine rather than injecting JavaScript overrides — because injected overrides leave detectable seams (patched toString outputs, properties that disagree with actual rendering behavior) that anti-fraud scripts specifically probe for.

Dual Login takes exactly that approach: a custom Chromium engine where each profile's canvas, WebGL, audio, fonts, navigator, screen, timezone, and language are set natively and stay internally consistent; per-profile data directories so log-ins persist and never bleed across accounts; per-profile proxy binding with WebRTC masked to the exit IP; and a full automation API for teams that need scale. Because profiles are portable, an account's session can move between machines without re-triggering the "new device" checks that cause verification storms.

If you're evaluating options, we keep an honest comparison in Best Antidetect Browser in 2026: Top 7 Compared, and teams thinking about permissions, shared access, and handovers should read Browser Profile Management: Best Practices for Teams.

What This Does and Doesn't Solve

Worth being straight about the limits.

Proper tooling solves the technical layers: storage isolation, fingerprint separation, IP separation, network-fingerprint authenticity. Those are the layers you cannot fix by being careful, and they're where most people fail.

It does not solve the account graph. Share a payment card and you're linked, full stop. It does not solve behavior — if you drive fifty accounts through identical scripted motions at 3 a.m., pattern analysis will find you. And it does not make you exempt from platform terms of service. Many platforms permit multiple accounts explicitly (business managers, seller accounts, developer accounts, agency structures); some restrict personal accounts to one per person. Knowing which regime you're operating in — by reading the actual terms, such as Meta's Terms of Service for its platforms — is part of doing this responsibly. The technology enforces separation; it doesn't grant permission.

The honest summary: detection is a scoring system, and your job is to avoid contributing high-confidence links. You can get that right across every layer you control, and the tooling exists to make it routine rather than heroic. Whether the accounts should exist is a question for the platform's rules and your own judgment.

FAQ

Can a website tell if I have two accounts if I use different browsers?

Often, yes. Different browsers on the same machine give you separate cookie jars, but many fingerprint signals come from shared hardware and OS resources — your GPU (WebGL renderer strings), your installed font set, your screen resolution, your timezone, and above all your IP address. Chrome and Firefox on the same laptop will produce different canvas hashes, but the overlapping signals plus a shared IP and correlated session timing are usually enough to link the accounts with high confidence.

Does using a VPN stop websites from linking my accounts?

No. A VPN changes only your IP address, which is one signal out of many. Your browser fingerprint — canvas, WebGL, fonts, screen, audio — stays identical across accounts, so the link remains. Shared VPN exit nodes also sit in datacenter ranges that platforms flag as high-risk, and a VPN's location often contradicts your browser's timezone and language, creating a mismatch that raises your risk score rather than lowering it.

How long do platforms remember that two accounts were on the same device?

Indefinitely, in practice. Device-account associations are stored as part of a persistent risk graph, not as short-lived session data. Accounts that shared a device or IP months or years ago typically remain linked, which is why separating accounts after they've been used together rarely undoes the association. Separation is much more effective when it's in place from the moment each account is created.

Is incognito mode enough to run a second account?

No. Incognito gives you a temporary, empty cookie jar and nothing else. Your IP, canvas fingerprint, WebGL renderer, font list, screen metrics, timezone, and TLS fingerprint are all unchanged. From the website's perspective, an incognito session is the same device with conspicuously empty storage — and for some anti-fraud systems, the absence of any browsing history is itself a mild risk signal.

Will randomizing my fingerprint on every page load protect me?

Usually the opposite. Real devices have stable fingerprints. A browser whose canvas hash, GPU string, or screen resolution changes between page loads is immediately anomalous, and fingerprinting vendors actively detect that instability. Effective separation uses a fingerprint that differs between profiles but stays consistent within each profile over time, with all its attributes agreeing with one another — the same GPU, OS, timezone, and language story every session.

Can websites detect that I'm using an antidetect browser?

They can detect poorly implemented ones. Tools that spoof by injecting JavaScript overrides leave traces — patched native functions, property values that contradict actual rendering output, timing anomalies — and detection scripts probe for exactly those seams. Implementations that apply the fingerprint natively inside the browser engine, before any JavaScript runs, don't expose those inconsistencies, because there's no override layer to find. Consistency is what's actually being tested: a profile whose reported properties match its real observable behavior looks like an ordinary device.

Wrapping Up

The short version: websites detect multiple accounts on the same device by correlating storage identifiers, IP data, browser and hardware fingerprints, network-level TLS signatures, behavioral patterns, and shared account details into a single confidence score. Clearing cookies addresses one of those. Incognito addresses part of one. A VPN addresses part of another. That's why the usual advice fails so reliably.

Genuine separation means every account getting its own isolated storage, its own stable and internally consistent fingerprint, its own dedicated proxy, and its own operational details — maintained from day one, not retrofitted after the first ban.

If you're running accounts that legitimately need to stay separate — client workspaces, regional storefronts, research profiles, testing environments — Dual Login handles the technical layers so you can focus on the work: isolated profiles with native, consistent fingerprints, per-profile proxy binding with WebRTC masking, portable sessions across machines, and an automation API when you outgrow doing it by hand. Spin up a couple of profiles, run them past a fingerprinting test, and see what separation actually looks like.