Browser fingerprint · computed locally
No cookie needed
to recognise this machine.
A browser reports dozens of environment details every day, without asking: which engine it runs, how large the screen is, which time zone and languages it prefers, which GPU it has, how many pixels a given sentence occupies. No single one of those is worth much; put together they identify one machine as reliably as a login. That is a browser fingerprint. This page lays your own out in full, hashes it into a single ID, and lets you measure again to see which item moved. Every check runs on this device: no value is uploaded, nothing is recorded, nothing is written to local storage, and a reload clears the comparison.
Your fingerprint ID · first 24 of 64 characters
sampling…
Sampling locally…
Uniqueness
—
The check has not run yet.
Collision odds
—
Local estimate · not a measured population ratio
Reading these numbers expand for the per-item counts and the estimate's caveats
Once the check finishes, this explains how many signals returned a value and how many were blocked.
Each signal is weighted by roughly how many buckets it splits people into, then treated as independent. Real populations are not independent — owners of the same phone share screen, engine and often time zone — so the true figure is far less unique. This site holds no visitor distribution and cannot give you a measured ratio. Volatile items count at half weight and stay out of the fingerprint ID.
You, as a site sees you
Every sentence here is assembled from the sixty values above; nothing outside them gets written. What cannot be measured stays unmentioned — screen refresh rate, installed extensions, whether you are on battery: browsers do not expose any of them.
The dot on the left is the status: read / not offered / unavailable / volatile. On the right is the estimated information in bits — a longer bar separates more people; volatile items count at half weight and stay out of the fingerprint ID. Click a row for the raw value, or a group heading to fold it.
Showing 0 / 0 items
Sampling components locally…
Where these signals leak from
None of it requires your consent and none of it requires an extension. To render a page correctly a browser has to know its own pixel ratio, which number format a language uses, which APIs exist — and those working details happen to describe a machine. A site collects them, hashes them together, and can recognise you with no account, no cookie and a different IP. Cross-site tracking, fraud scoring, and "this is another alt account" all run on this layer.
The steadiest items are the rendering ones. Six layers composited on a Canvas and a pixel run read back; WebGL naming the vendor and driver; audio pushed through a compressor and sampled at thirteen fixed points; one sentence measured across 43 candidate fonts; forty layout boxes measured in the browser. You did not configure any of these — they are what your GPU, driver, font stack and engine version grew. New machine, updated driver, one extra font installed, and the values move.
Which is why "the ID changed" does not mean "you were identified", and "identical twice" does not mean "safe". It is a ruler, nothing more: what sites actually score is never a single value but whether dozens of them agree with each other. So the group to read first on this page is the network side — the Accept-Language and Sec-CH-UA headers the browser sends, against the language list and brand array the page reads. They share one source, so editing only one side shows up immediately.
What this page itself does
- No requests: apart from the same-origin /api/whoami (which the home page already uses to read your connection), this page sends nothing anywhere. Every value stays rendered on your screen.
- No permissions: the probes only read APIs the browser already exposes. No dialogs, no camera or microphone request, no cookie. This page does not touch localStorage either — the two-round comparison lives in page memory and is gone on reload.
- No third-party scripts: the site's CSP allows same-origin scripts only, so there is no FingerprintJS, no analytics, no ads. Every probe here was written by hand.
- The volatile items really do change: window size, storage in use, connection type. They are listed and weighted, but excluded from the fingerprint ID — otherwise every measurement would come out "different".
Three things this page cannot do, and does not pretend to. One: no JA3 / JA4 fingerprint — that requires reading the raw TLS handshake, and the platform this site runs on exposes it only as an enterprise capability. Two: no cross-context consistency checks — running the same probes inside an iframe and a Worker and comparing the two is the proper way to catch "UA edited, engine untouched", but this site's CSP does not allow that kind of context, so it is not implemented here. Three: no measured uniqueness ratio — this site keeps no database and no visitor corpus, so that percentage is an optimistic upper bound from per-signal weights, not "3 of 1.2 million visitors share your fingerprint".
How do I make my fingerprint harder to recognise?
The honest answer: hardly at all, and the cost is that sites may stop rendering correctly. What actually reduces distinctiveness is blending into a common bucket rather than standing out of one — a mainstream browser at a mainstream version, system default fonts with no exotic additions, integer zoom, dark mode following the system, and no extension that injects script. Forcing fake values into a few fields usually makes things worse: a spoofed value tends to contradict its neighbours, and contradictions are exactly what risk systems hunt. Isolating several identities properly means a separate browser profile and a separate IP per identity, not a switch.
Why do so many rows say "unavailable"?
Three different reasons, labelled separately on the page. "Not offered" means the browser does not have that API at all — Firefox and Safari do not implement userAgentData, because they treat it as a tracking surface. "Unavailable" means something blocked it: this site turns off camera, microphone and geolocation in its Permissions-Policy header, so those rows read policy-blocked forever — the site's decision, not your setting — and Chrome is progressively narrowing the real GPU string out of WebGL. Neither is a fault. But "this browser does not offer it" is itself a distinguishing signal, so those rows still enter the fingerprint ID.
What has a fingerprint got to do with an IP lookup?
A cookie lives on your machine and can be cleared; an IP is the address of this connection and changes with the network. A fingerprint lives nowhere — it is a combination of facts that already exist, so there is nothing to clear. That is why you can wipe cookies and open a private window and still be recognised, and why a VPN moves the egress IP while the time zone, languages and rendering profile stay where they are. The other half of this site's answer is the "Browser exposure" card on the home page, which checks whether WebRTC bypasses your proxy and hands over the real egress — one card for the network side, this page for the device side.
What does "Re-test" actually test?
It samples every component again and diffs the two rounds line by line. Any row whose value moved gets a coral marker with the old and new value, and the panel under the table says whether the fingerprint ID matched. The point is finding out which signals are not actually stable on your machine: the ones that move with window size, zoom, a font install. Note this is only a comparison between two snapshots of one device. It cannot tell you whether a site would identify you as the same person — that needs the site's own data.