Fingerprint Checkers Explained: Reading a Profile Scan Report

GetAntik editorial team · October 26, 2026 · 10 min read

How to read BrowserLeaks, CreepJS, Pixelscan and AmIUnique results, spot real fingerprint mismatches, and avoid chasing a meaningless 100% score.

Why check a fingerprint at all if the browser is already "antidetect"

An antidetect browser replaces the set of parameters a site uses to tell one visitor from another: OS and browser version, screen resolution, number of CPU cores, canvas and WebGL noise, the font list, time zone, language. But swapping these values doesn't automatically make the combination believable. You can set Windows 11 with a gaming-grade GPU and still leave a time zone from an old profile that doesn't match the proxy's IP. To a detection script, that's not "an ordinary user" — it's a suspicious combination, and the profile gets flagged for manual review or a temporary limit before you've done anything with the account.

Fingerprint-checking services are built on the same logic antifraud systems use on major platforms, just exposed publicly for anyone to run. They show exactly what a site sees when your browser connects. Learning to read their reports lets you catch inconsistencies before a profile ever touches a real account, instead of finding out after a ban.

What detectors actually measure

Different services cover different layers, and none gives the full picture alone.

BrowserLeaks is a set of separate tests: canvas, WebGL, audio fingerprint, fonts, WebRTC IP leaks, time zone, cookies. It's useful because you can check one parameter at a time instead of parsing a combined verdict.

CreepJS is a more aggressive test that tries to catch mismatches between what a browser claims about itself and how it actually behaves at a lower level. It compares, for instance, what navigator reports against what low-level APIs actually return. CreepJS is the one most likely to show a "trust score" and flag spoofed values as suspicious rather than just logging them.

Pixelscan and iphey work closer to how marketplace and ad-platform antifraud systems think: they give a combined "looks human / looks like a bot" verdict and separately show geolocation consistency — whether time zone, system language, and the IP's country line up.

AmIUnique doesn't score "human vs. bot" — it measures how unique your parameter combination is relative to its whole visitor database. It's useful for spotting whether a profile looks unusually rare (say, an odd screen resolution paired with an atypical font set), where the rarity itself becomes a marker.

For day-to-day work, two or three services from different categories are enough: one that checks individual parameters (BrowserLeaks), one with an overall verdict plus geo-consistency (Pixelscan or iphey), and CreepJS for catching logical contradictions.

Reading the score, not just the color

The biggest mistake is treating a service's single score as a binary "will get banned / won't get banned" answer. It isn't that.

Human/bot percentage is the service's own heuristic, not a rule any specific platform follows. An 85% "human" score on Pixelscan tells you nothing about how Meta Ads' antifraud will actually weigh the same profile — platforms use their own weights and thresholds, and none of them publish those numbers.

CreepJS trust score is more useful read section by section than as a final number. If the overall score is low but the only reason is a rare-but-real font, that's not a problem. If the reason is a contradiction between the declared User-Agent and the actual render engine version, that's a real signal — somewhere in the spoofing chain, something is out of sync.

A "spoofed" label is not a failure. Every antidetect browser spoofs something — that's its job. The question is whether the spoofing is detectable as spoofing, i.e., whether the result looks organic or reveals the mechanism used to produce it (for example, canvas noise with a visible pixel-level pattern).

AmIUnique's uniqueness percentage should be read with common sense: 1 in 50,000 for a browser+OS combination is normal; 1 in 2,000,000 for a single parameter is worth checking — something exotic may have been set without any real need.

Checklist: what to verify before the first account login

1. IP, time zone, and language match. A proxy in Germany with a time zone and language left over from a US setup is the single most common and most obvious mistake. Any antifraud system catches it within the first second of a session.
2. No real-IP leak via WebRTC. Checked separately on BrowserLeaks. If a profile leaks the real IP instead of the proxy's, the whole point of the test collapses — nothing else matters after that.
3. Hardware that's plausible for the declared OS. Eight CPU cores and eight gigabytes of VRAM on an "old laptop running Windows 10" isn't wrong by itself, but it's a combination that looks hand-assembled rather than pulled from a real device. It's safer to pick parameters that show up in large numbers in the wild — mid-range configurations, not top-tier or bare-minimum ones.
4. Browser version matches a current release. A Chrome build six months out of date isn't critical for fraud detection, but it raises the odds a site will demand an update or show an urlbar warning that breaks automation.
5. Font list without obvious gaps. A list under 10–15 fonts reads on its own as a sign of a virtual machine or a minimal environment without a real OS behind it.
6. Canvas and WebGL are stable but not identical across page reloads. Getting a different value on every single reload is itself a pattern used to spot low-quality noise generators — a real device's fingerprint stays stable within one session.

