How We Test

How it works

When you load the homepage or any IP-detection tool, your browser makes a request to our edge API endpoint (/api/get-my-ip). The API reads the x-forwarded-for, x-real-ip, and cf-connecting-ip headers (in that priority order) to identify your real IP address, including handling IPv4-mapped IPv6 addresses.

IPv4 vs IPv6

If your network supports dual-stack, we detect both addresses. Your browser may prefer one protocol over the other depending on your ISP and OS settings. We show all detected addresses and label them clearly.

Geolocation accuracy

IP-to-location data uses MaxMind GeoIP2 (city-level database), cross-referenced against our provider's enriched dataset. Accuracy varies:

Detection signals we check

VPN detection is not a single check — it's a combination of signals. We evaluate all of the following and score them together:

1. ASN ownership — Data-center ASNs (e.g. Choopa, M247, QuadraNet) are almost exclusively used by VPNs. Residential ISP ASNs are not.
2. IP reputation databases — We query multiple threat intelligence feeds that flag IPs associated with VPN exit nodes, Tor relays, and proxies.
3. Reverse DNS patterns — VPN providers often set PTR records containing keywords like "vpn", "exit", "relay", or the provider name.
4. WebRTC leak detection — Even with a VPN, browsers can expose your real local or public IP via WebRTC. We check for this in a separate test.
5. IPv6 leak check — If your VPN only tunnels IPv4, your IPv6 address may leak. We detect this by checking whether IPv4 and IPv6 resolve to different ASNs.

What "VPN Detected" means

A "VPN detected" result means at least two strong signals match. It does not mean we know which VPN you use — only that the IP shares characteristics common to VPN exit nodes.

False positive rate

Corporate NAT gateways and some university networks can trigger a false positive. If you're not using a VPN but we detect one, your IP may route through a shared business network that resembles a proxy.

Download speed methodology

We download test payloads of increasing size (1 MB → 5 MB → 25 MB) from our CDN endpoint using the browser Fetch API with ReadableStream. We measure throughput in real time during the transfer, not just start-to-end time. This avoids skewing results due to TCP slow-start on small files.

Upload speed methodology

We generate random binary data client-side and POST it to our endpoint using XHR with upload.onprogress events. Upload results are measured at the 25th–75th percentile of transfer rate to ignore initial TCP handshake overhead.

Latency (ping)

We send 10 lightweight HEAD requests to our server and measure round-trip time using the Performance API (performance.now() with sub-millisecond precision). The median of 8 samples (discarding high/low outliers) is reported.

What affects your result

• Other active downloads or streams on the same network
• Wi-Fi vs wired connection (Wi-Fi adds 10–30% variance)
• Device CPU speed (JavaScript is single-threaded)
• Time of day / ISP congestion
• VPN overhead (typically reduces speed 10–40%)

How ping is measured

We make repeated HTTP HEAD requests (configurable: 12–50 samples) to a lightweight endpoint and record round-trip time using the Performance API. The first 2 samples are discarded as warm-up, then average, min, and max are calculated from the remaining samples.

How jitter is calculated

Jitter = the average of the absolute differences between consecutive ping values. Formally: jitter = mean(|ping[i] - ping[i-1]|). This is the standard RFC 3550 jitter definition used in VoIP quality measurement.

Reference values

Query method

DNS queries are executed server-side via our /api/dns-query endpoint, which uses Node.js dns.promises to query the authoritative resolver chain. This avoids browser DNS caching and gives you authoritative answers, not your local resolver's cache.

Record types we support

• A / AAAA — IPv4 and IPv6 address records
• MX — Mail exchange records (with priority)
• TXT — Text records (SPF, DMARC, DKIM, domain verification)
• CNAME — Canonical name / alias records
• NS — Authoritative name server records
• SOA — Start of authority (serial, refresh, retry, expiry)
• PTR — Reverse DNS pointer records

TTL and propagation

We display raw TTL values as returned by the authoritative server. DNS changes can take anywhere from minutes (low-TTL records) to 48 hours (default 86400s TTL) to propagate worldwide. Our lookup shows the current authoritative value, not what your ISP's resolver has cached.

