Cookies and Device Fingerprint: Amazon Account Linking Explained

Every week, somewhere, a seller opens Seller Central and finds the red banner: account deactivated, "related to another account." They never shared a password. They never logged into the old account from the new laptop. They cleared their cookies religiously. And yet Amazon knew — usually within days, sometimes within hours of the second account's first login.

The mechanism behind that banner is what this article unpacks: cookies and device fingerprint Amazon account linking, the two-layer identification system that ties accounts to machines and machines to each other. Most of what circulates in seller forums about it is folklore — half-remembered, out of date, or flat wrong. The actual system is simpler to describe and much harder to beat than the folklore suggests, and understanding it precisely is the difference between accounts that survive for years and accounts that die in a review queue.

This is an informational deep dive, not a loophole list. By the end you'll know what Amazon can see, which signals survive a cookie wipe, why incognito mode is close to useless here, and what genuinely separate browser environments look like in practice.

Why Amazon links accounts at all

Amazon's marketplace runs on trust math. When a seller account gets suspended for counterfeits, review manipulation, or unpaid reimbursements, the cheapest move for that seller is to open a fresh account and carry on. Amazon's account-linking system exists to make that move expensive. It isn't primarily hunting people who run two legitimate businesses — it's hunting ban evasion, and everyone else is collateral.

That framing matters because it explains the system's behavior. Linking is guilty-by-association: if account A is flagged and account B shares enough signals with A, B inherits A's problem. A perfectly healthy account can be deactivated purely because it was once opened on a laptop that, two years earlier, touched a suspended account. The infraction transfers through the link; the link is built from identity signals; and the two richest identity signal families are cookies and the device fingerprint.

It's worth saying clearly: Amazon does not blanket-ban multiple accounts. Its Seller Code of Conduct permits operating more than one account when there's a legitimate business need — separate brands, separate legal entities, separate marketplaces — and since 2021 you generally don't even need prior approval if each account has its own bank account, its own catalog, and no policy strikes. What the policy actually forbids is using a second account to evade enforcement on the first. But the detection system can't read your intent. It reads signals. If your two legitimate accounts share a browser environment, the machine sees exactly what ban evasion looks like, and the machine acts first. We covered the enforcement side of this in How to Avoid Account Bans on Amazon Seller: 2026 Playbook; this article covers the identification side.

Layer one: cookies — the persistent paper trail

Cookies are the layer everyone knows about, and almost everyone underestimates.

Open amazon.com in a fresh browser and, before you log into anything, Amazon sets identifiers. The best known is ubid-main — a unique browser ID with an expiry of roughly twenty years. It exists precisely to recognize this browser installation across sessions, across logins, and across logouts. Alongside it you'll find session-id (rotates more often, but each rotation is server-logged against the previous one), x-main and at-main (authentication tokens once you sign in), and a rotating cast of others. If you want the underlying mechanics, MDN's HTTP cookies documentation is the canonical reference — what matters for us is not how cookies work but how Amazon uses them.

Here's the part sellers miss. The cookie isn't just a login token; it's a join key in Amazon's backend. Every account that authenticates while a given ubid-main is present gets recorded against that browser ID. Log into your personal buyer account on Monday and your seller account on Tuesday from the same Chrome profile, and Amazon's data now contains a durable fact: these two accounts share a browser. That fact never expires just because you later clear the cookie. The linkage was written server-side at the moment of overlap.

This is why "I always logged out first" offers no protection whatsoever. Logging out ends the session; it does not delete the browser ID, and it certainly does not delete the server-side record of which accounts that browser ID has carried. It's also why the most common origin story for a linked-account suspension is mundane: the seller checked a personal order, or a virtual assistant logged into a client's account, or someone opened "just for a second" a friend's Seller Central on their own machine. One overlapping session, one permanent edge in the graph.

What clearing cookies actually does

Clearing cookies resets the future. The old ubid-main is gone; Amazon issues a new one on your next visit. But three things blunt the value of that reset. First, the historical linkages remain — clearing cookies doesn't unlink anything already linked. Second, a brand-new browser ID appearing on a device whose other signals are unchanged is itself informative: same fingerprint, same IP, fresh cookie jar is a recognizable pattern, not a disguise. Third, cookies were never the only identifier. Which brings us to the layer that survives the wipe.

Layer two: the device fingerprint — identity without storage

