FingerprintJS is an open-source library, separate from the paid Fingerprint product. What it collects, how accurate it is, and how it differs from CreepJS.
Search "fingerprintjs" and the results blur together two different things. One is an open-source JavaScript library you can add to any page for free: it runs entirely in the visitor's browser and returns a visitorId string. The other is Fingerprint, a paid commercial identification service sold by the same company, which adds server-side processing and advertises much higher accuracy. They share a name, a GitHub organization, and a general approach — combining many browser signals into one identifier — and not much else. This article is about the first one: what the open-source library actually reads, how it turns those readings into a visitorId, how accurate it really is, and how it compares with the other fingerprint testers this site already covers.
Key Takeaways
- The free, MIT-licensed FingerprintJS library and the paid Fingerprint product come from the same company but are not the same thing. The library runs entirely client-side, and its own README says its accuracy is "significantly lower" than the commercial version's.
- The library reads roughly 40 browser signals — canvas drawing, installed fonts, audio processing, WebGL renderer details, screen and hardware properties, timezone and language, display preferences, and more — and hashes them into one
visitorId. - A
visitorIdanswers "is this the same browser as last time?" That is a stability question, different from CreepJS's "is this browser lying about itself?" and Cover Your Tracks' "how rare is this combination?" - Because it doesn't depend on cookies or storage, the fingerprint survives private browsing and clearing browser data. It still changes when the underlying signals change — after a browser or graphics-driver update, for example, or in browsers that deliberately randomize fingerprinting surfaces.
- The README gives no accuracy percentage for the open-source library, so this article doesn't either. Treat any specific figure you see quoted for it with caution.
Two Things Named "FingerprintJS"
The confusion is baked into the project's history. The company, FingerprintJS Inc., started with the open-source library, later built a commercial product on the same idea, and now does business as Fingerprint. The library is still maintained and is still what you get from npm install @fingerprintjs/fingerprintjs — but most of the company's marketing, and much third-party writing about "FingerprintJS," describes capabilities of the paid product that the free library doesn't have.
The differences that matter if you're evaluating either one:
- Where it runs. The open-source library computes everything in the visitor's browser and hands the page a
visitorId. The commercial product also processes each request on the vendor's servers, where it can use signals a page script can't read on its own — the connecting IP address, for instance — and compare the visit against earlier ones. - What it costs. The library is free under the MIT license. The commercial product is a paid, usage-based API.
- What each claims. The README states plainly that because the library generates fingerprints inside the browser, its accuracy is significantly lower than the commercial version's. The vendor advertises much higher accuracy for the paid product precisely because of that server-side layer.
If you searched "fingerprintjs" looking for a free library you can host yourself, the open-source project is that. If you're evaluating fraud-prevention or bot-mitigation tooling for a business, you're really looking at the commercial product — and the two shouldn't be compared as if one were simply a rebranded copy of the other.
What the Open-Source Library Actually Reads
Strip away the branding and the library uses the same family of techniques covered elsewhere on this site: a fixed set of client-side signals, collected and hashed into one value. Its source code defines each signal as an "entropy source" — around 40 of them in the current version. Grouped by type:
- Canvas drawing. The hidden-drawing technique covered in Canvas Fingerprint Detection: How Websites Identify Your Device: the same text and shapes render with tiny pixel differences depending on GPU, driver, and font rendering, producing a stable hash without any cookie.
- WebGL. Basic WebGL parameters such as the reported vendor and renderer strings, plus the list of supported WebGL extensions.
- Audio. A short signal processed through the Web Audio API — the mechanism explained in Audio Fingerprinting: How AudioContext Identifies Your Device — along with the audio stack's reported base latency. The variation comes from the audio implementation and hardware, not from any setting a user chooses.
- Fonts. Which fonts are installed, plus how the default font families render. Both vary by operating system, language packs, and installed software.
- Screen and hardware. Screen resolution and color depth, the space the operating system reserves around the usable screen area (such as a taskbar or dock), CPU core count (
hardwareConcurrency), the approximate device-memory hint, and touch support. - Locale. Timezone, preferred languages, and the locale used for date and time formatting.
- Platform and browser. The reported platform and CPU architecture, the browser vendor, installed plugins, whether the built-in PDF viewer is enabled, and a few engine-specific checks such as Apple Pay availability.
- Preferences and environment. CSS media features such as color gamut, forced or inverted colors, contrast and reduced-motion preferences, and HDR support; whether cookies and storage APIs are available; which content blockers appear to be active; and small floating-point differences in
Mathfunctions.
None of these signals is unique to FingerprintJS — Browser Fingerprinting Explained: How to Protect Your Privacy covers the underlying techniques in general terms. What the library contributes is packaging: a maintained script that collects the whole set and turns it into one string, so a site doesn't have to build that collection logic itself.
From Signals to a visitorId
Calling the library's get() method returns four things: the visitorId; a confidence score describing how sure the library is about that identifier; the raw components it collected; and the fingerprinting algorithm version. The visitorId itself is a 128-bit hash — the library's x64hash128 function, a MurmurHash3 variant — of all the components serialized into a single string. Change any one component and the hash comes out completely different; there is no "almost the same" visitorId.
How Accurate Is It, Really?
The README makes two claims worth separating. First, a fingerprint doesn't depend on cookies or local storage, so it "stays the same in incognito/private mode and even when browser data is purged." That is the core reason sites use fingerprinting at all: clearing cookies doesn't reset it.
Second, the README says that because FingerprintJS generates fingerprints inside the browser, its accuracy is significantly lower than the commercial version's. It doesn't publish a percentage, and neither will this article.
Why lower? Two structural reasons follow directly from how the visitorId is built. This is our analysis, not a claim made by the project:
- Drift. The hash covers every component, so a change to any single signal produces a new
visitorId. A browser update can alter how text renders on a canvas; a graphics-driver update can shift canvas output or the WebGL renderer string; installing a font changes the font list. Browsers with anti-fingerprinting protections that deliberately add noise to canvas or audio output can return different values from one session or site to the next. A returning visitor whose signals shifted looks like a brand-new visitor. - Collisions. The reverse problem: devices of the same model, running the same OS version and browser build — a fleet of identically configured office laptops, or two iPhones of the same model on the same iOS version — can expose nearly identical signals and produce the same
visitorId, making different people look like one visitor.
A browser-only script has no way to correct either error by itself. A server-side system can weigh additional evidence, such as the network a visit comes from and the history of earlier visits — which is exactly the gap the commercial product is built to fill.
Where FingerprintJS Fits Among the Other Testers
FingerprintJS's visitorId answers one specific question: is this the same browser as before? That's a stability question, and it's worth being precise about how it differs from the other tools covered on this site, because the same browser can get three very different-sounding verdicts depending on which question is being asked:
- CreepJS asks is this browser telling the truth about itself? — a coherence check that cross-references trusted and untrusted signal sources for internal contradictions. A browser can look perfectly consistent by CreepJS's standard while still producing a highly stable, highly trackable
visitorId. - Cover Your Tracks asks how rare is this combination of signals? — a uniqueness question answered with information theory, unrelated to whether the signals are internally consistent or stable from one session to the next.
- FingerprintJS asks neither. It asks whether the same set of signals, hashed the same way, yields the same identifier again — a repeatability question that says nothing about how common the combination is or whether any individual signal looks tampered with.
Why Fingerprint Test Tools Disagree About You covers this pattern in general: uniqueness, coherence, and identity stability are three different measurements that often get reported under the same loose words "score" or "ID," and a tool built for one of them was never trying to answer the other two. If you've compared a visitorId-style result against a CreepJS trust score or a Cover Your Tracks anonymity figure and found them hard to reconcile, that's expected — they aren't answering the same question. BrowserLeaks Explained: Which Leaks Each Test Actually Covers rounds out the picture with a fourth shape these tools take: a suite that reports each surface separately instead of combining anything into a single figure.
Checking Your Own Signals
BrowserInsight's fingerprint check shows many of the same signal categories this library reads — canvas, WebGL, audio, fonts, screen, and navigator properties — laid out one by one, alongside consistency checks that flag when they contradict each other. It doesn't compute a competing visitorId. Instead, it shows you the raw surfaces a fingerprinting library would hash, so you can see which ones make your browser stand out. To watch drift happen, run the check, then update your browser or turn on its fingerprinting protection (if it has one) and run it again: a changed canvas, WebGL, or font value is exactly the kind of shift that would also produce a new visitorId.
Frequently Asked Questions
Is the open-source FingerprintJS library the same as the Fingerprint product?
No. They're built by the same company and share the general hash-based approach, but the open-source library runs entirely client-side and, per its own README, is significantly less accurate, while the paid Fingerprint product adds server-side processing the free library doesn't have.
Can I use the open-source library on a commercial site?
The library is published under the MIT license, which permits commercial use. Check the license file in the repository for the exact terms.
Does FingerprintJS collect or store data about me?
The open-source library itself is a script that runs in your browser and returns a visitorId. What happens to that identifier afterward — whether it's stored, and where — depends entirely on the site that deployed it, not on the library. Check the specific site's privacy policy rather than assuming anything about how a fingerprinting script's output is handled.
Why does my visitorId change between visits?
Because it's a hash of every signal the library reads, a change to any one of them produces a different ID. Browser updates, graphics-driver updates, newly installed fonts, and anti-fingerprinting features that randomize canvas or audio output are common causes. Opening a private window or clearing cookies, by contrast, isn't supposed to change it — the README says the fingerprint stays the same in both cases.
Is FingerprintJS more accurate than CreepJS or Cover Your Tracks?
That comparison doesn't quite make sense, because the three tools aren't measuring the same thing. FingerprintJS asks whether the same visitor produces the same identifier twice; CreepJS asks whether a browser's signals are internally consistent; Cover Your Tracks asks how rare the combination is. "More accurate" only means something when two tools are trying to answer the same question.
Recommended Reading
- Why Fingerprint Test Tools Disagree About You
- CreepJS Explained: How Fingerprint Lie-Detection Catches Spoofing
- BrowserLeaks Explained: Which Leaks Each Test Actually Covers
- Canvas Fingerprint Detection: How Websites Identify Your Device
- Audio Fingerprinting: How AudioContext Identifies Your Device
- Browser Fingerprinting Explained: How to Protect Your Privacy
