cookieless-fingerprint

Read what a browser will tell any website about its device. No cookies, no storage, no network call, no dependencies.

Around 50 signals across time, hardware, screen, browser, GPU, accessibility preferences, connection and rendering artefacts, returned as typed JSON with a stable id.

Live demo, with the reasoning: gauravkrp.com/cookie

Or run the bare one in this repo:

npm install && npm run build
npx serve .        # then open /demo/

Install

npm install cookieless-fingerprint

Self-host it. Do not serve this from someone else's CDN: a third-party script running canvas, audio and WebGL probes is indistinguishable from a tracker, and blocklists treat it as one.

Use

import { fingerprint } from 'cookieless-fingerprint';

const { id, device, graphics, screen } = await fingerprint();

id;                   // 'a4f13c02'  stable across reloads, nothing stored
device.os;            // 'macOS 14.5'
device.cores;         // 12
graphics.chip;        // 'Apple M3 Pro'
screen.refreshRateHz; // 120

graphics.renderer keeps whatever the driver actually said, which on Chromium is the ANGLE wrapper naming the vendor twice: ANGLE (Apple, ANGLE Metal Renderer: Apple M3 Pro, Unspecified Version). graphics.chip is that unwrapped down to the chip.

The result is a plain object, so JSON works with no adapter:

JSON.stringify(await fingerprint());

Why it is async

Four signals cannot be read synchronously, by design of the platform: client hints (getHighEntropyValues, giving CPU architecture and device model), the battery API, the audio fingerprint, which renders 5000 samples through an OfflineAudioContext, and refresh rate, which is measured over about twenty animation frames.

If you need something immediately, fingerprintSync() returns everything else:

import { fingerprintSync } from 'cookieless-fingerprint';

const { device, preferences } = fingerprintSync();

It deliberately has no id. Half the fields feeding a stable id are async, so a synchronous one would be a different number for the same visitor and would look like the fingerprint drifts.

Cost

A full fingerprint() is roughly 350ms wall clock, almost all of it waiting for frames to tick by while measuring refresh rate. Skip what you do not need:

await fingerprint({ skip: ['screen', 'rendering'] });  // ~5ms

Skipped groups still appear on the result with every field null, so destructuring never throws.

Flat view

For a table, a CSV or an analytics payload:

import { fingerprint, flatten } from 'cookieless-fingerprint';

flatten(await fingerprint());
// { 'graphics.renderer': 'Apple M3 Pro', 'device.cores': 12, ... }

Reading the output

null always means one thing: the browser was asked and would not say, whether the API is missing, blocked, or returned nothing. It never stands in for zero, false, or a skipped probe. So battery: null means you cannot know, and saveData: false means the browser said no.

Expect a lot of nulls in Safari and in Firefox with resistFingerprinting on. That is the feature working, on their side.

The id

An 8-character FNV-1a hash over the signals that do not move between reloads. Deliberately excluded: the wall clock, battery level, viewport size, measured refresh rate, screen orientation, bandwidth and round-trip estimates, and storage quota. Any one of them would hand the same visitor a new id on every reload.

It is not a unique identifier and should not be used as one. Two identical laptops on the same OS build will often collide, and the id legitimately changes when someone updates their browser, switches to light mode, or plugs in a different monitor. It is a similarity signal, not a primary key.

FNV-1a is not cryptographic. It is here to turn a long rendering artefact into a short stable label without touching the async crypto API.

The exact field list and ordering define every id in the world, so changing it is a major version bump.

Honesty about what this is

This is a fingerprinting library. It exists so people can see what is already being taken from them, and so developers can build that disclosure into their own sites.

If you use it to track people who have not agreed to it, you have built the thing the demo is arguing against. Several jurisdictions treat device fingerprinting as requiring the same consent as cookies, including under the EU ePrivacy Directive and the UK PECR, precisely because it needs no storage. Storing nothing is not a legal exemption.

Support

Every probe degrades to null rather than throwing, so the library runs anywhere. It returns an all-null result under SSR or in Node rather than crashing, which means you can call it in a component without guarding for window.

Browsers that blank the most: Safari (no userAgentData, no WebGL renderer name, no battery), Firefox (same, more so with resistFingerprinting), and Brave with its shields up.

Development

npm install
npm test          # the suite that matters is test/id.test.ts
npm run build

The tests run in Node with no DOM. That is deliberate: the parts worth testing are pure, and the parts that need a browser are thin readers around a platform API. test/id.test.ts is the one to keep green, since it pins the promise that a reload gives you the same id.

Licence

MIT