How our tools work: methodology and data sources

We only use data whose publisher allows this use, and we show its attribution and update date wherever it appears. The /v1/sources endpoint behind the site lists every dataset with its live status; this table is the human version.

Deliberately not used: MaxMind GeoLite2 (license terms), ip-api.com (non-commercial only), Spamhaus and CBL (commercial use requires a paid subscription), SORBS (shut down 2024), PeeringDB (reproduction requires approval), AbuseIPDB (API key required). We would rather show fewer sources than sources we are not allowed to show. IPinfo Lite is supported by the lookup service but not enabled at the moment.

No database knows where an address is; each one infers a place for a block from registry records, operator geofeeds, latency measurements and usage patterns, and rebuilds the guess periodically. We therefore query several and show them next to each other.

DB-IP Lite (monthly build), the IP2Location.io API (live, cached 24 hours) and, for your own address, Cloudflare's live edge geolocation (where our edge saw the connection come from) vote on country and city; IPinfo Lite is supported but not enabled at the moment. The registry country from iptoasn.com is shown for comparison but never votes: it is where the block was allocated, which for a multinational can be a different continent. The consensus is the value the voting sources agree on, with a confidence that drops when they disagree or when only one source has data, and a spread (kilometers between the sources' coordinates) so you can see the disagreement in numbers. The confidence is a number from 0 to 1 that the lookup service computes for the country vote (it says nothing about the city): with one voter it starts at 0.6 (+0.05 per agreeing registry record, at most 0.8); when all voters agree it is 0.75 plus 0.1 per voter, plus 0.02 per agreeing registry record, capped at 0.97; when voters disagree it is the agreeing share times 0.9. The site shows it only in the expandable “How sure is this?” detail, next to the plain count of city-level sources that agree. Registry records (RIR, Team Cymru, RDAP) are listed separately as network registry records: they say where the network owner registered the block — for satellite and global providers often a different country from the visitor — and are never counted as location confirmations. Prefixes that are announced from many locations at once (anycast) are flagged and their confidence is capped.

Blocks get reassigned faster than databases rebuild; large ISPs and mobile carriers route traffic through regional gateways; VPN, proxy and cloud addresses are located where the server is, by design; IPv6 coverage in free databases is thinner than IPv4; anycast addresses have no single location. The guide why your IP location is wrong covers each case. City-level is the best possible outcome; street-level claims from any provider are marketing.

The leak tests measure what actually leaves your device, not what your settings say. Everything they need runs on infrastructure we operate ourselves so that no third party sees your test.

We run the only authoritative nameserver for the zone dnstest.checkmyip.com. For each test your browser is given unique hostnames under that zone (six in the standard test, thirty-six extended) and loads a tiny resource from each. Every recursive resolver that handles your lookups has to ask our nameserver, and our server records the resolver's address for that session. Each resolver is classified: same address as you (you run your own resolver), same network as your HTTP address, a known public resolver, or other (an ISP's or VPN provider's resolver). Where a resolver forwards EDNS Client Subnet we compare the forwarded prefix with your visible address; a prefix that does not contain it proves the query entered the resolver from a different network. The verdict table (leak / possible leak / no leak / review, each with a confidence) is applied exactly as documented in our service interface, and the resolver list is always shown so you can check the reasoning. Sessions expire after ten minutes and are never written to disk.

Your browser gathers ICE candidates against our own STUN server (stun.checkmyip.com, UDP and TCP, IPv4 and IPv6). The server-reflexive candidate is the public address our STUN server saw your UDP packet arrive from; we compare it (and any public host candidate) with the address your browser uses over HTTP, including the IPv4-only and IPv6-only views. A public address that websites do not already see is reported as a leak; local and mDNS candidates are shown but only noted as LAN layout visible. The comparison runs in your browser; candidates are not sent to us.

Three hostnames resolve respectively to an IPv4-only address, an IPv6-only address and both. Your browser fetches a small JSON file from each; which fetches succeed and which family the dual-stack host sees tell us whether you have IPv4 only, dual-stack preferring IPv6, dual-stack preferring IPv4 (often a sign of a slow or broken IPv6 path) or IPv6 only. In the VPN test, an IPv6 address from a different network than your VPN's IPv4 address is reported as an IPv6 leak.

An address is reported as a Tor exit when it is on the Tor Project's exit list (refreshed hourly). It is reported as a VPN or data center address when it falls in the X4BNet VPN or data center ranges, in the official cloud providers' published ranges, or when its ASN is a hosting network; as an iCloud Private Relay egress when it is on Apple's list; and as a proxy when a DNS blocklist that tracks open proxies lists it. Residential, mobile and business classifications come from the network type of the ASN. Each verdict carries a confidence (high for list hits, medium or low for heuristics) and the list of reasons. On your own connection we add browser-side signals: a device time zone that differs from the address's time zone, and WebRTC or DNS results that point at a different network. The risk score (0–100, levels low / moderate / high / severe) adds fixed weights per signal — for example +20 for a hosting range, +50 for a known botnet command server — and the weights are published with a version number so a score can be reproduced.

