What Still Leaks Between Two Browser Profiles
Separate profiles handle cookies and storage cleanly. Then there are the four signals they do nothing about, which is where most linkage actually happens.
Using a separate browser profile per identity is the correct first move, and it does its job well. Cookies, localStorage, sessionStorage, IndexedDB, service worker registrations, and the cache are partitioned per profile, so identifiers a site writes into one profile are genuinely not readable from another. If your threat model is a site setting a cookie and reading it back later, profile separation closes that off completely.
The problem is that it closes off the storage layer and nothing else. Four things sit outside it, and between them they account for most of the linkage people are actually worried about.
The first is the network address. Two profiles on one machine share one connection. Every site both profiles visit sees the same IP, at the same time, from the same autonomous system. No amount of storage isolation touches this, and it is the single strongest join available — it requires no scripting, no consent, and no cleverness, because the address is inherent to the request rather than something the browser volunteers.
It is also the join that survives the longest. Storage identifiers can be cleared, and a determined user does clear them. An address is logged in the ordinary course of serving a page, retained for entirely mundane operational reasons, and available for correlation long after anyone remembers collecting it.
The second is the fingerprint. A browser profile changes what is stored, not what is measured. Screen resolution, GPU and driver strings through WebGL, canvas and audio rendering differences, font enumeration, hardware concurrency, platform, and timezone are properties of the machine, and they are identical across every profile running on it. Two profiles on the same laptop produce the same fingerprint, which is why using a separate profile and using a different device are not the same claim, even though they are frequently made as though they were.
What makes hardware fingerprints effective is not that any one value is rare but that the combination is. Plenty of people have your screen resolution. Far fewer have it alongside your exact GPU string, your font set, and your timezone. And unlike a cookie, none of it can be cleared, because none of it was ever stored — it is recomputed from the machine every time it is asked for.
The third is timing and behaviour. Profiles used from one machine tend to be active in one waking pattern, in one timezone, with recognisable typing and scrolling characteristics. Two accounts that are never active at the same moment but are always active in the same eight-hour window, with the same weekly rhythm and the same gaps on the same holidays, are describing one person's calendar. That is weaker evidence than an IP match taken alone, but it accumulates quietly and it is the kind of thing that promotes a maybe into a probably.
The fourth is you. Identities get linked because the same recovery email was used, the same phone number was reused for verification, the same password appeared in a breach against two accounts, a real postal code was typed into a signup form out of habit, or the same payment card was used twice. Operational leaks are by a wide margin the most common way compartments actually get joined together, and no technical control prevents any of them. They are also the ones that hold up as evidence, because they are not statistical.
Persona Kit is built around the assumption that the storage layer is the easy part. Sessions run in an isolated browser — on your own Steel Browser deployment — rather than as a profile on your machine, and their cookies and storage are saved against the persona when the session ends and restored the next time it launches. That gets you two things at once: a persona stays signed in without ever sharing state, and no state accumulates on your own device to be correlated later.
Each persona carries its own device profile, so what is measured differs between personas rather than being your hardware reported repeatedly under different names. Traffic leaves through the residential proxy you assign, so two personas do not have to share your address or your ASN. And the credential vault and the per-persona inbox exist so that the fourth category — reusing an email, reusing a phone number, reusing a password — stops depending on you remembering which identity owned what, which is a thing nobody reliably does past about the fifth identity.
It is worth naming what remains. Behavioural similarity is still yours, because you are still the person driving. A persona used only during your working hours has your schedule. And nothing here protects an identity you personally connect to yourself by typing something you should not have — which is why the most valuable habit is deciding, before a persona exists, what it is allowed to know about you.
None of that is an argument against separate profiles. It is an argument against stopping there, and against the specific comfortable belief that because the visible identifiers are gone, the invisible ones are too.
Deep Dive: How Session Isolation Actually Works
Isolation is the easy half. The harder requirement is persistence — an identity that starts empty every time is its own kind of signal.
The State of Browser Fingerprinting in 2026
Three layers now do the work: passive network signals, active browser measurement, and behaviour. The counterintuitive part is that fighting them with randomness makes you easier to find.
An Identity Fails on Its Contradictions, Not Its Gaps
A missing middle name costs you nothing. A postal code that does not exist in the city above it costs you the account. How the details have to agree.