What makes a profile look like its own device
Every value a profile sets comes from one of 25 real device models, so those values agree. A few signals still come from your own machine; they’re listed at the end of this page. This describes desktop 3.5.8, out for Windows; Linux is on 3.5.6 and macOS on 3.5.5. On 3.5.5? Update.
Coherent, not random
A fingerprint fails when its parts contradict each other, such as a macOS user agent with a Direct3D WebGL renderer, or 32 CPU cores on a phone screen. Each profile is built from one catalogue entry whose numbers come from the real hardware: 9 Windows PCs, 7 Macs, 3 Linux machines and 6 Android phones. A Pixel 8 reports 9 cores because its Tensor G3 has 9.
Canvas noise, seeded per profile
Seeded noise changes a few rendered canvas pixels without breaking the image, OffscreenCanvas included. Same profile, same canvas hash on every launch; a different profile, a different hash.
WebGL vendor and renderer
UNMASKED_VENDOR_WEBGL and UNMASKED_RENDERER_WEBGL report the device model’s GPU, and readPixels output carries the profile’s noise. Shader precision, MAX_TEXTURE_SIZE and the extension list are not changed: they come from your own graphics card.
Audio noise
Seeded noise is added to OfflineAudioContext renders, AudioBuffer.getChannelData and AnalyserNode reads. It is fixed per profile, so reading the same audio twice returns the same numbers; a value that changes on every read is how a randomiser gets caught.
Font availability
document.fonts.check answers from the device model’s operating system, so an Android profile doesn’t claim Calibri. Probes that measure rendered text still see the fonts installed on your machine.
CPU, memory and screen
navigator.hardwareConcurrency, navigator.deviceMemory, screen size and pixel ratio come from the device model: the CPU’s real thread count, memory rounded the way Chrome rounds it, and the panel’s pixels divided by its pixel ratio.
Client hints
Sec-CH-UA-Platform says “Android” when navigator.platform says “Linux armv8l”, because both come from the same entry. The Chrome version in the user agent and the hints is the version of the Chrome actually running the profile.
Any HTTP, HTTPS, SOCKS4 or SOCKS5 proxy
We don’t sell proxies, so there’s nothing to meter. Use the residential, mobile or datacenter proxies you already have.
One proxy per profile
A username and password work with HTTP and HTTPS proxies. Chrome can’t send a password to a SOCKS proxy, so for SOCKS use one that allows your IP. The proxy test shows the exit IP, country and latency; from 3.5.8 it also finds the protocol the proxy speaks and tells a wrong password, used-up traffic and an unreachable port apart. From 3.5.8, a profile whose proxy is switched on but can’t be used doesn’t launch, rather than browsing from your own IP.
The timezone you set
Give a profile any IANA timezone, or tell it to use this computer's. From 3.5.8 it can also match its proxy: the zone of the proxy’s exit IP is looked up at each launch, and if that fails the profile doesn’t launch. The zone is applied inside the browser engine, so the clock, Intl formatting and daylight saving all agree. The health check warns when a profile's timezone and its proxy's country do not.
WebRTC: relay-only, or off
Altered allows only relayed WebRTC connections and hides your own addresses. Disabled, the default for new profiles, removes WebRTC altogether: that closes the same leak but is itself detectable, because every real Chrome has it. We recommend Altered. Real leaves WebRTC alone and can leak your IP.
Your profiles stay on your machine
Each profile is its own Chrome user-data directory on your disk, with its own cookies, session tokens, cache and storage. Nothing is uploaded unless you turn on encrypted sync. XDLogin doesn’t encrypt these folders itself, so protect them like any other files in your user account.
Separate storage per profile
A captcha, an expired session or a ban on one profile never touches another profile’s cookies, cache or storage.
Encrypted cloud sync (Pro and above)
Optional, and off until you turn it on. Each profile is sealed with AES-256-GCM on your device before upload, using a passphrase that never leaves your machines; the server stores only ciphertext.
Local API, CDP and MCP
Every profile exposes a Chrome DevTools endpoint on 127.0.0.1. Attach Puppeteer or Playwright directly, or Selenium through ChromeDriver. A local REST API launches and stops profiles, and an MCP server lets an AI agent do the same; from 3.5.8 the agent can also read a page and click, type and scroll in it. All of it is on every plan, free included.
The phone app, and the gaps we publish
Android beta
A separate app for your own phone, sideloaded as an APK. Since 1.3.0-beta.1 it keeps up to four profiles open at once, each in its own process with its own proxy, timezone, cookies and storage (Android 9 and newer; one at a time on Android 8). Android System WebView adds an X-Requested-With header naming the app to every request, and we haven’t been able to remove it. Download and details.
What a profile can’t change yet
- The TLS handshake: it is your Chrome’s, and the same for every profile on this computer.
- WebGL limits, shader precision and extensions: they are your graphics card’s.
- Font measurements: text is still drawn by your machine.
- Web Workers built from in-page code, and service workers.
- On Edge or Brave, the client hints still say Google Chrome.
The full list, and our own probe results, are on the test results page.