Browser & connection test

What this tool checks

This test runs in your browser and stores nothing about you. When it finishes, it adds its yes/no results (IPv4 works, IPv6 works, WebRTC leak) to anonymous daily counts per country, published as connection statistics; browsers that send Global Privacy Control or Do Not Track are left out.

• IPv4 and IPv6. Your browser fetches a small address-echo endpoint from two test hosts, one reachable only over IPv4 and one only over IPv6. Each reports the address it saw. If a fetch fails within six seconds, that protocol counts as not reachable. This shows whether you have working IPv6, which What's my IP? can't, because a browser uses only one protocol per connection.
• Latency and jitter. The browser sends 12 small HTTPS requests to our server, one after another. The first is discarded because it includes opening the connection; the other 11 are timed.
• WebRTC leak test. The browser prepares a WebRTC connection using a public STUN server (named under the test), just as video-call sites do, and lists the addresses it would offer to a peer. The public ones are compared with the addresses our tests saw.
• What your browser tells websites. Time zone, languages, screen, the browser's own network estimate, cookie, Do Not Track and Global Privacy Control settings, CPU cores, device memory and touch support, plus the HTTP request headers our server received.

What it can't see: download and upload speed (this is not a speed test), packet loss along the route, or DNS leaks. Latency is measured to our server only.

Reading the results

IPv4 and IPv6. A green tick with an address means that protocol works. "Not reachable from your connection" means the request failed: usually no IPv6 from your provider, or a firewall or VPN blocking it. The line above shows which protocol this page itself arrived on.

Latency. Four values in milliseconds:

These are full HTTPS requests, so they read a few milliseconds above a plain ping. Jitter of a few milliseconds is normal on a cable; tens of milliseconds usually means busy Wi-Fi or a congested link, which is what makes calls choppy.

WebRTC leak test.

• No leak: every public address WebRTC revealed is one we already saw from you on the same IP version.
• Leak: WebRTC revealed a different public address. If you use a VPN, websites can learn your real address this way.
• Not compared: addresses of an IP version none of our tests saw from you, so there was nothing to compare. Common when a VPN carries only IPv4.
• WebRTC is disabled: the browser doesn't offer it, so it cannot leak.

Local addresses shows your LAN addresses or, in most current browsers, random names ending in .local that hide them.

Request headers are shown as received, except cookies, authorisation headers and proxy headers that repeat your address. "Country (Cloudflare)" is the country our CDN assigns to your address.

Common problems and fixes

IPv6 shows "Not reachable"

Check that IPv6 is enabled on your router and that it receives a prefix from your provider; many routers ship with it off. A VPN without IPv6 support may block IPv6 on purpose to prevent leaks, which is the safe behaviour. If your provider offers no IPv6, there is nothing to fix on your side.

WebRTC reports a leak while on a VPN

Your browser is offering an address outside the tunnel. Use the VPN's system-wide mode rather than a browser extension, make sure the VPN tunnels or blocks IPv6, or limit WebRTC in the browser (in Firefox, set media.peerconnection.enabled to false in about:config; Chromium-based browsers need an extension or policy that restricts WebRTC).

High jitter or "Slowest" spikes

Test on a cable instead of Wi-Fi, and pause large downloads and streams, then run it again. If jitter stays high on a quiet, wired connection, the congestion is beyond your router.

FAQ