How the Analyzer Works
A step-by-step account of what happens between clicking "Start analysis" and seeing your results — and why none of it involves a server.
Step 1: The page loads plain JavaScript
The analyzer is a static page. When it loads, your browser downloads HTML, CSS, and a handful of small JavaScript files from this site — one file per test plus the code that renders results. There are no frameworks, no analytics, and no tracking pixels of the site's own. The one piece of third-party code is an advertising script that funds the site; it is separate from the analyzer and disclosed in the privacy policy. At this point nothing has been measured yet; the tests only run when you click the button.
Step 2: Five tests run inside your browser
Clicking Start analysis runs the tests one after another, entirely within the page's JavaScript environment:
- Canvas — the page draws a small fixed image (text, shapes, a gradient) on an off-screen canvas and reads the pixel output back. See canvas fingerprinting.
- WebGL — the page opens a WebGL context and reads the vendor and renderer strings plus capability values the browser reports. See WebGL fingerprinting.
- Audio — the page renders one second of a silent test signal through an offline audio context and reads the resulting samples. No sound plays and no microphone is involved. See audio fingerprinting.
- Screen — the page reads resolution, available size, color depth, pixel ratio, and current viewport from standard properties. See screen fingerprinting.
- Fonts — the page measures the width of a fixed string rendered in 41 candidate fonts and compares each against generic fallbacks. See font fingerprinting.
Step 3: Raw output becomes a hash
Some raw results are long — a canvas image encodes thousands of pixels. To display something readable, the page computes a SHA-256 hash of each raw result using your browser's built-in Web Crypto API. A hash is a short, fixed-length summary: the same input always produces the same hash, and a tiny change in input produces a completely different hash. That property is exactly what makes hashes useful for change detection. Hashing also happens locally; the raw data never needs to go anywhere to be summarized.
Step 4: Results are explained, not just displayed
Each result card shows the technical value or hash together with a plain-language summary, the specific data source, a distinguishing-power rating (Higher, Moderate, Lower, or Unavailable) with the reasoning behind it, a privacy interpretation, and a practical action. The rating reflects how much a signal could narrow down which browser produced it — for example, an unmasked GPU renderer string names specific hardware, while a common screen resolution describes a very large group.
Step 5: A baseline waits in page memory
After the first run, the page keeps each test's hash in an ordinary JavaScript variable — not in localStorage, not in a cookie, not on a server. If you change a setting and press Run again and compare, the new hashes are checked against that variable and differences are highlighted. Refreshing or closing the page destroys the variable, and with it the baseline. That is the entire storage story.
What never happens
No result is transmitted: the analyzer's own code makes no network requests after the page loads its files — requests made by the advertising script are unrelated to and never carry your results. No result is stored: the analyzer creates no cookies and uses no persistent browser storage. No permission is requested: every API used is available to ordinary pages without a prompt — which is precisely why fingerprinting works silently on sites that do it for tracking. You can verify all of this in the privacy audit.