A device fingerprint is an identifier that is computed, not stored. Instead of writing a value to your disk, the site measures dozens of properties of your browser and hardware and hashes the combination. Nothing to clear, because nothing was saved on your side. Wikipedia's overview of device fingerprinting covers the academic history; the practical summary is that a modern fingerprint distinguishes browsers with startling precision — the EFF's Cover Your Tracks project has been demonstrating for years that a typical browser configuration is unique or near-unique among hundreds of thousands of visitors.

What goes into it? On a site with Amazon's engineering budget, roughly this:

• Canvas rendering. The browser draws hidden text and shapes to a canvas element; the exact pixels vary with your GPU, driver version, OS font rendering, and anti-aliasing. The hash of those pixels is a hardware signature.
• WebGL and GPU identity. The unmasked renderer string ("NVIDIA GeForce RTX 4070", "Apple M3") plus dozens of WebGL capability parameters. This one signal alone narrows you enormously — we dissected it in WebGL Fingerprint Spoofing Explained.
• Audio stack. An OfflineAudioContext processes a signal; floating-point differences across audio hardware and drivers produce a stable per-machine value.
• Fonts. The installed font list, measured indirectly through text metrics, reflects your OS, its version, and every application you've ever installed that bundled a font.
• Screen and window geometry. Resolution, color depth, device pixel ratio, available screen space minus taskbars.
• Navigator surface. User agent, platform, hardware concurrency (CPU cores), device memory, language list, timezone.
• Client hints and TLS. Modern Chromium exposes structured UA client hints, and the TLS handshake itself has a fingerprintable shape before a single byte of JavaScript runs.

No single measurement identifies you. The combination does. Two different laptops of the same model will still usually diverge on fonts, drivers, screen setup, or timezone. And critically for the Amazon case: this fingerprint is identical across every Chrome profile on the machine, identical in incognito mode, and identical after you clear all site data. It's a property of the machine and browser build, not of any stored state.

How the two layers reinforce each other

Cookies and fingerprints individually have weaknesses — cookies can be cleared, fingerprints occasionally collide. Together they cover each other's gaps, which is exactly why the phrase "cookies and device fingerprint Amazon account linking" describes one system rather than two. The fingerprint re-identifies a device after a cookie wipe, allowing the new cookie to be joined to the old one server-side. The cookie disambiguates two machines that happen to fingerprint similarly. A cookie reset on a stable fingerprint is a non-event; a fingerprint change under a stable cookie is a non-event; you'd have to break both simultaneously — plus the network layer — to present as a new device, and doing that by hand is close to impossible.

What the linking engine actually does with the signals

Nobody outside Amazon knows the exact model, and anyone claiming otherwise is guessing. But the observable behavior — which suspensions happen, how fast, and what appeal outcomes reveal — is consistent with a probabilistic scoring system over a large identity graph, the same architecture every serious platform uses (we walked through the general version in How Websites Detect Multiple Accounts on the Same Device).

Picture every account, cookie ID, device fingerprint, IP address, payment method, phone number, and address as nodes in a graph. Every observed co-occurrence draws an edge: this fingerprint was seen with that cookie; that cookie carried this login; this login came from that IP. Most edges are weak on their own — millions of people share a mobile carrier's IP pool. But edges accumulate, and some are near-conclusive. Shared ubid-main with overlapping logins is close to proof. Identical canvas-plus-WebGL-plus-fonts fingerprint is very strong. Same bank account or tax ID is administrative certainty, no browser signals required.

Two behaviors follow from the graph model, and both match what sellers experience. First, linking is retroactive. The edge created the day you checked your personal orders in the wrong browser sits dormant in the graph. When either account later trips enforcement, the graph is walked, the edge is found, and the other account inherits the flag — months or years later. Sellers experience this as a suspension "out of nowhere"; the graph experienced it as a long-scheduled consequence. Second, linking cascades. Account B linked to suspended account A doesn't just get suspended — B's own fingerprints, cookies, and payment nodes are now tainted, and anything touching them comes under suspicion. This is how one bad account poisons an entire operation, and why cleanup after a linking event is so much harder than prevention.

The signal table: what survives what

Read the last column carefully, because it kills the most popular "solution." Chrome's built-in profiles separate cookies and history — the storage row — and nothing else. Every profile on the machine presents the same fingerprint, the same IP, the same TLS shape. To Amazon, five Chrome profiles are one device with five cookie jars, which is arguably more suspicious than one.

The myths, and why each one fails

