How we test our tools

Last updated 29 September 2026.

A network tool is only worth using if it is right, and "it returned something" is not the same as "it returned the truth". So we check each tool against inputs whose answer is already known and independently verifiable. This page records those checks, the bugs they caught, and where the underlying data stops being reliable.

Known-answer tests

Port checker

Tested against 8.8.8.8, whose behaviour is publicly documented. Port 53 (DNS) returns open, port 443 (DNS-over-HTTPS) returns open, and port 23 (telnet) returns filtered — Google drops it rather than refusing it. google.com:443 also returns open, which confirms hostname resolution works as well as raw addresses.

The tool distinguishes "closed" from "filtered" by whether the connection is refused or simply times out, so a firewall that silently drops traffic reads as filtered. That inference is reasonable but it is an inference, not a certainty.

Reverse DNS

Tested with 142.250.187.206, a Google address with a stable PTR record. The correct query is 206.187.250.142.in-addr.arpa — the octets reversed — which resolves to lcfraa-bm-in-f14.1e100.net. We also check 8.8.8.8 (dns.google) and 1.1.1.1 (one.one.one.one).

Those last two are deliberately poor tests on their own: both addresses are palindromes, so they resolve correctly whether or not the octets are reversed. Only a non-palindromic address proves the query is built properly.

IP reputation

Tested against three addresses with known characteristics, one of each type:

• A live Tor exit taken from the Tor Project's own published exit list — returns tor: true, proxy: true, and is flagged for abuse.
• A commercial VPN exit — returns vpn: true and hosting: true.
• 8.8.8.8 — returns hosting: true with every anonymity flag false, which is what a datacentre address that is not an anonymity service should look like.

A tool that returns "not a VPN" for everything looks perfect until you feed it a real VPN, so every flag has to be shown moving in both directions.

WebRTC leak test

The classifier has five outcomes and we exercise all of them: a genuine leak (a WebRTC address on a different network than the one serving the page), no leak, WebRTC returning no public address at all, a private LAN address, and WebRTC disabled entirely.

The distinction that matters is between a different address and a different network. On our own test machine the page saw one address while WebRTC reported another, both belonging to the same VPN provider. Comparing addresses alone would call that a leak; comparing the network it belongs to correctly does not.

Speed test

The arithmetic is checked independently of the network. A known transfer — 80,000,000 bytes in 3.015 seconds — must produce 212.31 Mbps. Computing it as 202.47 means the code is dividing by 2²⁰ instead of 10⁶, which is exactly the bug described below.

CAPTCHA diagnosis

Every cause this tool reports maps to a specific value it can show you, so a finding can always be traced to a measurement rather than a hunch. The ranking is deterministic for a given input, which means it can be tested without a network at all: 18 cases run against stubbed inputs covering each cause in isolation and in combination.

• Our own UK residential line, with a matching browser timezone and language, must report no cause found. A diagnostic tool that always finds something is worthless, so the honest negative is the case we guard hardest.
• An abuse flag must outrank a VPN flag; Tor must outrank a datacentre range; a WebRTC leak must rank last. A commercial VPN exit produces datacenter then vpn, in that order.
• A timezone mismatch must appear as a low-severity contributing cause and never as the primary one, because travellers trip it without any VPN.
• A browser reporting a bare en, with no region, must raise no language finding. A language with no region tells us nothing about location, and guessing from it would manufacture a false cause.
• Carrier-grade NAT is reported only when the public address falls inside 100.64.0.0/10, checked at all four range boundaries. Many ISPs run CGNAT on ordinary addresses, which we cannot detect, so we say that rather than guess.

IP geolocation

Rather than assert an accuracy figure, we measured one: 15 addresses looked up in three independent providers on the same afternoon. The full method and raw results are published in how accurate is IP geolocation, including the parts that undermine a confident headline number.

Bugs these tests found

All four were live on this site and were fixed on 28–29 September 2026.

• The VPN leak test reported a leak for almost everyone. Chrome, Edge and Safari replace your local IP with a random *.local name. The old check treated anything that was not a private IPv4 address as a leak, so that protective placeholder was counted as an exposure. The same code also built its connection without a STUN server, meaning a genuine public-address leak could never be detected. It was wrong in both directions at once.
• The IP reputation page did nothing. Its Check, Use My IP and Copy buttons carried element IDs but nothing was ever bound to them, so clicking them had no effect regardless of which data source sat behind the page.
• Reverse DNS never reversed the octets. It queried 142.250.187.206.in-addr.arpa instead of 206.187.250.142.in-addr.arpa. That returns no record, so every non-palindromic address reported "no PTR record found".
• The speed test understated every result by 4.86%. It divided by 1024×1024 where a megabit is 10⁶ bits.

Where our data comes from, and its limits

• Cloudflare edge geolocation — city, region, postcode area, timezone and coordinates, passed to us as request headers. City-level accuracy is genuinely poor; see the experiment linked above.
• IPinfo Lite — network and organisation details, including the ASN. Server counts and organisation names are self-reported by the networks themselves.
• ipapi.is — VPN, proxy, Tor, datacentre and abuse flags. These are catalogues: a brand-new VPN endpoint may not be listed yet, so "not detected" means "not in the catalogue", not "definitely not a VPN".
• Cloudflare DNS-over-HTTPS — reverse DNS lookups.
• Cloudflare speed endpoints — the same infrastructure behind speed.cloudflare.com.
• Your own browser — the browser privacy and email header tools read only what your browser already exposes, or what you paste in. Pasted email headers are parsed locally and never uploaded.

Every one of these is an estimate produced by someone else's database. Where we can measure how wrong they are, we publish the measurement rather than a reassuring adjective. The privacy policy lists each provider and what it receives.

Found something wrong?

If a tool gives you a result you can show is incorrect, we want to know — that is how the four bugs above were found. Email [email protected] with the input you used and what you expected.