How FingerprintJS Pro Identifies Browsers: A Walkthrough for Site Owners

FingerprintJS Pro is a commercial service that sites embed to recognise returning visitors and to score the risk that a visit is automated. Banks, e-commerce stores and ad platforms use this kind of service, and it is worth understanding if you run a site that is exposed to fraud or scraping, or if you simply want to know what a page can learn about your browser.

This walkthrough explains what the product reports, how to read each signal, and how a site owner or QA team can test their own integration with separate test profiles. It is education from the defender's side. It does not teach how to get a browser past anyone else's defences, and JustBrowser is not sold for that.

What you will learn

1. What a visitor identifier is and why it is stable across cookie clears
2. How to read the bot-risk result and its signals
3. What the private-browsing signal looks at
4. How to use separate test profiles to check your own integration
5. Why a single signal never tells the whole story

Prerequisites

• A site you own or operate, with FingerprintJS Pro integrated (or a vendor demo page for learning)
• Basic familiarity with browser fingerprinting: canvas, WebGL and audio output, fonts and screen metrics, plus network-level signals such as TLS (our TLS and JA4 fingerprint guide covers the network side)
• A multi-account browser such as JustBrowser to run several clean, separate test profiles
• About 20 minutes

The vendor's public demo summarises results in readable cards rather than raw API responses. That is enough to learn how the signals are presented. For your own site, the API response carries more detail.

Step 1: Understand the visitor identifier

The visitor identifier is the product's alternative to a cookie. It is derived from browser and device characteristics, including canvas and audio output, fonts and hardware details, combined with server-side matching. Because it does not rely on stored data, it can survive cookie clears.

For a site owner, three behaviours are worth checking in your own test runs:

• Same profile, same identifier across sessions. This is the expected result. It means the profile keeps a stable identity.
• Same profile, different identifier. Something in the profile or network is changing between sessions, for example a proxy that moves the apparent location or a setting that is regenerated on each launch. Investigate before drawing conclusions.
• Different profiles, different identifiers. This confirms that your test profiles really are separate visitors. If two profiles share an identifier, they share too much, and your tests are not testing two visitors.

This is the practical value of a multi-account browser for a tester: each profile is its own browser with its own cookies, storage, proxy and identity parameters, so you can model several distinct visitors on one machine and check how your integration treats them.

Step 2: Read the bot-risk result

The bot-risk result classifies a visit and gives the reasons behind the classification. Vendors describe the exact categories in their own documentation, so check it before relying on any threshold. As a reading guide:

• A clean result means no automation indicators were found for that visit.
• A borderline result means some indicators are present but not conclusive. On your own site, decide in advance what action you want here, for example a lightweight challenge rather than a block.
• A high-risk result means the visit looks automated. On your own site, this is where your block or challenge rule should fire.

The point of testing your own integration is to confirm that these results reach your application and that your rules respond the way you intended. A scoring service that your backend ignores protects nothing.

Remember that the classification is the vendor's judgement, not a fact about intent. Legitimate visitors, such as assistive technology users, privacy-minded users and monitoring tools you run yourself, can look unusual. Design the response to a borderline result with false positives in mind.

Step 3: Know the common signal categories

Vendors do not publish everything their models use, but the categories you will see discussed are:

Automation framework indicators. Signs that a browser is being driven by Selenium, Playwright, Puppeteer or a WebDriver connection. If you run your own automated tests against your own site, expect these to be reported, and decide how your production rules should treat your own test traffic, for example by allow-listing your test infrastructure.

Headless indicators. A headless session has no real window, so screen and viewport follow headless defaults. A tester should run headed sessions when the aim is to reproduce what a person sees.

Behavioural anomalies. Timing and interaction patterns that differ from typical human use. These are model-driven and not fully explained by the vendor, which is a reason to treat them as a signal to weigh, not a rule to trust blindly.

Environment inconsistencies. Cases where the claimed browser, operating system, fonts or hardware do not agree with each other. A profile whose identity parameters are generated consistently avoids creating these by accident, which is useful when you want a clean baseline for a test.

Network context. IP reputation, hosting-provider ranges and location versus timezone. These come from outside the browser, so a test that changes only the browser profile will not change them.

Step 4: The private-browsing signal

FingerprintJS Pro can report whether a visit appears to come from a private window, using behaviours that differ between normal and private modes, such as storage quota and file-system availability.

For a site owner this is a way to understand how visitors browse and, for fraud rules, to treat private-window sign-ups with a little more care. It is not a verdict. Plenty of ordinary visitors use private windows for ordinary reasons.