Table: what to focus on in each service

Common testing mistakes

Testing in a regular tab instead of inside the profile. Sounds obvious, but with enough profiles running, someone on the team eventually opens a checker in a background window with no proxy attached and panics over a result that has nothing to do with the real setup.

Chasing 100%. A perfectly sterile fingerprint with zero "suspicious" flags sometimes looks more artificial than a slightly imperfect but genuine one. Real users don't max out detectors — they have rare fonts, unusual resolutions, outdated plugins too.

Testing once and never after a proxy change. A good antidetect browser adjusts the fingerprint to match the proxy's IP automatically — time zone, language, geolocation taken from the exit node. But if the proxy is swapped manually or via rotation and the profile isn't restarted, the mismatch can persist until the next session start. The logic behind rotation, and when it's actually needed, is worth understanding on its own — it's covered in detail in the IP rotation strategy guide.

Mixing up what a VPN does and what an antidetect browser does. A VPN only changes the IP and, sometimes, the system's default time zone — it doesn't touch canvas, WebGL, fonts, or the dozens of other parameters a site uses to build a fingerprint independent of the network address. If this causes confusion on a team, it's worth checking the breakdown of VPN vs. antidetect browser, which lays out what each layer actually protects.

Trusting a single service. Each detector is built around its own set of checks. A profile that sails through BrowserLeaks can still get a low trust score in CreepJS — precisely because of contradictions BrowserLeaks isn't designed to catch.

Where this saves a team real time, not just theory

With dozens or hundreds of profiles, manually checking every single one against three services before every launch doesn't scale. It's more practical to build the check into profile creation rather than repeating it by hand every time:

• set parameters within realistic ranges (resolution, OS, browser) when creating a profile, instead of assigning random exotic values;
• tie time zone, language, and geolocation to the proxy's exit IP automatically, so it doesn't depend on someone remembering to set it;
• keep ready "proxy + parameter set" combinations as templates for recurring tasks instead of rebuilding a fingerprint from scratch for every new account — covered in more detail in the guide to profile templates for fast account setup;
• selectively run new profiles through fingerprint checkers before the first login to paid or long-lived accounts, rather than for every test account.

In GetAntik, profile fingerprint settings — OS, browser, screen, GPU, canvas/WebGL/audio noise, fonts — are configured at profile creation and tied to the proxy the browser pulls time zone, language, and geolocation from, based on the exit IP. This removes the most common cause of failed fingerprint checks — a mismatch between the network address and system settings, which otherwise has to be caught manually on every single profile.

When checking actually matters

Not every profile needs a three-service run before launch. It's worth checking:

• new profiles going into paid ad accounts, where a mistake means a frozen budget;
• profiles for long-lived accounts (marketplaces, banking and financial services), where regaining access after a ban takes weeks;
• profiles after a device migration or restoration from backup — post-migration verification is covered in the guide on switching antidetect browsers without losing accounts;
• profiles for work where separating identities and keeping contexts clean is the entire point, such as investigative work — this case is covered in detail in the article on OSINT investigations and identity separation with an antidetect browser.

For routine internal tasks (daily posting, working with already-warmed accounts), a single check at profile creation is enough, with a re-check only when the proxy changes or parameters were manually edited after an incident.

FAQ

Does a profile need to score 100% on every service before launch? No. A reasonable goal is the absence of obvious contradictions (IP vs. time zone, WebRTC leaks, browser version), not a maximum "humanness" score. A perfect result across every test at once is rare even for real users.

Do fingerprint checkers show exactly what a real platform sees? No. Every platform runs its own antifraud system with its own weights and thresholds, none of which are published. Public checkers give an approximate picture and are good at catching blatant setup mistakes, but they don't guarantee how a specific site will behave.

How often should an already-working profile be re-checked? After a proxy change, after moving to a different device, after manually editing fingerprint parameters, or after a long period of inactivity. Otherwise, continuously re-checking working profiles isn't necessary.

Can a profile's fingerprint be checked without logging into a real social media or ad account? Yes. Fingerprint checkers are just regular sites opened inside the profile. Checking doesn't require logging into the target account and leaves no trace on the platform itself.

What should I do if CreepJS flags several items as "lied" at once? First check the basics — time zone, language, and IP country alignment — then browser version and User-Agent. If there are many mismatches and they're systemic, the problem is likely in the profile's settings themselves rather than a coincidence, and it's better to rebuild the profile from scratch than to patch it piece by piece.

fingerprint testingantidetect browserproxy setupmulti-accountingbrowser profiles