Anonymity score

How this score works

The score starts at 100 and subtracts a fixed number of points for each signal that fails or needs review. The signals are the same ones a careful fraud filter looks at, evaluated with our own data: the public routing table for the network, the DB-IP Lite database for the IP's country and time zone, daily downloads of the Tor exit and Spamhaus DROP lists, a published list of datacenter ranges, 8 DNS blocklists, and the values the page script collects from your browser.

Every signal gets one of five statuses. Pass and note cost nothing. Review and fail cost the points shown in the table below. Not run means the signal has not been evaluated yet, either because its browser test is still running or because JavaScript is off; the summary line shows how many of the 12 signals have been checked so a partial result is never mistaken for a full one.

The score is deterministic. Two visitors with the same evidence get the same number, and you can recompute it by hand from the table.

The 12 signals and their point values

The bands: 80 to 100 is clean, 50 to 79 is caution, 0 to 49 is risky. A single datacenter exit lands you at 75, which is why the band is caution rather than risky: a datacenter address with everything else in order is normal for a developer and merely suspicious for a login. Add a WebRTC leak and you are at 60; add a time-zone mismatch and you are at 50, one point from risky.

How to read your result

The ring shows the score and band. Under it, the "what to fix" list contains only the rows that cost points, ordered as they were evaluated, each with the sentence of evidence and a link to the glossary entry that explains the fix. Below that, the full signal table shows all 12 rows including the ones that passed, then the WebRTC candidates table, then the usual profile of the address.

Read the fix list first. Two patterns cover most cases:

• Only the network rows fire. The address is the problem, the browser is fine. A residential or mobile exit in the right country fixes everything at once.
• Only the browser rows fire. The address is fine and the configuration leaks. These are settings, and each takes a minute.

If rows show Not run, wait a few seconds for the browser tests; the DNS resolver test takes the longest because it has to wait for your resolvers to reach our name server. If they stay at Not run, the page script is blocked by an extension or JavaScript is off, and the score covers only the server-side rows.

A note status is informational. The hosting row shows a note when the network could not be classified from its name, and the IPv6 row shows a note when IPv6 is on and located in the same country as the IPv4; neither costs points.

How to fix it

In order of points, which is usually also the order of effort:

1. Tor exit node (-40). Use a different exit. Tor is not a tool for logging into accounts that check their visitors, and no setting changes how the exit is listed.
2. Datacenter or hosting network (-25). Switch to a residential IP or a mobile carrier address. If a VPN is the only option, pick a provider and server that exit on a consumer network, and verify with the IP checker.
3. Known VPN or proxy network (-20), Spamhaus DROP (-20), blacklists (up to -20). Also address-level. Change the exit; for a blocklisted home address, restart the router for a new lease and check again after our 1-hour cache expires.
4. Automation signals (-20). Use a normal browser profile for logins. Headless or driver-controlled browsers announce themselves.
5. WebRTC public IP (-15). Turn on WebRTC protection in the VPN client or extension, or configure the browser; the WebRTC leak test has per-browser steps. In an antidetect browser, set WebRTC to replace the address with the proxy address.
6. DNS resolver location (-15). Route DNS through the tunnel in the VPN client, or enable remote DNS for a SOCKS5 proxy, and remove any encrypted-DNS setting pointing at a resolver in your own country. The DNS leak test shows the resolvers in use.
7. IPv6 address (-15). Enable IPv6 inside the VPN, or disable IPv6 on the adapter while the tunnel is up. The IPv6 test has the steps.
8. Time zone vs IP location (-10). Set the clock to the exit's time zone, in the system settings or in the antidetect profile. See timezone mismatch.
9. Proxy headers (-10). Ask the provider for an elite proxy or a different port; the headers are added by the proxy software. Confirm on the HTTP headers page.
10. Browser language vs country (-5). Put the exit country's language, or English, first in the browser's language list.

After each change, reload this page from the same browser profile; the score is recomputed from scratch on every load.

Limits of this test

• The score is a model, not a verdict from any specific site. Real services weigh signals differently, keep histories we do not have and buy reputation data we do not. Use the score as a checklist of what is visible, not as a promise.
• Network classification is rule based. Datacenter and VPN detection rely on a range list and name keywords. Misses happen in both directions, so read the evidence sentence rather than trusting the label blindly.
• Blocklist coverage is 8 lists, IPv4 only. Commercial reputation feeds are not included and IPv6 addresses are not checked against blocklists.
• Browser rows require JavaScript and a completed test. The DNS row needs the resolvers to reach our name server, which can take several seconds on slow resolvers.
• The time zone and language rules are deliberately lenient. Any zone used in the IP's country passes, and English always passes the language check. A stricter site may flag what we accept.
• A third-party address gets only 5 rows. The other 7 describe a browser session we do not have for an address you typed in.
• We measure anonymity against the IP, not identity. Cookies, logged-in accounts, device identifiers and payment data can identify you with a perfect score here. Nothing on this page should be read as a guarantee of anonymity.

Why a score and not an anonymity percentage

A percentage implies a probability we cannot honestly compute: nobody knows the odds that a particular site will challenge a particular visitor. A point system with published values is checkable. If you disagree with a deduction, you can see the evidence and decide for yourself; if a site you use is known to care about one signal more than we do, you can weight it yourself. It also makes progress visible: fixing a WebRTC leak moves the score by exactly 15, so you know the change worked before you try the login.

How the score behaves with different setups

Plain home connection, normal browser. Usually 100. Exceptions: ISPs that add carrier-grade NAT headers, a clock set to the wrong zone, or an address inherited with a listing.

VPN on a commercial provider. Typically 55 to 75: the hosting row almost always fires, and the VPN network row fires when the provider's name is recognizable. Leaks push it lower. This is why a VPN that shows "connected" can still be the reason a login is challenged.

Residential or mobile proxy, browser configured to match. 100 is achievable and is what you should expect before using the address. If the score is lower, the fix list tells you exactly which setting is off.

Antidetect browser profile. Same as the proxy case, with one caution: set WebRTC to replace rather than disable, and derive the time zone and language from the proxy rather than typing them in, so they stay consistent when you rotate the exit.

Third-party address typed into the box. Only the 5 network rows are scored. A datacenter address shows 75 here, and that number should be read as the network's score, not the score a session through it would get.

Where the browser fingerprint fits

The score covers the connection and the consistency between the connection and the browser. It does not score how unique your browser's fingerprint is, because uniqueness is a property of the whole population of browsers, which we cannot measure honestly from one visit. The browser fingerprint test shows the values a site can read and the hash they produce, so you can compare profiles; the anonymity score glossary entry explains how the two reports relate.