Data sources

WHOIS queries are routed to the appropriate registry based on TLD:

• .com / .net → Verisign → then registrar WHOIS
• .org → PIR registry
• Country TLDs → Respective country NIC
• IP WHOIS → ARIN (North America), RIPE (Europe), APNIC (Asia-Pacific), LACNIC (Latin America), AFRINIC (Africa)

GDPR redaction

Since 2018, ICANN-compliant registrars redact personal data (name, address, phone) for individual registrants under GDPR. You will see "REDACTED FOR PRIVACY" for most .com domains. This is expected behaviour, not a data error.

What we check

Our SSL checker connects to the domain on port 443 via a server-side probe and retrieves the full certificate chain. We then verify:

• Validity period — Not-before and not-after dates
• Common Name & SANs — Whether the domain matches the certificate
• Chain completeness — Intermediate certificates are present and trusted
• Issuer / CA — Certificate Authority identity
• Key size — RSA ≥2048 bit or ECC ≥256 bit flagged as secure
• Cipher grade — TLS 1.2 minimum, TLS 1.3 recommended
• HSTS — Whether HTTP Strict Transport Security header is present

Expiry warnings

We flag certificates expiring within 30 days as "warning" and within 7 days as "critical". Certificates issued by Let's Encrypt expire every 90 days and must be renewed by your server's automation.

Lists we check

We query DNS-based blocklists (DNSBLs) for the queried IP across the following categories:

How DNSBL queries work

We reverse the IP octets and append the DNSBL domain. For example, to check 1.2.3.4 against zen.spamhaus.org, we resolve 4.3.2.1.zen.spamhaus.org. An A record response means "listed". No response (NXDOMAIN) means "clean".

Scan method

Our port scanner performs TCP connect probes from our server to the target IP/hostname. We attempt a full TCP handshake (SYN → SYN-ACK → ACK) and classify the result:

• Open — Three-way handshake completed. A service is listening.
• Closed — Connection refused (RST received). Port is reachable but no service.
• Filtered — No response (timeout). Firewall is likely blocking.

Ethical use policy

Port scanning is only performed on IPs you are authorised to test. Our tool rate-limits to 20 ports per scan and logs abuse attempts. Do not use this tool to probe networks you do not own. See our Terms of Use.

Common ports reference

What we parse

Email headers are pasted as raw text and parsed entirely in your browser (no server upload). We extract and explain:

• Received chain — Full hop-by-hop routing path with timestamps
• From / Reply-To / Return-Path — Sender identity (check for spoofing)
• Message-ID — Unique identifier for tracking
• X-Originating-IP — Sender's IP if exposed
• SPF result — Whether the sending server was authorised
• DKIM result — Whether the email signature is valid
• DMARC result — Combined SPF+DKIM policy enforcement
• Spam score — X-Spam-Status headers from filtering services

Privacy

Email header parsing runs entirely client-side in JavaScript. Your pasted headers are never sent to our servers. Close the browser tab and the data is gone.

How to get email headers

• Gmail: Open email → ⋮ menu → Show original → Copy to clipboard
• Outlook (web): Open email → ⋯ → View message source
• Apple Mail: View menu → Message → All Headers
• Thunderbird: View → Headers → All

What is a WebRTC leak?

WebRTC (Web Real-Time Communication) is a browser API used for video/audio calls. To establish peer-to-peer connections, it uses STUN/TURN servers to discover your real IP address — even when behind a VPN. This exposes your local and public IP to any website using WebRTC.

How we detect it

We create an RTCPeerConnection using STUN servers (stun.l.google.com, stun1.l.google.com) and parse onicecandidate events to extract all IP addresses your browser exposes. We compare these against your current detected IP to flag leaks.

How to fix a WebRTC leak

• Firefox: Set media.peerconnection.enabled to false in about:config
• Chrome/Edge: Use a browser extension like uBlock Origin (with WebRTC blocking enabled)
• Use a VPN that handles WebRTC — Good VPNs route WebRTC through the tunnel or block it entirely

Found an error or outdated information? Contact us — we review every submission.