When you test, run your profiles in normal mode so that the private-browsing signal reads as expected, and run one deliberate private-window visit so you can see how your own system records it.

Step 5: Test your own integration with separate profiles

A short, repeatable test plan for your own site:

1. Create three named test profiles. For example a plain desktop visitor, a visitor on a different operating system and a visitor routed through a proxy in another region. Each profile keeps its own cookies, storage, proxy and identity parameters.
2. Visit your site with each profile twice. Record the visitor identifier and the bot-risk result for every visit.
3. Check that the identifier is stable per profile and distinct between profiles. This confirms your integration, and your test profiles, behave as intended.
4. Drive one profile with automation. Connect Playwright, Puppeteer or Selenium to a JustBrowser profile through its local REST API and CDP (see the Playwright and Puppeteer REST API guide), and confirm that your rules treat automated traffic the way you decided. Use the profile's own browser context rather than creating a new one, and end the session through the API when you finish.
5. Check your backend, not just the dashboard. Confirm that your server receives the result and that the block, challenge or allow action actually runs.
6. Record the results. Keep them next to the date and the profile settings so you can compare after any change.

This plan tests your own defences on your own property. It is not a way to measure how another site's defences would treat a browser.

Step 6: Common problems in your own testing

The identifier changes between sessions on one profile

Likely cause: something that should be stable is changing, such as a proxy that moves the apparent location between runs or a setting regenerated per launch.

What to do: keep the proxy and locale fixed for a given test profile, and compare runs one change at a time.

Two profiles report the same identifier

Likely cause: the profiles share too many characteristics, or they were cloned from one another without changes.

What to do: create the second profile from scratch with its own identity parameters, and re-run.

The bot-risk result is higher than expected for your own automation

Likely cause: your test harness exposes automation indicators, which is exactly what the service is meant to report.

What to do: decide whether your production rules should allow your known test infrastructure, and implement that on your side, for example with an allow-list.

Results look right in the dashboard but nothing happens on the site

Likely cause: the integration reports results, but your backend never reads them or never acts on them.

What to do: trace one request end to end, from the browser call to the server decision.

A real visitor was challenged

Likely cause: a false positive. Privacy tools, unusual networks and assistive technology can all look atypical.

What to do: give challenged visitors a clear path to proceed, such as a lightweight check or a support contact, rather than a silent block.

Step 7: Put it together

A sensible routine for a site owner:

1. Check IP and network context for your test setup, so network noise does not confuse the results.
2. Run your named test profiles against your own site and record identifiers and results.
3. Compare against the previous run and investigate any change.
4. Re-test after every change to your integration, CDN or proxy setup, and on a regular schedule, because vendors update their models.

For a wider look at how browser fingerprints are built and read, see BrowserScan, IPHey and Pixelscan checks explained. If bot traffic is hitting paid campaigns on your site, ClickzProtect covers that side, and JustAnalytics helps you follow what real visitors do without adding more fingerprinting.

Frequently Asked Questions

What is the difference between FingerprintJS Pro and free fingerprint tools?

FingerprintJS Pro is a commercial visitor-identification and bot-detection service that sites integrate into their own pages. Free tools such as BrowserScan and Pixelscan show you what a page can read from a browser. Pro combines browser signals with server-side analysis and machine learning to produce a stable visitor identifier and a bot-risk result. They answer different questions.

Does FingerprintJS Pro detect private browsing?

It offers a dedicated private-browsing signal that looks at behaviours which differ between normal and private windows, such as storage quota and file-system availability. Site owners can use it to understand how visitors browse. Treat it as one signal among several rather than a verdict.

Why would a bot-risk result differ from what a free fingerprint tool shows?

Free tools mostly report what is readable from the browser at one moment. A commercial bot-detection result also draws on automation indicators, timing and server-side data. A browser can look internally consistent and still produce a different bot-risk result, which is why site owners test their own integration end to end.

How often should a site owner re-test its own bot defences?

Re-test after any change to the integration, after changes to your proxy or CDN setup, and on a regular schedule, because vendors update their models. Keep a small set of named test profiles so results are comparable from one run to the next.

---

Try JustBrowser

A multi-account browser for teams, on a custom Chromium engine with native C++ integration, not extension-based. Each profile is its own browser with its own cookies, storage, proxy and 40+ identity parameters. Local REST API + CDP for Playwright, Puppeteer, Selenium. $9.99/month or $99.99/year. 7-day free trial, card required — cancel any time in the seven days and you are not charged. Unlimited profiles.

Get started → · How it differs from Multilogin / GoLogin / AdsPower