What is Fingerprint

Fingerprint is a software-as-a-service that identifies online devices and provides valuable information about them.
Fingerprint’s products do not involve biometrics or human fingerprint scanning.

Fingerprint's key feature is its ability to generate a unique ID, often referred to as a "device fingerprint", and permanently associate it with each device.

An example of such an ID, which appears as a string of characters, is xPFysGV25VxZcGQUxVIt.
You can see your own device ID by going to https://fingerprint.com/demo.

This identifier can be very useful, because once created, it’s impossible to erase and very hard to alter.

It’s often used in situations where online visitors don’t want to be identified, such as fraud detection or account security.

Additionally, it can enhance user experience by reducing the need for account verification or captcha completion.

Fingerprint offers two products: Identification and Smart Signals. This guide focuses on Identification.

Before we dive deeper into usage examples, we need to clarify several important terms and get a few potential misconceptions out of the way.

Terms and concepts

What is the difference between Fingerprint Identification and FingerprintJS?

FingerprintJS is a JavaScript library that gathers browser attributes and JavaScript objects, then computes a hash from this data. The library is fast, doesn’t need a backend, but has two shortcomings:

1. It produces identical fingerprints on identical devices. The most notable example is Safari on iOS on the same iPhone model. If you run FingerprintJS on two iPhone 15s, you'll get identical fingerprints. This is problematic because it prevents unique device identification, causing many iPhones to have the same fingerprint.
2. The fingerprint generated by FingerprintJS changes whenever any underlying attribute or data point changes. For instance, if you change your time zone by traveling from Illinois to Indiana, your fingerprint will also change. The same applies to OS updates (which change your OS version), browser updates, and other modifications.

The source code for the FingerprintJS library is available on GitHub. The current version is v4, licensed under the BSL license. Previous versions (v3 and v2) were under the less restrictive MIT license, but they are incompatible with modern browsers like Safari 17. Read more about our license change in this blog post.

Our flagship commercial product, Fingerprint Identification, offers several improvements over FingerprintJS. It's a client-server software that uses a client-side SDK and a backend to generate fingerprints. The client-side JavaScript SDK is not the same product as FingerprintJS library. It is an advanced script that collects more data and sends it to the Fingerprint backend for fingerprint generation.

Fingerprint Identification not only supports browsers, but also mobile devices. It comes with server API and webhook support, and integrates with most cloud and CDN products, simplifying integration into your stack. It provides highly accurate identification and can distinguish between identical physical devices (e.g., two identical iPhone 15s).

Another difference is that the identifiers generated by Fingerprint Identification are stable for months and will not change if the device attributes change or if the device software is updated.

We offer both Fingerprint Identification and FingerprintJS v4 library. Fingerprint Identification doesn’t share the weaknesses of FingerprintJS and provides more value for production applications.

The legacy FingerprintJS v3 version is free to use, but lacks support for Safari 17.

Fingerprints vs VisitorIDs

Understanding the difference between FingerprintJS and Fingerprint Identification, let's now discuss the IDs they generate.

FingerprintJS generates a browser hash, which we refer to as a "fingerprint".

On the other hand, Fingerprint Identification follows a different process for ID generation. It produces a more stable and precise identifier, known as a "VisitorID". This identifier doesn't rely on browser attribute hashing, but employs advanced data matching techniques, which include statistical ID generation and machine learning. We typically don't use the term "fingerprints" for identifiers produced by Fingerprint Identification, instead we use "VisitorIDs".

Although this guide might use both terms interchangeably for simplicity, it's important to note that Fingerprint Identification generates VisitorIDs, while FingerprintJS generates fingerprints.

Is Fingerprint GDPR compliant?

FingerprintJS is a stateless library and is GDPR compliant as it doesn't store data. In essence, FingerprintJS is a large JavaScript function that generates a hash from public browser attributes. Writing a function in JavaScript is GDPR compliant :). However, how you utilize the data generated by FingerprintJS could require obtaining users' consent. This topic is beyond the scope of this guide.

Fingerprint Identification is also GDPR compliant, but it’s important to dive into the details to understand why.

