RunTheTests
/

Connection tools

46 tools that run in your browser. Nothing to install, nothing uploaded.

Every one of these connection tools runs in your browser or against public resolvers — none require an account, and none upload your files. They cover the two things people actually need to check: what your connection reveals about you (your IP, location and network operator, read at our edge) and whether a domain’s DNS and mail records are set up correctly. The DNS tools query two independent public resolvers so you can see where they disagree, which is the honest version of a propagation check.

Two different jobs live in this category

Half of these tools look outward at your own connection: the address and network operator the internet sees, the route your traffic takes, latency and jitter, throughput up and down, and whether the line falls apart when somebody else in the house starts a download. The other half look at a domain’s public records: which nameservers are authoritative, where a CNAME chain finally lands, which mail servers accept its mail, and what its SPF, DMARC and CAA records permit. They share a page because they answer the same practical question from opposite ends — when something will not load or mail will not arrive, the fault is either your connection or the other side’s configuration, and these tell you which.

Why speed is rarely the number that matters

Almost everyone reaches for a speed test, and for almost every complaint it is the wrong measurement. Video calls, gaming and general responsiveness are decided by latency, jitter and loss, not by peak throughput — a 500 Mbps line with 200 ms of jitter under load is a worse call than a 30 Mbps line that stays steady. The specific failure behind most “my internet is fine but calls break up” reports is bufferbloat: throughput is fine, but the moment the link is saturated, latency climbs by hundreds of milliseconds because an oversized buffer refuses to drop anything. Run the latency and bufferbloat tests before the speed test, and you will usually have your answer already.

What a DNS check here can and cannot prove

The lookup tools query independent public resolvers over DNS-over-HTTPS and show you each answer side by side, which makes them conclusive in one direction and suggestive in the other. If two resolvers return different records, the change is genuinely still propagating and you have proof. If they agree, all you have learned is that these resolvers agree — your ISP’s resolver, a corporate resolver, or a stale cache on your own machine can still be serving the old record until its TTL expires. That is why nothing here is labelled a global propagation check: to make that claim honestly you would need to query resolvers on every continent, and the tools that claim it mostly do not.

Where these measurements are weaker than the native tools

A browser cannot send an ICMP packet, so nothing here is ping in the strict sense — latency is measured with timed HTTPS requests, which include TLS and server handling and therefore read a little higher and a little noisier than the ping command on your own machine. Throughput is measured against one endpoint over one set of connections, so it is a floor rather than a ceiling for what your line can do. Where the difference matters, use these to establish that a problem exists and roughly where, then reach for ping, traceroute, mtr or dig to characterise it precisely. Several tools here exist specifically to make the output of those commands readable once you have run them.

Frequently asked questions

Is this the same as the ping command?

No. A browser cannot send ICMP packets, so latency here is measured with timed HTTPS requests, which carry TLS negotiation and server processing on top of the round trip. Expect readings a little higher and a little noisier than ping on the same connection. The relative picture — is latency stable, is jitter high, does it collapse under load — is still accurate, which is what the diagnosis actually turns on.

My speed test looks fine but calls still break up. What should I check?

Latency, jitter and bufferbloat, in that order. Real-time media cares about consistency far more than peak throughput, and the classic pattern is a connection that tests at hundreds of megabits and adds hundreds of milliseconds of delay the moment anything saturates the uplink. Run the bufferbloat test while nothing else is downloading, then again during a large upload — if latency climbs sharply, that is your answer, and it is usually fixable with smart queue management on the router.

Do the DNS tools show global propagation?

They query independent public resolvers and show each answer, which proves a change is still in flight when the answers differ. Agreement is weaker evidence: your ISP’s resolver, a corporate resolver or a cache on your own machine can still serve the old record until its TTL runs out. Nothing here is labelled a global propagation check, because making that claim honestly would need resolvers on every continent.

Why does my IP location show the wrong city?

Because IP geolocation is an inference from registry data and network routing, not a measurement. Accuracy is usually good at country level, unreliable at city level, and can be wildly wrong when your traffic exits through a carrier-grade NAT, a mobile network or a VPN — the address is then registered wherever that infrastructure lives, which may be hundreds of miles away. The tool reports its confidence rather than presenting a pin as fact.