Browser profiles and isolation: what separating accounts really means
"Isolation" is the word everyone uses for keeping browser identities apart, and it covers several different things. This article separates them, because the one that is easy is not the one that matters.
Storage isolation
A browser profile has its own cookies, local storage, cache, history, saved passwords and extensions. Two profiles cannot see each other's cookies, so a site cannot connect them through storage. Every mainstream browser supports multiple profiles, and this level of isolation is solved. If this were all a site could see, keeping accounts separate would be a matter of clicking "new profile".
Network isolation
Two profiles that use the same address arrive from the same place. A site that sees two accounts from one residential address at the same time has learned something, and if the time zone and language match too, it has learned more. Network isolation means each profile has its own route, usually a proxy, and that the route carries everything: HTTP, WebRTC and, where possible, DNS. A profile whose proxy covers HTTP only is isolated on paper and connected in practice.
Fingerprint isolation
This is the hard one. Two profiles on the same machine with the same browser build produce the same canvas hash, the same audio hash, the same renderer string, the same thread count, the same screen geometry and the same font list. From a site's point of view they are one machine with two cookie jars. Making them look like two machines means the browser has to report different values for those properties, consistently, per profile.
Consistency is where this usually fails. The values have to describe a machine that exists: an operating system, a GPU that ships with it, a screen size and pixel ratio that go together, a user agent, Client Hints and navigator.platform that agree, and fonts that belong to that operating system. They have to stay the same across visits, because a fingerprint that changes every day is itself a signal. And they have to survive the comparisons sites make between sources: the user agent against the renderer, the time zone against the address, the WebRTC candidate against the request.
What "hiding" gets wrong
Blocking everything is not isolation; it is a different fingerprint. A browser that returns "unavailable" for canvas, audio, WebGL and WebRTC looks like a privacy tool, which is a small and recognisable group. The goal for a working profile is the opposite: to look like one ordinary, boring machine, fully readable, whose signals all agree. The success condition is not that a diagnostic shows nothing, but that it shows a plausible machine and no mismatches.
How to check a profile
Open a diagnostic in the profile and read it the way a site would. Does the renderer match the operating system? Does the time zone match the address? Does WebRTC expose only the proxy's address, or none? Reload: do the hashes stay the same? Then open a second profile and confirm the values differ from the first. A page like PowerScan shows these side by side, flags the comparisons that differ, and stores nothing, so the check is repeatable and leaves no trace.
A note on what this site does not claim
PowerScan does not score authenticity, detect proxies, or decide whether a browser is a bot. Those judgements need data a page script does not have, and showing a number for them would be guessing. What it does is read the same signals a site reads and point out where they disagree. That is the part you can act on.