Fingerprint identification is a SaaS product that is offered as a client-server API system.
GDPR typically designates two roles in online browsing experience: “data controllers” and “data processors”. A data controller is a website or a web application that may decide to collect data from website users, and store that data for further use. A data processor is a 3rd party service that accepts data from a data controller and stores it in its backend systems.

Examples of a data controller: eBay.com, wikipedia.com, YouTube.com.

Examples of a data processor: DigitalOcean, Amazon Web Services, Google Cloud.

Fingerprint Identification is a data processor, not a data controller. A website that uses Fingerprint Identification API is a data controller. For example dropbox.com uses Fingerprint identification to prevent account abuse and to improve the security of created accounts. Dropbox.com is a data controller and Fingerprint is a data processor.

As a data controller, Dropbox needs to be GDPR compliant and ensure the data that it collects is used correctly according to GDPR guidelines.

As a data processor, Fingerprints also needs to be GDPR compliant and ensure that the data it receives from data controllers is processed correctly, according to GDPR guidelines.

What obligations does Fingerprint have as a data processor?

Fingerprint must delete personal information that it received from a data controller upon request.

Fingerprint complies with this requirement and supports both programmatic and manual data deletion request types.

Now with fundamentals explained and misconceptions out of the way, let’s dive into three typical use cases when Fingerprint can be useful.

Fingerprint design patterns

How would you typically use a device fingerprint?

In this guide we’ll walk through several examples to give you more information to decide if Fingerprint Identification can be helpful in your situation.

We’ll start with three design patterns that are used across all identification use cases.

These patterns are:

1. Comparing fingerprints
2. Counting fingerprints associated with data
3. Counting data associated with a fingerprint

Comparing fingerprints

You generate a fingerprint before an important action and compare the fingerprint with the previous fingerprint for that user. If fingerprints match, the action is safe and you let the user continue. If fingerprints don’t match, it could mean two things:

1. The user is using a different device or a different browser.
2. Unauthorized access from an unknown device is attempted.

In this situation it’s a good idea to perform additional verification steps, which we’ll cover in a future section.

Counting fingerprints associated with data

This pattern is a more powerful version of the previous “comparing fingerprints” pattern.

Every time an important action happens in your application you generate a fingerprint.

For example when users are logging in, creating new accounts, or paying for items in their cart you would generate a fingerprint.

Once it’s generated, you add it to the collection of known fingerprints, associated with the current user.
If the collection of distinct fingerprints becomes too large (e.g. > 5), it means that too many devices are trying to perform an action on behalf of this user.

When too many devices are associated with one account, it may not be safe. In such cases, increase friction and request more information from the user.

You might ask for two-factor authentication (2FA) or even put the action on hold for review.

Too many fingerprints per account could also mean account sharing.

Counting data associated with a fingerprint

This involves counting the number of internal identifiers linked to a single fingerprint. This powerful pattern can address multiple use cases.

For example, for each signup attempt, you would generate a fingerprint and update your database with the number of accounts already associated with this fingerprint. If the number is too high (e.g. > 2), it indicates that this user is creating multiple accounts in your application.

It also can be used in other situations:

• Counting the number of refunds per fingerprint to prevent refund fraud.
• Counting the number of returned purchased items per fingerprint to avoid e-commerce return fraud.
• Counting the number of referrals, redeemed coupons, unrelated financial transactions, unrelated crypto operations and other things.

Use Cases

Fingerprint identification can support numerous use cases. All of them are built using the design patterns we previously discussed.

Below, we'll discuss three popular use cases. However, you can find more examples on our use cases page.

Reducing Login Friction

The pattern used here is comparing fingerprints.

To reduce login friction without reducing your accounts' security, use Fingerprint Identification. This method compares the visitorID from the previous login with the current login attempt visitorID. If they match, it's safe to authorize the login without requiring additional account verification.

By incorporating fingerprint comparison into the login process, you can decrease friction and enhance account security simultaneously.

Account takeover protection

The design pattern used here is counting fingerprints associated with data.

If you want to protect your accounts from a potential takeover, traditionally you require your users to use 2FA every time they log in. This does help with account security, but hurts the login UX, annoys users and reduces the conversion rates. This is a very good use case for Fingerprint as it allows to secure accounts and remove user annoyance and friction.

