AmIUnique compares you with people who visit AmIUnique

AmIUnique is accurate about the people it measures, and those people are not the web. It compares your browser with fingerprints left by its own visitors, a crowd that skews towards researchers, developers and privacy-minded users. So "you are unique" is a true statement about that table and a weak one about any site you actually use. The useful part of the page is lower down: which single attribute sits near 0.01%, and why.

Who AmIUnique compares you with

AmIUnique is a research site that began at Inria in France, run by researchers who study browser fingerprinting. Every visit adds a fingerprint to its dataset, and the results page compares yours with all of them.

In 2016 Laperdrix, Rudametkin and Baudry published "Beauty and the Beast" at the IEEE Symposium on Security and Privacy, built on 118,934 fingerprints from the site's own visitors. About 90% of the desktop browsers in it were unique, and 81% of the mobile ones.

Two years later the same group measured somewhere else. In "Hiding in the Crowd" (The Web Conference, 2018), Gómez-Boix, Laperdrix and Baudry collected 2,067,942 fingerprints from one of France's most visited websites, using the same attributes. Only 33.6% were unique. The authors' own conclusion was that the audience plays a large part in how effective fingerprinting is.

Same attributes, same researchers, and uniqueness fell by well over half when the visitors were ordinary readers of a news site rather than people who had gone looking for a fingerprint test. That is the honest answer to "is AmIUnique accurate": the measurement is sound, and the sample is self-selected.

How it works: Machines that exist

What our profile and a stock Chrome both read

AmIUnique is one of the public detectors in Mosaic's Detection tests. When we run that catalogue, an untouched Google Chrome on the same machine goes through the same page as a control. On 19 September 2026, the profile under test read:

Yes! You are unique among the 5522816 fingerprints in our entire dataset
rarest attributes: Canvas 0%, WebGL Data 0%, User agent 0.01%, Content language 0.01%

The control got the same verdict. The untouched browser on the same Mac was "unique among the 5522842 fingerprints", the count having moved on by a few visits. That is the first thing to know about the headline: it does not separate a browser somebody configured from one nobody touched, so it cannot grade either.

That is why the row's verdict in our catalogue is reference rather than pass or fail, and the rule we read it by is written beside it: "No single attribute at '0.01% of visitors'. Being unique overall is unavoidable and fine; being the only browser in the world with your font list is not."

How to read the attribute table instead

Each row in the table says what share of the dataset has your value for that one attribute. Read the rare ones and ask why each is rare. There are three kinds of answer, and they need different responses.

Rare because the dataset is old. The headline we quoted is the "All time" tab, which counts every fingerprint since the site opened, so anything that changes with each release, such as a browser version in the User-Agent, is rare there by arithmetic. A current Chrome version only gets common once enough people have visited with it. The page also has tabs for today, 7, 15, 30 and 90 days, and a recent window is the fairer comparison for a value like that.

Rare because of the crowd. Our profile's language list was Austrian German first (de-AT,de,en-US,en), because the profile was matched to an Austrian exit. Among AmIUnique's visitors that list read 0.01%. Among the visitors of an Austrian shop it would be one of the most common lists there is. The value is right for the place; the table is the wrong place to judge it.

Rare because something is wrong. This is the row that matters: a font list nobody else has, a screen size no device ships, a renderer string that no driver writes. A value that is rare because it is impossible is rare on every site, and a consistency scanner will find it whatever its crowd. Our profile's canvas and WebGL hashes both read 0%, and a hash is close to unique on any machine in a table this size, so a rare hash alone says little. What to check is whether the WebGL values agree with the GPU the browser claims.

Use it beside a control

The cleanest way to read AmIUnique is the way we read every detector: run your profile and an untouched browser on the same machine in the same session, and look only at what differs. A rare row that both share belongs to the machine or the crowd. A rare row only the profile has is a claim that profile made, and the thing to check. Why that control should be Google's own build and not a guess is in the control that settles "is it our patches?".

The EFF's test has the same crowd problem with a different crowd, and we worked through its number in 18.28 bits: what Cover Your Tracks' number measures. What either page means for profiles that should stay stable rather than random is in 'Randomized fingerprint' is the wrong goal on Cover Your Tracks, and the values a page reads in the first place are listed under browser fingerprint.