"I use incognito for the second account." Incognito discards cookies at the end of the session. The fingerprint and IP are untouched. Amazon sees a familiar device that keeps showing up cookieless — a pattern, not an absence.

"I clear cookies between logins." Resets the future, not the past, and the fingerprint bridges the gap anyway. Worse, alternating logins from one fingerprint with fresh cookies each time is a distinctive rhythm of its own.

"I use a VPN." A VPN changes exactly one row of the table — IP — and replaces it with an address from ranges that are publicly catalogued as datacenter or VPN space. The fingerprint and cookie layers are untouched, and the IP layer now looks worse for a selling account, since real small businesses rarely operate from VPN exit nodes. If you're going to fix the network layer, it needs residential or ISP IPs with stable geography — the full reasoning is in Antidetect Browser with Residential Proxies: The 2026 Playbook.

"I bought a second laptop." Genuinely the strongest naive approach — it truly is a second fingerprint. It fails operationally instead: both laptops sit on one home IP, and the day you're traveling and "just quickly" handle both accounts from one machine, the graph gets its edge. Hardware separation also doesn't scale past two or three accounts; nobody runs eight laptops.

"Different browsers — Chrome for one, Firefox for the other." Better than Chrome profiles, since the fingerprints genuinely differ. But the IP is shared, several fingerprint components leak the same underlying hardware (GPU strings, fonts, screen), and the approach caps out at the number of distinct browsers you can stand to use.

The common thread: each trick addresses one row of the table while leaving the others intact, and the linking engine only needs the rows you didn't cover.

What real separation looks like

If the detection model is "correlate every signal a browser emits," then genuine separation means every account gets a browser environment where all the signals are consistent, isolated, and distinct. That decomposes into four disciplines.

One isolated environment per account

Each account needs its own complete browser data directory — cookies, localStorage, IndexedDB, cache, service workers — that no other account ever touches. Not a Chrome profile sharing a binary and a fingerprint; a fully partitioned environment. This is the core of what an antidetect browser does: each profile runs as its own real browser process with its own persistent storage, so account A's ubid-main and account B's ubid-main live in different worlds and can never be observed together. Persistence matters as much as isolation — the cookies must survive between sessions, because to Amazon a returning browser with a year-old ubid-main and accumulated history is what a real customer looks like. Fresh cookie jars on every launch would be the opposite of stealth.

One consistent, distinct fingerprint per profile

Each profile needs a fingerprint that (a) differs from your real machine and from every sibling profile, and (b) is internally coherent — Windows fonts with a Windows user agent with a plausible GPU for that class of machine, a screen resolution that exists in the real world, a timezone that matches the IP's geography. Coherence is the hard part. Amazon-scale fingerprinting scripts cross-check components against each other, so a mismatched combination (an "iPhone" reporting 16 CPU cores, a macOS UA with Segoe UI in the font list) is a louder alarm than no spoofing at all. Quality antidetect implementations apply the fingerprint natively inside the browser engine rather than by injecting JavaScript overrides — injected shims are themselves detectable through function-integrity checks. The mechanics of doing this properly are a topic of their own; start with How to Change Browser Fingerprint: A Practical 2026 Guide.

One IP identity per account

Each profile gets its own proxy, residential or ISP, geographically consistent with the account's registered business address, and sticky — the same account appearing from Ohio, Frankfurt, and Singapore in one week is its own flag. Bind the proxy to the profile so the pairing never varies. And mind WebRTC: a browser can leak the real IP through STUN requests even when all HTTP traffic goes through the proxy, so the environment must mask WebRTC to the proxy's exit address, not just route page traffic.

Operational hygiene

The browser environment is necessary, not sufficient. Keep payment methods, bank accounts, phone numbers, and emails fully disjoint between accounts — those administrative links bypass the browser entirely and are the easiest edges for Amazon to draw. Never cross the streams "just once"; the graph is written in ink. Stagger activity patterns so accounts don't wake, list, and reply in lockstep. And if one account does get suspended, treat everything it touched — its proxy, its fingerprint, its payment instrument — as burned rather than recyclable.

The same architecture generalizes beyond Amazon, incidentally. eBay, Etsy, and Walmart Marketplace run the same two-layer identification with different weightings, which is why sellers who solve it properly once tend to solve it everywhere — see Best Browser for Managing Multiple eBay Accounts for how the pattern transfers.

Approaches compared

A note on legitimacy