When a user logs into their account, you generate and store a device fingerprint. Before allowing the login attempt, you will count distinct fingerprints, associated with current account. If the number of fingerprints per account exceeds a certain limit (e.g. > 5), it could mean that an unknown device is trying to access the account and you should trigger a request for additional verification.

Counting fingerprints is a more flexible pattern than simply comparing them. It takes into account the fact that users typically access their accounts from multiple devices, or that shared household accounts could be accessed by several family members.

New account fraud

In simple terms, it's not ideal for users to create multiple accounts. Traditionally, this problem could be mitigated by forcing users to use Single Sign-On (e.g., log in with Google) or by validating their phone numbers. However, both options could negatively impact conversions and lower the signup rate.

Fingerprint can help in this use case and the design pattern used here is counting data associated with a fingerprint.

Every time a new account is created, you generate a fingerprint and count how many accounts are already associated with this fingerprint. If the number is low (e.g. ≤ 3), you allow the user to continue, finish creating the account, and finally write to the database table that this new account is associated with the fingerprint you just generated.
If the number is high (e.g. > 3), it means that one device is trying to create multiple accounts. In this case you should add some friction, e.g. by asking for a phone verification.

Pricing and billing

FingerprintJS (the library) can be purchased based on estimated number of monthly users your website has. As it's a client-side library, we don't count your users or collect any data.

Billing for Fingerprint Identification relies on the number of API calls made. These calls are logged on our backend, and an invoice is generated monthly or annually. We suggest monthly billing for smaller applications with lower traffic, and annual billing for larger customers with higher volumes.

You can find the Fingerprint Identification pricing information on our pricing page.

How am I protected from overpaying?

We take billing very seriously and have built several layers of protection to prevent accidental overcharging.

Fingerprint uses a two-level surge protection on all customer accounts. The first level is a DDoS protection. If your website is under attack, Fingerprint will not bill you for the API calls that are made during that period. The second layer is a web application firewall (WAF) that will filter out malicious or abusive requests from bots.

In addition to the surge protection, Fingerprint routes each request through a customizable request filtering layer. This allows you to ignore requests from unknown sources, permit only certain web applications to make Fingerprint API calls, or even discard requests at the HTTP header level.

In the unlikely event a malicious request surge penetrates these protective layers, we can waive the API calls charges.

How many API calls will I need?

Fingerprint’s identification is billed according to the number of API calls made. If you're unsure of how many you'll need, consider these two strategies:

1. Begin with unlimited free trial that lets you test all Fingerprint products for 14 days. After the trial you’ll get a good understanding of how many API calls you’ll likely need.
2. If a trial is not feasible, estimate the number of important actions where Fingerprint would typically be used, such as before login, account creation, payments, item refunds or return requests.

How the trial works

We provide an unlimited 14-day trial which allows you to test all our products, including identification, smart signals, and the device reputation network.

To begin, visit https://dashboard.fingerprint.com/signup.

Integrating Fingerprint into your application

Fingerprint provides several platform capabilities that are useful when building your apps.

1. Client-side SDKs for client-side data capture
2. Cloud integrations for robust data collection and compliance
3. Server data ingestion, server APIs and webhooks

You can use these capabilities to create a complete integration of Fingerprint with your applications.

Begin by capturing browser and device attributes on the client side, then stream the data to your cloud environment for storage, audit, and compliance purposes. The cloud integrations will then forward this data to our backend for identification.

Finally you can use server API and webhooks on your backend to get all the information from Fingerprint.

What about mobile apps?

Fingerprint client-side SDKs support web browsers (with our JavaScript SDK), Android native SDK (written in Kotlin), and iOS native SDK (written in Swift). All client-side SDKs support both identification and smart signal products.

Mobile SDKs can be used directly or via Flutter or React Native wrappers for cross-platform development.

Is Fingerprint future-proof?

Modern browser vendors regularly introduce privacy focused features. Recent examples include Apple’s Safari 17, Google Chrome Privacy Sandbox and Brave Browser fingerprinting protections.

Is Fingerprint future-proof? Is it safe for you to integrate Fingerprint into your application?

To answer this question, let’s take a look at the project history.

