How this site measures, and where it is guessing
Two different kinds of number appear on ReadMyBrowser. Detected values are read straight from your browser and are as accurate as your browser is. Entropy figures are our own estimates, and we have no way to verify them against real visitors, because verifying would mean collecting. This page draws the line between the two and shows every figure.
What counts as measured
Every card on the dashboard and every signal page reads its value with a single documented call, listed on the page itself under "How a website reads this". The call runs in your browser, the result is rendered into the page, and nothing is transmitted. If you open your developer console and run the same expression, you will get the same answer. That is the whole method, and it is why these values need no caveat.
Two things are not read from your device and are labelled as such wherever they appear. Your public IP address cannot be read by JavaScript at all, so the page asks our own endpoint which address the request arrived from. Your IP location is a lookup that hosting infrastructure performs from that address, not a reading, which is why it disagrees with a consented location so often.
What counts as estimated
The entropy figures. Entropy in this context means how much a signal narrows the crowd you could be in: one bit halves it, ten bits divides it by about a thousand. To state a real figure you need to know how the values are distributed among actual people, and that requires a dataset of actual people's browsers.
ReadMyBrowser has no such dataset and is not going to build one, because the promise on every page is that nothing is collected. So the figures below are reasoned rather than measured: how many distinct values the signal can take, and how unevenly those values are spread in practice. They are useful for ranking signals against each other. They are not research findings and should not be cited as any.
For a figure that is genuinely measured against a population, use EFF's Cover Your Tracks or AmIUnique. Both compare your browser against a real dataset, which they can do because you contribute yours to it. That is a fair trade and worth making knowingly. It is simply a different trade from the one this site offers.
The full entropy table
These are the 11 signals the fingerprint test combines, with our estimate for each and the reasoning behind it. This is the same table published at /api/entropy.json, generated from the same source file, so the two cannot drift apart.
| Signal | Estimate (bits) | Why that figure |
|---|---|---|
| User agent | 10 | Carries browser, major version, platform and architecture in one string, though Chrome's User-Agent Reduction keeps shrinking what is left in it. |
| Screen size and colour depth | 4.8 | A handful of resolutions cover most visitors, but the long tail is genuinely varied. Colour depth adds almost nothing, since browsers converged on reporting 24. |
| Device pixel ratio | 1.5 | Dominated by 1, 2 and 3, with the fractional values from Windows scaling and Android splitting the remainder. |
| Timezone | 3 | A few hundred IANA zone names exist but are used very unevenly, so a common zone is cheap and a rare one is revealing. |
| Language list | 2.5 | The ordering carries more than the first entry: one common language is near-universal, a specific ordered list of three is not. |
| CPU threads | 1.8 | Concentrated on 4, 8, 12 and 16, and capped or reduced outright by Safari and Tor Browser. |
| Device memory | 1.2 | The specification allows only six values and caps them at 8, which was the point of specifying it that way. |
| Touch points | 1 | Effectively a yes or no for most visitors, so it splits the population roughly in half rather than finely. |
| WebGL renderer | 7 | A long driver-supplied string naming the graphics chip and often its driver, which splits visitors far more finely than any browser-level value. |
| Canvas rendering | 8 | How a device rasterises identical text and shapes depends on GPU, driver, fonts and anti-aliasing, so small hardware differences produce completely different hashes. |
| Platform | 1.5 | About five platform families cover nearly everyone; the value is in the rare ones. |
Why the total is capped at 33 bits
Those rows add up to 42.3 bits. We do not report 42.3, and the reason is worth stating plainly rather than hiding in a footnote.
Adding per-signal estimates assumes the signals are independent, and they are not: several of them describe the same device. The total is therefore capped at 33 bits, roughly 8.6 billion combinations, which is already more than the number of people online. Anything past that ceiling is arithmetic rather than information.
The independence assumption is the flaw. A Retina pixel ratio, an Apple GPU renderer string and a macOS platform token are not three independent facts, they are one purchase described three times. Adding their bits counts the same information repeatedly. Correcting that properly needs the joint distribution across signals, which needs the dataset we do not have, so we cap instead and tell you we capped.
If your own reading was capped, the page says so and shows both numbers. That is deliberate: a tool that explains how websites overstate what they know about you should not overstate what it knows about you.
How often this is checked
Every signal page carries the date a human last checked its facts, at the foot of the page, and that date is stored per page rather than stamped from the build clock. Browser behaviour in this area moves: APIs get capped, rounded or removed outright, usually in response to a demonstration that they worked as an identifier. The Battery Status API is the clearest example, and it is now absent from two of the four major engines.
There are 32 signal pages. When a browser changes what it reports, the page for that signal, its entry in the published API and the entropy table all come from the same source file, so a correction lands in all three at once.
How to report an error
Tell us what your browser actually reports and which browser and version you are on, through the contact page. A real person reads it. Facts that turn out to be wrong get corrected and the change is listed on the changelog, with the date, so you can see what was fixed and when.
Corrections we can verify against a specification or vendor documentation are made directly. Reports we cannot reproduce are still useful: browser behaviour varies by platform and version far more than the documentation admits, and a report we cannot confirm usually means the page needs a caveat rather than a new value.
Who maintains this
ReadMyBrowser is built and maintained by FusionStudios, a Dutch web development studio. It is given away free, it carries no advertising and it sells nothing, which is the reason it can be blunt about what fingerprinting is worth to the people doing it. The one commercial interest is honest and stated on the about page: tools like this are how the studio shows what it can build.
Last checked on .