Browser fingerprint test — which trackable parameters do you expose?

Fingerprint detection isn't really about 'what your UA looks like' — it's about whether the identity you claim holds together. Risk systems rarely ban you because one value is rare; they ban combinations that contradict each other. The most commonly caught contradiction is timezone versus IP geolocation: your exit IP lands in Los Angeles (UTC-8), but JavaScript's Intl.DateTimeFormat().resolvedOptions().timeZone returns Asia/Shanghai. A 16-hour mismatch like that almost only happens when someone in China is on a US proxy — the single most frequent tell for proxy users.

The second contradiction sits between the UA string and the runtime environment. The UA says Windows NT 10.0 but navigator.platform returns MacIntel; or the UA claims Chrome on Android yet navigator.maxTouchPoints is 0 (no touchscreen) and the screen aspect ratio is a desktop one. Changing the UA in an anti-detect browser is easy; getting dozens of correlated low-level properties to line up is hard, and these 'changed the facade, not the structure' details are what leak.

The third is language versus region. Accept-Language and navigator.languages say en-US, but the IP is in Vietnam and the timezone is Asia/Ho_Chi_Minh — language/region/network disagreeing drags your trust score down too. IPOK lays parameters out across Network / Software / Hardware and marks each ✓ or 🚩 precisely so you can see at a glance which contradiction you're stuck on, instead of drowning in raw values.

Many people think fingerprint testing is about 'was I identified or not'. The deeper metric is 'how easily can you be singled out'. The concept that measures this is entropy: the more finely a parameter slices the population, the more information (bits) it carries. Screen resolution, GPU model, installed font list, timezone and language, combined, are often enough to compress you down to nearly one person among millions — exactly what the EFF's Panopticlick / Cover Your Tracks projects have demonstrated for years.

The irony is that the more you install plugins, tweak your UA, or use an obscure browser 'for privacy', the more unique and trackable you may become. A vanilla mainstream Chrome user disappears into the crowd; a browser with a mangled UA and a pile of anti-fingerprint plugins can have a combination so rare that you're the only one on the web — and it can re-identify you by that fingerprint even after cookies are cleared. That's the privacy paradox.

So the healthy goal of fingerprint testing is not 'change every value' but 'look like an unremarkable real machine'. IPOK's 0-100 anonymity score is weighted toward 'are there disguise tells / automation traces', not toward rewarding exotic values — because when fighting risk controls, blending in is far safer than standing out.

People doing multi-account or anti-association work use anti-detect browsers (AdsPower, Multilogin, BitBrowser, etc.) to give each account its own fingerprint. But 'I installed an anti-detect browser' doesn't equal 'my fingerprint is clean', and there are recurring failure modes. The first is WebGL/Canvas rendering tells: the GPU vendor/renderer returns SwiftShader, llvmpipe or Mesa — software-rendering markers that strongly imply a headless browser, VM or server. Real desktops/laptops almost always report hardware GPUs from NVIDIA/AMD/Intel/Apple.

The second is automation-framework residue. When a browser is driven by Selenium/Puppeteer/Playwright, navigator.webdriver is true and injected variables like cdc_ may hang off window. Even with a stealth plugin patching some of it, function toString output, prototype-chain anomalies and a missing chrome object can still be caught by advanced detection. The third is an inconsistent profile: a fingerprint dialed up to look 'high-end' (top-tier GPU + 64GB RAM) paired with a cheap datacenter IP — hardware and network don't match in style, which is more suspicious, not less.

The right move is to re-test with a neutral checker after editing the fingerprint: confirm the timezone follows the proxy, the UA matches the platform, there's no webdriver, the GPU is hardware-rendered, and hardware matches the IP's profile. IPOK reads every parameter locally, never uploads, and deliberately doesn't generate canvas/audio hashes — making it suited to that 'check yourself in the mirror before you leave' step for a configured environment.

If you're a privacy-conscious regular user: focus on which high-entropy parameters you expose, and on the illusion of 'I changed IP but not identity'. After connecting a VPN/proxy, confirm your timezone and language aren't still leaking your real location — many VPNs only change the IP and leave the browser timezone alone, so the IP is in the US while the timezone is still Asia/Shanghai, which is raising your own hand. Run this alongside the site's WebRTC-leak and DNS-leak checks to cover both the network layer and the browser layer.

If you're in cross-border e-commerce / multi-account ops: treat this page as a pre-launch checkup for each browser environment. For every account, confirm the three fingerprint groups are self-consistent, there are no automation traces, and the hardware matches the proxy's profile before logging into the target platform. This meaningfully cuts losses from fingerprint-linked failures like 'bulk sign-ups banned instantly' or 'aged accounts suddenly dropping en masse'.

If you're a developer / in anti-fraud: use this page as a sample of the adversary's view. You can see directly which signals a client can read and which combinations most easily expose a disguise, then design matching consistency checks in your own risk logic (timezone vs IP, UA vs platform, webdriver, software-rendered GPU, etc.). Note that IPOK is positioned as a self-audit tool — it shows your device's real parameters and does not generate a trackable fingerprint for you.