Home › Tools › Fingerprint Test
A browser fingerprint is the combination of signals your browser exposes to every site automatically — user agent, screen, timezone, language, hardware, rendering behaviour. Individually they are common; combined they are often unique enough to recognise you across sessions without any cookie.
That is the part people miss: clearing cookies and using incognito does not change your fingerprint. The signals come from the device and the browser build, not from stored data.
What does each signal actually reveal?
Roughly three groups: declared identity (user agent, platform, languages), hardware and environment (screen, CPU cores, memory, timezone), and rendering behaviour (canvas, WebGL, audio). The third group is the hardest to fake convincingly, which is why detection systems weigh it heavily.
Declared identity
User agent, platform, languages. Trivially spoofable — and that is the problem: a spoofed UA that contradicts the other groups is a louder signal than no spoofing at all.
Hardware & environment
Screen size, colour depth, CPU cores, device memory, timezone. Cheap to read, and highly effective at contradicting a claimed location.
Rendering behaviour
Canvas and WebGL hashes depend on GPU, drivers and font stack. Very stable per device, and hard to fake without producing an impossible combination.
WebRTC
Can expose local network addresses even behind a VPN. A classic source of “my proxy said Germany but the browser said otherwise”.
Why does this matter for ad accounts?
Because platforms use the same signals to decide whether many accounts belong to one operator, and whether your claimed location is real. The usual failure is not one wrong value — it is contradiction between values: a US proxy with an Asian timezone, a mobile user agent on a desktop GPU, a fresh profile with an identical canvas hash to twenty others.
This is exactly why an anti-detect browser exists: to make each profile internally consistent, not merely different. Consistency is the hard part — randomising every field produces combinations that do not exist in the real world, and that is its own detectable pattern.
Note that this concerns your own accounts’ environment, which is a separate problem from filtering incoming visitors. Two different layers, both usually needed. Cloaking vs anti-detect browsers →
FAQ
Does incognito mode or clearing cookies change my fingerprint?
Barely. Private windows drop stored data, but the signals above come from your device and browser build, so most of them stay identical. That is precisely why fingerprinting is used for cross-session recognition where cookies fail.
Does a VPN hide my fingerprint?
No. A VPN changes the IP address your traffic appears to come from. It does not change your timezone, language, screen, GPU or canvas output. If those contradict the VPN’s location, the contradiction itself becomes the signal.
Should I randomise every fingerprint value?
No — that usually makes things worse. Randomising each field independently produces device profiles that do not exist in reality (impossible GPU/OS pairings, mismatched screen and platform). Consistency beats uniqueness: a plausible, stable, internally coherent profile attracts far less attention than a randomised one.
Do you store the results of this test?
No. Everything runs client-side in your browser. There is no upload, no logging, no database. You can verify it: open your browser’s network tab and reload — no request carries the results out.
Why does a cloaking provider publish this tool?
Because these signals are exactly what any traffic-filtering system reads. Understanding what your browser broadcasts helps you reason about why some visitors get classified the way they do. The tool uses only standard public browser APIs — it is not our detection engine and does not reflect how we classify traffic.
Filtering visitors is the other half
Fingerprints describe who is knocking. Deciding what they see is a separate layer.
How cloaking works →