None of this is an invitation to evade enforcement. If an account was suspended for genuine policy violations, standing up a disguised replacement violates Amazon's Code of Conduct, and the administrative layer — banking, tax identity, product catalog — will eventually link what the browser layer hid. The honest use case for everything above is the operator with legitimately separate businesses: an agency managing storefronts for distinct clients, a company running approved accounts across marketplaces and regions, a brand keeping its wholesale and DTC entities apart. Those operators aren't trying to fool Amazon about who they are on paper — their entities, banks, and catalogs are genuinely distinct. They're trying to prevent a false-positive browser linkage from tying entities that are actually separate, because the automated layer suspends first and lets you appeal later, and appeals of linked-account suspensions are notoriously slow and opaque. Clean browser separation keeps the machine's picture aligned with the paper reality.

FAQ

Does clearing cookies unlink my Amazon accounts?

No. Clearing cookies deletes the identifiers stored in your browser, but the linkage was recorded on Amazon's servers at the moment two accounts shared a browser ID, and that record persists. Your device fingerprint also survives the wipe, letting Amazon join your new cookie to the old one. Cookie clearing changes the future; it cannot rewrite the past.

Can Amazon link accounts through incognito mode?

Yes. Incognito gives you temporary cookies but leaves your device fingerprint — canvas, WebGL, fonts, screen, timezone — and your IP address completely unchanged. Amazon can recognize the device across incognito sessions with high confidence, so incognito provides essentially no protection against account linking.

Is it against Amazon's rules to have multiple seller accounts?

Not inherently. Amazon's Seller Code of Conduct allows multiple accounts for legitimate business needs — separate brands, entities, or marketplaces — generally without prior approval, provided each account has its own bank account, its own products, and no policy violations. What's prohibited is using a second account to evade enforcement actions on the first.

How fast does Amazon link two accounts?

The signal collection is immediate — identifiers are recorded from the first page load and every login. Enforcement, though, is often retroactive: the linksits in Amazon's identity graph until something triggers a review of either account, which may be days or years later. Many sellers only discover a two-year-old linkage when an unrelated complaint prompts a review.

Do Chrome profiles keep Amazon accounts separate?

Only at the cookie layer. Chrome profiles partition cookies, history, and extensions, but every profile on a machine shares the same GPU, fonts, screen, user agent, timezone, TLS fingerprint, and IP address. Amazon reads all of those, so multiple Chrome profiles look like one device with several cookie jars.

Is a VPN enough to prevent account linking?

No. A VPN changes only your IP, and typically to a datacenter range that's publicly identifiable as VPN infrastructure — which reads worse for a seller account than a normal residential IP. Your cookies and device fingerprint are untouched, so the two strongest linking layers remain fully intact.

What happens if one linked account gets suspended?

Enforcement propagates along the links. A suspension on one account routinely triggers deactivation of every account sharing a strong signal with it, and the shared identifiers — fingerprints, cookies, payment instruments, addresses — become tainted for future registrations too. This cascade is why prevention is dramatically cheaper than remediation.

Closing thought

The uncomfortable truth about cookies and device fingerprint Amazon account linking is that there's no clever trick hiding in it. Amazon isn't running one detection you can defeat with one setting; it's running a correlation engine over every signal your browser emits, and it's patient enough to act on evidence collected years earlier. Every partial measure — incognito, cookie clearing, a VPN, an extra Chrome profile — closes one row of a table with seven rows.

Which means the only durable answer is architectural: give every account a browser environment that is genuinely, completely its own — isolated persistent storage, a coherent and distinct fingerprint applied at the engine level, and a dedicated sticky residential IP — and then never let those environments touch each other. Do that from the start and the linking engine has nothing to correlate. Bolt it on after the first suspension and you're managing damage instead of preventing it.

Dual Login was built for exactly this shape of problem: each profile is a real browser process with its own data directory, its own natively-applied fingerprint, and its own bound proxy, so ten accounts look like ten devices in ten places rather than one machine wearing ten hats. If you're running multiple marketplace accounts and currently relying on Chrome profiles and good intentions, spin up a couple of Dual Login profiles and compare what a fingerprinting test site reports for each. Seeing two genuinely different devices come out of one computer tends to clarify the whole problem faster than any article can.

Worth reading next if you're building this out: Antidetect Browser for Dropshipping Stores for the multi-store operational patterns, and Cheaper Multilogin Alternatives That Actually Work in 2026 if you're weighing tools on cost.