IPv6 Test
Check whether your connection has working IPv6, which protocol your browser actually prefers, and how IPv6 latency compares to IPv4 across five global regions. No target needed, this tests the connection you are reading this on.
If you have no IPv6 the test takes about five seconds while that probe times out. A timeout is a result, not an error.
Hit run. There is nothing to type, because the thing being tested is the connection you are reading this on.
Your browser fetches separate hostnames for each family. One is reachable only over IPv4, one only over IPv6, and a third over both. Which of them answer tells us what your connection can actually do.
Each hostname is warmed once and then measured, and we take the median. The first request to any host carries DNS, TCP and TLS setup, which would otherwise dominate the comparison.
Then we repeat both families against five regions: South Africa, Germany, the United States, Singapore and Australia. That is the part that tells you whether a problem is yours or the path's.
The hostnames are served directly by our origin rather than through a CDN. That matters more than it sounds: behind a proxy the connection terminates at the edge, so the server sees the proxy's address family rather than yours, and any answer it gives you about IPv6 is really an answer about the CDN. It also means a client with no IPv6 route will often hang rather than fail quickly, which is why the IPv6 probe has a five second timeout. A timeout there is a legitimate result.
Dual stack means both protocols work. This is the normal, healthy result and what most residential and mobile networks now provide.
IPv4 only means your ISP, your router, or your operating system is not giving you IPv6. Nothing is broken, but you are relying entirely on a protocol that ran out of addresses in 2011.
IPv6 only is rare and usually deliberate: a lab, a test network, or a mobile carrier using NAT64 to reach the IPv4 internet on your behalf.
The result worth paying attention to is the one almost no other test shows you: which protocol your browser chose when both were available. Browsers implement Happy Eyeballs, described in RFC 8305, which races an IPv4 and an IPv6 connection against each other and uses whichever answers first. So having IPv6 and using IPv6 are two different things. If you are dual stack but your browser consistently picks IPv4, something on your IPv6 path is slow enough that the race is being lost, and that is worth investigating even though nothing appears broken.
On the protocol alone, no. IPv6 has a simpler header and no need for NAT, but the difference in a single request is not something a human can perceive.
In practice the difference is routing, not protocol. IPv6 traffic sometimes takes a longer or less well peered path than IPv4 to the same destination, and occasionally a much shorter one.
The number this tool gives you is the round trip difference between the two families to the same origin, which is the honest version of the question.
Treat that number as an indication rather than a benchmark. It is one client, one moment and one path, measured over a small number of samples. A difference of a few milliseconds either way means nothing. A difference of fifty or a hundred milliseconds means your IPv6 traffic is going somewhere very different from your IPv4 traffic, and on a tunnelled or badly peered IPv6 deployment that is exactly what happens. We do not attempt a throughput test, because a meaningful one needs a multi second sustained transfer and would tell you more about your last mile than about IPv6.
Leave it on. Disabling IPv6 is advice that circulates because it appears to fix things, and it usually does so by hiding the actual fault rather than repairing it.
The Windows status "IPv6 connectivity: no network access" is not a fault on its own. It very often appears on a working connection where the machine has a link local address and no route beyond it.
Where IPv6 genuinely causes slow browsing it is usually one of three things: a router advertising a prefix it cannot route, DNS returning AAAA records for hosts that are not actually reachable, or a tunnel adding real latency.
Turning IPv6 off does make those symptoms disappear, which is why the advice spreads. It also removes half the internet's addressing from your machine, breaks anything that is IPv6 only, and leaves the underlying misconfiguration in place for the next person. If this test shows IPv6 working with a sane latency delta, there is no case for disabling it. If it shows IPv6 present but your browser never picks it, that is the symptom to chase.
If IPv6 is missing entirely and you want it, the order to check is: whether your ISP offers it at all, whether your router has it enabled and is receiving a prefix, and only then your operating system. Most of the time it is the first of those, and no amount of local configuration will help.
Free Network & Website Tools
Ping Test
An essential latency test that measures real-time responsiveness and connection stability. It provides critical data on packet loss and round-trip times to ensure a consistent user experience.
Server Check
A comprehensive health audit that verifies server reachability, SSL validity, and CDN performance. It ensures your site is correctly configured and accessible across both modern and legacy IP versions.
Traceroute
A deep-path analysis tool that maps every network hop between the source and the target. It pinpoints the exact location of bottlenecks or failures within the global internet infrastructure.
DNS Lookup
Verify DNS record consistency across our global network. Check A, AAAA, MX, TXT, and more records from 5 regions with 4 public resolvers each.
MAC Address Lookup
Identify the manufacturer of any network device by its MAC address. Powered by the IEEE OUI database with real-time vendor details.
Robots.txt Tester
Analyze your site's robots.txt file for format errors, crawl rules, and get AI-powered optimization suggestions.
