How ReadMyBrowser Measures and Estimates

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.

Per-signal entropy estimates and their reasoning
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.

Signals the test reads but does not score

The fingerprint test reads 6further signals that real fingerprinting scripts use, shows you their values and includes them in your fingerprint ID. It gives them no bits, and so they never move your score, your rating or the "1 in N" figure. The reason is the same one that runs through this page: a figure for these would have to be invented, and an invented figure presented next to a reasoned one would make both look equally solid.

Signals the fingerprint test reads without scoring, and why
Signal	What the test reads	Why it carries no bits
Client hints (high entropy)	navigator.userAgentData.getHighEntropyValues(): platform version, CPU architecture and bitness, device model, and the full version of every brand the browser reports.	It restates the browser, version and platform that the user agent row already scores, in finer detail, so giving it bits of its own would count the same facts twice. A browser without the API simply returns nothing here.
Intl settings	Intl.DateTimeFormat and Intl.NumberFormat resolvedOptions(): the locale the browser formats with, its calendar, its numbering system and whether it uses a 12 or 24 hour clock.	These mostly follow from the language list and timezone, which are already scored. How much they add on top depends on how unusual the combination is among real browsers, which only a population dataset could show.
Media-query preferences	matchMedia() for colour scheme, reduced motion, contrast, forced colours, colour gamut, dynamic range, pointer type and hover.	Most visitors keep the defaults and a few accessibility or display settings stand out sharply. That split is a distribution, and a distribution is exactly what we cannot estimate without collecting it.
WebGL parameters	gl.getParameter() limits such as the largest texture and renderbuffer, vertex attributes and viewport dimensions, plus the shading language version and the number of supported extensions, hashed together.	They are set by the same graphics chip and driver that the WebGL renderer row already scores, so most of what they reveal is counted there.
Audio rendering	An OfflineAudioContext renders a short tone through a compressor without playing anything, and the output samples are hashed.	The result depends on the audio stack and the processor, which overlaps with signals already scored, and it cannot be reasoned from a list of possible values the way the scored rows are.
Installed fonts (probe)	The width of a test string drawn in each of 42 common font names is compared with the generic serif, sans-serif and monospace fonts; a different width means that font is installed.	The answer depends on which names are probed, so a figure would describe our list rather than your device, and installed fonts already shape the canvas rendering row.

These extra reads run after the page has drawn your score, one at a time while the browser is idle, with the audio render and the font probe last. Each has a time limit, and a browser that blocks one simply shows that row as blocked or not exposed. The font probe asks only about these 42 names, which is why its answer describes the list as much as your device: Arial, Arial Black, Arial Narrow, Calibri, Cambria, Candara, Comic Sans MS, Consolas, Constantia, Corbel, Courier New, Franklin Gothic Medium, Gabriola, Georgia, Impact, Lucida Console, Lucida Sans Unicode, Palatino Linotype, Segoe UI, Tahoma, Times New Roman, Trebuchet MS, Verdana, American Typewriter, Avenir, Baskerville, Didot, Futura, Geneva, Gill Sans, Helvetica, Helvetica Neue, Hoefler Text, Menlo, Monaco, Optima, Cantarell, DejaVu Sans, Liberation Sans, Noto Sans, Roboto, Ubuntu.

The same rows are published in /api/entropy.json under unscoredSignals, with no bit value, so anyone reusing the model sees which signals it leaves out and why.

What we deliberately do not claim

That your fingerprint is unique. The score is a capped estimate. Only a comparison against a real population of browsers can show whether anyone else matches you, and we do not hold one.
That a lower score makes you untrackable. Sites also recognise visitors by IP address, cookies and logins, none of which a fingerprint score measures.
A number for the signals we do not score. They are listed above with the reason, and they stay unscored until there is something better than a guess to put in their place.
That a fix step works in your exact browser version. Every step in the fingerprint test's checklist cites the vendor documentation or the page on this site it comes from, but browsers change. The before and after compare exists so you can see the effect for yourself rather than take our word for it.
That a shared result is genuine.A share link carries a few plain-text fields after the "#" in the address, which anyone can edit. The page labels it as a shared result and checks only that its fields are in the allowed form.
That we know what other sites do with a fingerprint. This site can show what your browser exposes. What a particular tracker or anti-fraud system then does with it is not visible from here.

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.