Does your website use third-party services? Get GDPR compliant in minutes.
Try FlowConsentFree plan · 10-min setup
ClientJS is an open source JavaScript library that generates a browser fingerprint by reading device and browser attributes such as user agent, screen, fonts, plugins and canvas data. It combines these into a single identifier that can recognise a device without using cookies. Because fingerprinting accesses information on the user device and creates a persistent identifier, the GDPR and the ePrivacy Directive treat it as requiring prior consent.
ClientJS is a free, open source JavaScript library that creates a digital fingerprint of a visitor browser. Rather than storing an identifier in a cookie, it reads many properties of the browser and device and combines them into a single hashed value that is likely to be unique. Developers embed it to recognise returning devices for purposes such as fraud prevention, analytics or personalisation.
ClientJS gathers attributes including the user agent, operating system, browser and version, language, screen resolution and colour depth, installed fonts and plugins, time zone, and canvas and WebGL rendering signatures. None of these on its own identifies a person, but their combination produces a fingerprint that can single out a device. The library itself does not set cookies and runs entirely in the browser.
A browser fingerprint is a persistent identifier that can distinguish one user from another, so it is personal data under the GDPR even when no name is attached. The act of reading device characteristics to build the fingerprint falls within Article 5(3) of the ePrivacy Directive, which European regulators interpret as covering fingerprinting and not only cookies. As a result, prior consent is generally required before ClientJS runs.
Get GDPR compliant in 10 minutes
Free plan available · No credit card required
Because fingerprinting is treated like a non essential cookie, you must obtain freely given, specific, informed and unambiguous consent before generating the fingerprint, unless it is strictly necessary for a service the user explicitly requested. Block the ClientJS code until consent is given through a Consent Management Platform, log that consent, and let users refuse or withdraw as easily as they accept.
ClientJS runs locally and does not send data to a library vendor, so transfers depend on what your own backend does with the fingerprint. If you transmit the fingerprint to servers outside the European Economic Area, for example a fraud or analytics provider in the United States, those transfers need a valid safeguard under Chapter V of the GDPR and a Transfer Impact Assessment. Keep a clear record of every recipient.
Treat the fingerprint as a tracking identifier: disclose it in your cookie and privacy notices, gate it behind consent, and define a retention period after which it is deleted. Document the purpose and necessity of fingerprinting, prefer less intrusive alternatives where possible, and carry out a DPIA given the high risk nature of the technique. Review the implementation whenever you change how the fingerprint is used or shared.
Websites using ClientJS must obtain user consent under GDPR regulations.
DPIA considerations
ClientJS reads a wide range of device and browser characteristics (user agent, language, screen resolution, colour depth, installed fonts, plugins, canvas and WebGL signatures, time zone) and hashes them into a probably unique fingerprint. Key DPIA considerations: (1) the fingerprint is a persistent identifier and therefore personal data even without a name; (2) fingerprinting is harder for users to detect, block or delete than cookies, which heightens the intrusion; (3) accessing device information falls under Article 5(3) of the ePrivacy Directive and requires consent; (4) combining the fingerprint with other data enables cross context tracking. A DPIA is strongly recommended because fingerprinting is a high risk, opaque form of identification.
Sample consent text
We use ClientJS to recognise your device through a browser fingerprint, for example to support security or to remember your preferences. This reads characteristics of your browser and device and combines them into an identifier, without using cookies. You can withdraw your consent at any time through our cookie settings.
Third-party domains contacted
cdnjs.cloudflare.comcdn.jsdelivr.netClientJS uses cookies for user preferences — inform visitors with a consent banner.
ClientJS does not set cookies. Instead it reads browser and device attributes and hashes them into a fingerprint, which is a cookieless identifier. Being cookieless does not make it exempt; the fingerprint is still a persistent identifier that the law treats much like a tracking cookie.
Yes, in most cases. Reading device characteristics to build a fingerprint falls under Article 5(3) of the ePrivacy Directive, which regulators apply to fingerprinting as well as cookies, so prior consent is required unless the fingerprint is strictly necessary for a service the user requested. Block ClientJS until consent is given.
For non essential fingerprinting the basis is consent under Article 6(1)(a) GDPR, combined with Article 5(3) ePrivacy for accessing device information. A narrowly scoped security use that the user has requested might rely on legitimate interest or necessity, but general analytics or tracking fingerprints cannot.
ClientJS by itself does not transfer data, since it runs in the browser. Transfers arise only when your backend sends the fingerprint to a third party or to servers outside the EEA, in which case Standard Contractual Clauses or another Chapter V mechanism and a Transfer Impact Assessment apply. Map where the fingerprint travels.
A DPIA is strongly recommended. Fingerprinting is an opaque, persistent and hard to refuse form of identification, which regulators consider high risk, so documenting the purpose, necessity, risks and safeguards is good practice and may be mandatory under Article 35 GDPR.
Load ClientJS only after consent through a CMP, disclose the fingerprint in your privacy and cookie notices, and define a retention and deletion policy. Limit the attributes you read to what you need, avoid combining the fingerprint with other identifiers without a basis, and complete a DPIA before going live.
For analytics, privacy friendly tools that rely on aggregated or cookieless server side measurement avoid persistent identification. For security, risk based authentication using a narrowly scoped, consented signal or a first party session is less intrusive. Whatever the alternative, the key is to minimise persistent identification and to be transparent.
State in your privacy and cookie notices that you create a browser fingerprint, list the categories of device attributes read, explain the purpose and retention, and name any third parties that receive the fingerprint. Because no cookie is set, make clear that a cookieless identifier is used and how users can object.