// DOCUMENTATION
Methodology
Every tool on this site, documented: what it tests, where the data comes from, and where it stops being reliable.
// Why these pages exist
A result is only worth something if you know how it was produced. Every tool here has a page setting out exactly what it checks, which service or protocol supplied the answer, and the specific conditions under which it will be wrong or incomplete.
The limits sections are the point. A tool that hides what it cannot do is asking to be over-trusted, and a security tool that gets over-trusted is worse than no tool at all. Where a result would be misleading, we would rather say so on a page you can read before you rely on it.
These pages are checked against the code rather than written once and left. The review date below applies to the whole set — if a tool changes, its page changes with it.
// One page per tool
How your public IP address is detected on page load, and why the location shown may not be yours.
How an arbitrary IPv4 or IPv6 address is geolocated, and how accurate each field actually is.
Which DNS record types are queried, which resolvers answer, and why results can differ from other checkers.
How registration data is retrieved over RDAP, and why most contact details are missing.
Which eight DNSBLs are queried, how a listing is distinguished from an error, and what a result does not cover.
Which breach dataset is searched, how it compares to the alternatives, and what a clean result does not prove.
Where the randomness comes from, how the entropy figure is calculated, and the one place it is approximate.
What the TLS handshake reports, why invalid certificates are still shown, and what this is not.
Which seven headers are scored, how the grade is calculated, and why a grade is not a security assessment.
How WebRTC candidates are gathered, how a leak verdict is reached per address family, and why some browsers show nothing.
Last reviewed against the code on 2 August 2026.