The privacy score on the privacy score page starts at 100 and subtracts a fixed amount per finding, in two modes. VPN mode (you told us you are on a VPN): −40 if the visible address is your ISP's rather than a VPN's, −25 for a DNS leak, −20 for a WebRTC leak, −15 for an IPv6 leak, −10 for a time-zone mismatch, −10 if the address is on a blocklist. Normal mode (no VPN): −10 for a WebRTC-exposed local network, −10 for a time-zone mismatch, −20 for a blocklisted address. The browser-fingerprint check is shown as an estimate and is not deducted in this first version; the −10 for a highly unique fingerprint will be switched on once uniqueness is measured from real samples, and this page will say so. The score is never below 0; bands are 90–100 excellent, 70–89 good, 40–69 fair, below 40 poor. The formula is deliberately simple so that the fix list and the score always agree. When a check cannot run — our test server is unreachable, a request times out, or the browser does not support the test — it is excluded and the score is shown as incomplete with the names of the checks that did not run; a partial result is never presented as a final score, and each missing check can be retried.

We query ten DNS blocklists in parallel through our own recursive resolver, as the list operators request, and cache the answers for ten minutes. We only use lists whose operators publish terms allowing free public queries and that answered the standard test entry on 2026-10-21. UCEPROTECT levels 2 and 3 list whole allocations and ASNs and are shown as informational, not counted against you. A query refused by a list is reported as an error, never as a listing. Each result shows the list, its category, the return code and its documented meaning, when it was checked and where to request removal.

The reputation card on the homepage shows two scores out of 100 and an overall figure. IP reputation is what blocklists, abuse feeds and anonymiser signals say about the address; Browser reputation is what this browser gives away or gets wrong (leaks, mismatches, trackability). Each starts at 100 and loses a fixed, published amount per finding; the deductions below are the whole formula, there is no hidden model. The result is an estimate from the signals we can measure, never a guarantee of how any website will treat you: every site weighs these signals differently, and many use data we do not have. A check that could not run (the lookup did not answer, a test timed out, the browser does not support it) is left out of its score and named in the "More" panel; it is never counted as passed. The IP score needs at least two of its three signals, the Browser score at least three of its seven; with fewer, that side shows Could not be checked and the overall figure comes from the other side alone, marked as such.

A VPN costs fewer points than a proxy on purpose: it is a legitimate privacy tool, and most websites only add a captcha for it, while proxy and Tor exits are blocked outright more often.

All browser signals are read in your browser; nothing about them is sent to us. The language table is deliberately wide (English counts as usual in Bangladesh, India, Nigeria, Singapore and so on), so this signal only fires on a clear miss and carries little weight.

Overall = 60 % of the IP score + 40 % of the Browser score, rounded: a website judges the address first and the browser second. Bands: 90–100 Excellent, 75–89 Good, 55–74 Fair, 35–54 Poor, below 35 Risky; the one-line explanation under the number names the count of findings and of checks that could not run. We only use sources whose terms allow free public queries: AbuseIPDB and IPQualityScore need an API key and a commercial licence, Spamhaus requires a paid subscription for commercial use, Project Honeypot's http:BL needs an access key, so none of them is queried and the score says nothing they would say. If we add a source later, this table changes first. The weights are our own judgement, kept small in number so that the list of fixes and the number always agree; they are not calibrated against any website's real decisions, which is the main reason the score is an estimate.

We do not store visitor addresses. Lookup results are cached for ten minutes, in the lookup server's memory and at the edge (Cloudflare's per-data-center cache, keyed by address); leak-test sessions live in memory for ten minutes; nothing identifying is written to disk or to a database. Aggregated usage counts (page, day, country, language, device class) contain no addresses. Our servers' own health reports contain the servers' addresses and load, not yours. See the privacy policy.

2026-10-22 — Geolocation votes: DB-IP Lite, IP2Location.io (live) and Cloudflare edge data; IPinfo Lite prepared but not enabled. Registry records (RIR, Team Cymru, RDAP) are shown as a separate group and never counted as location confirmations. Privacy score: an incomplete run is labelled incomplete instead of showing a final figure. The location map loads automatically through our own tile relay.

2026-10-21 — Site launched after a complete rebuild. Geolocation: Cloudflare edge + DB-IP Lite (build 2026-10-01), IPinfo Lite prepared. Network: iptoasn.com, DB-IP ASN Lite, Team Cymru, RIPEstat, RDAP. Risk: Tor exits, X4BNet, cloud feeds, iCloud Private Relay, Feodo Tracker, ten DNSBLs; score version 2026-10-21.1. Leak tests on our own DNS zone and STUN server. Future changes to sources, weights or test design are recorded here with their date.