For 11 years, FingerprintJS has been the most accurate open-source browser fingerprinting library. It was first created on GitHub in 2012, and since then, its source code has been freely accessible for exploration. Developers working on Safari, Chrome, and Brave have studied the FingerprintJS source code and have been able to make changes in the browsers to block fingerprinting.

Some browser vendors, such as Brave, have introduced several anti-fingerprinting features over the recent years. However, these features are not effective in preventing fingerprinting in practice, as fingerprinting depends on open web standards, and breaking fingerprinting means breaking the internet.

In the unlikely event that a browser vendor introduces a feature that will make fingerprinting less effective, Fingerprint Identification will maintain its accuracy advantage for the following reasons:

1. These browser changes will change browsers for everyone, not only for Fingerprint. If that happens, Fingerprint will still be the highest accuracy solution in the industry, though it may be slightly less accurate than before.
2. Fingerprint Identification relies only partially on fingerprinting. It also uses considerable server-side information to create stable and unique VisitorIDs. The server-side techniques employed by our identification platform are not dependent on browser fingerprinting and will continue to function even if a new method of building web applications is developed.

Fingerprint Identification is guaranteed to work across all popular browsers, while maintaining its market-leading accuracy. Fingerprint.com is the only company globally fully dedicated to browser and device identification, fingerprinting, and fraud detection.

No browser updates will change our unique position to deliver high-accuracy and stable identification products. This is due to our uncompromising focus on accuracy, extensive browser research, sophisticated client and server-side identification techniques and machine learning.

How can I get help?

If you're a developer, please join our Discord channel for technical discussions.

If you’re a GitHub user, please use discussions and open issues.

If you’re a customer, our US-based support is always ready to help!

Fingerprint’s mission is to help build safe and seamless online services

Fingerprint identification was designed with certain guiding principles in mind.

Make cross-site tracking impossible with Fingerprint

Each visitor identifier (visitorID) generated in your application will be different in a different application.

If the same user visits two Fingerprint customers, they will get different visitor identifiers from the Fingerprint Identification API. This design decision, made early in our development, ensures cross-site tracking is not possible.
Fingerprint believes that same-site tracking is useful as it protects from fraud and abuse. For this reason, we historically focused on generating the highest-accuracy identifiers in same-site context.

Fingerprint was not designed for ad-tech

We built Fingerprint to provide device identification and intelligence data in same-site context for various use cases and customer industries. This model works very well for most cases, but will not work for advertisement purposes as ads typically rely on building a cross-site activity graph with the help of 3rd-party cookies and other legacy cross-site tracking techniques.

Flexible Data Retention Policies

By default, Fingerprint Identification keeps data for 30 days. However, you can adjust your account settings to keep data for a shorter or longer period, or even turn off data storage completely!

This flexibility makes it suitable for a variety of scenarios, including critical ones like services used by minors.

Fingerprint does not store PII (Personally Identifiable Information).

Fingerprint’s unique ability is to work on the device level. It provides accurate identification and smart signal without storing any PII. We don’t store emails, names, account information, and it’s even possible to configure your application to not store IP addresses making it a zero-PII product.

Fingerprint doesn’t require browser or device permissions

Fingerprint was designed with zero-permission policy in mind. We guarantee that no browser permissions are needed, no prompts are shown to users and mobile SDKs will never show any additional permissions dialogs to your users, ensuring Fingerprint’s client-side SDKs could be integrated in all kinds of web and mobile apps with different data collection expectations.

Fingerprint is crash-proof

Whether it’s a web or a mobile app, you can add Fingerprint to it without fear of it crashing your app. Fingerprint is designed to be crash-free and report errors, rather than throw them.

Fingerprinting might take a few seconds, especially on older mobile devices. To prevent application slowdowns, Fingerprint features a robust timeout implementation. As the application developer, you can control the duration of the identification process. If it exceeds the set timeout, the process will safely abort, ensuring your application's flow remains uninterrupted.

Fingerprint is secure

It’s nearly impossible to impersonate a specific fingerprint that belongs to a different device.
It’s safe to compare fingerprints and step up authentication or add additional friction when there is a fingerprint mismatch.

In conclusion, Fingerprint isn't just a good option—it's unequivocally the best choice for your identification and device fingerprinting needs.