Internet speed test

How this tool works

Press start and the page runs 3 measurements in sequence, all from your browser to our server. There is nothing to install and no account.

Latency and jitter. The browser sends a series of tiny requests to a lightweight endpoint on our server and times each round trip. The lowest value is reported as latency and the variation between them as jitter. Browsers cannot send ICMP, so this is an HTTP round trip rather than a classic ping, but it follows the same path. The ping tool explains the difference.

Download. The browser fetches test files of 1 MB, 5 MB and 10 MB from our server, with caching disabled, and times each one. Larger files are used so that the connection has time to ramp up; a TCP connection starts slowly and reaches full speed only after a moment, which is why a very short test underestimates a fast line. Throughput is computed from the bytes received and the time taken, and the best sustained figure is shown.

Upload. The browser generates random data and sends it to a receiving endpoint on our server that counts the bytes and discards them. The upload figure is computed the same way as the download.

The test uses a single server location. That is the honest part most tests gloss over: the result is the throughput between your device and our server, over the particular path between them, at this moment. A server a few hundred kilometers away and a server on another continent give different results for the same connection, and this test does not choose the nearest of many servers for you.

Results are shown in megabits per second (Mbps), the unit ISPs quote. Divide by 8 for megabytes per second.

How to read the result

Download is the figure most people care about: how fast content arrives. Streaming, browsing and downloads all depend on it. A result well below your plan does not automatically mean the ISP is at fault; see the next section.

Upload matters for video calls, sending files, cloud backups, screen sharing and live streaming. Most home plans give far less upload than download, and a call that stutters on a connection with fast download is usually an upload or jitter problem.

Latency is the round-trip time to our server. Distance sets the floor: light in fiber travels roughly 200 kilometers per millisecond, so a server 3,000 kilometers away cannot answer in less than about 30 milliseconds. Numbers far above what distance explains point at a slow local network, a congested ISP link or a detour through a VPN.

Jitter is how much the latency wobbles. A connection with 20 milliseconds of latency and 2 of jitter feels better for calls and games than one with 15 milliseconds of latency and 30 of jitter, because applications can plan for a steady delay but not for spikes.

A rough guide to what speeds are enough for common uses, as published by most streaming and conferencing services, is below. Treat it as orientation, not a standard.

How to get closer to the speed you pay for

Work through these in order. Each step removes one possible bottleneck and the test tells you whether it mattered.

1. Test by cable. Connect the computer to the router with an Ethernet cable and run the test again. If the result jumps, Wi-Fi was the limit. Wi-Fi speed drops with distance, walls and interference from neighbors; moving the router, switching to the 5 GHz band or adding an access point fixes most of it.
2. Stop other traffic. Pause downloads, cloud backups, streaming on other devices and game updates. One device saturating the connection, especially the upload, drags everything else down and raises latency for everyone.
3. Reboot the modem and router. Consumer equipment degrades over weeks of uptime. A reboot is quick and surprisingly often restores full speed.
4. Check the router's WAN link. Log in to the router and look at the connection speed it negotiated with the modem or ONT. A gigabit plan behind a 100 Mbps WAN port, or a port that negotiated 100 Mbps because of a damaged cable, caps at 100.
5. Update firmware and drivers. Old router firmware and old network drivers on the computer both cause slow, unstable throughput.
6. Disable the VPN or proxy for the test. Then re-enable it and test again to see what it costs. If the difference is large, pick a server closer to you or a faster protocol. The proxy checker confirms whether traffic is actually going through the tunnel.
7. Try another browser and device. Browser extensions, antivirus web filters and an overloaded computer can all slow the test without the network being at fault.
8. Test at different times of day. Speed that is fine at 10 in the morning and halves at 9 in the evening is congestion in the ISP's network. Record the results with times; the ISP will ask for them.
9. Compare with a second server. Run a test to a server in another location. If both are slow in the same way, the limit is near you; if only one is, the limit is on the path to that server.
10. Contact the ISP with the cabled results, the times, and the router's negotiated speed. That is the evidence that gets a line checked rather than a scripted reply.

Why speed tests disagree with each other

Two tests run a minute apart can differ by a wide margin, and that is not a sign that one is lying. The server location, the number of parallel connections the test opens, the file sizes, how the test handles the slow start of a TCP connection, and whether the test server is itself busy all change the number. A test that opens many connections at once to a nearby server shows the raw capacity of the last mile; a single-connection test to a distant server, which is what this page runs, shows what one download from a far-away site actually achieves. Both are true, and the second one is closer to everyday experience for anything not served from a nearby cache.

Latency is affected less by these choices and is the more comparable number between tests.

What speed means for proxies and VPNs

For anyone running traffic through a proxy or VPN before logging in to an account, throughput is only part of the picture. Each tunnel adds its own latency, and a server that is far from both you and the site you are visiting adds the detour twice. Measure latency and jitter with the tunnel on and off; a small drop in download speed is normal, but latency that doubles or jitter that explodes means the server is overloaded or badly placed. The traceroute tool shows the path from our probe to the tunnel endpoint, which helps judge where it sits.

Bits, bytes and overhead

Internet plans are sold in megabits per second and most software reports megabytes per second, which causes much of the confusion around speed tests. A byte is 8 bits, so a 100 Mbps plan corresponds to 12.5 MB/s in theory. In practice a download manager on that line shows a little under 12 MB/s, because every packet carries headers for TCP, IP and the link layer that are not part of the file. Losing a few percent to that overhead is normal and no test can recover it.

The same arithmetic tells you how long a transfer should take. At 50 Mbps, a 1 GB file needs about 160 seconds if the line is the only limit; if it takes 10 minutes, something else is the bottleneck, and the steps above are the way to find it.

Download speed versus latency: what you actually notice

The headline number is download speed, but for most everyday use it stops mattering above a modest level. Web pages are made of many small requests, and each one costs a round trip before any data flows, so a page on a 300 Mbps line with 80 milliseconds of latency loads more slowly than on a 50 Mbps line with 10 milliseconds. Video calls and games depend on latency and jitter almost entirely. Large downloads, 4K streams and cloud backups are the cases where raw throughput dominates.

If the download figure looks fine but everything feels sluggish, look at the latency and jitter lines first, then at the upload figure, which, when saturated by a backup or an upload in the background, pushes latency up for every other application on the connection.

Testing from the command line

For a server, a VPS or a headless machine the browser test does not apply. A quick throughput check from a shell is curl -o /dev/null -w "%{speed_download}\n" https://example.com/large-file, which prints bytes per second for a download from any URL, including the test files on this site. For a controlled measurement between two machines you manage, install iperf3 on both, run iperf3 -s on one and iperf3 -c <address> on the other; add -R to measure the reverse direction and -u -b 50M for a UDP test with a target rate that also reports jitter and loss. Those numbers are the throughput of the path between the two hosts with no browser in the way, which is the fairest way to compare hosting providers or to confirm what a server's port can actually deliver.

Speed on mobile connections

On a phone, the test reflects the radio link at that moment: the band, the signal strength, how many other users share the cell and whether the phone is on Wi-Fi or cellular. Results swing far more than on a fixed line, so run several and look at the range rather than one number. Mobile latency is higher than fixed-line latency by nature, and jitter is the figure most affected by moving between cells or by a weak signal. If a mobile test is much slower than expected, switching the phone's Wi-Fi off and on, or moving a few meters, often changes the result more than anything the carrier controls.

Limits of this tool

• The test measures the path to one server in one location. It does not select the nearest of many servers, so users far from it see lower throughput and higher latency than a nearby test would report.
• Our server has finite capacity. On a very fast line, the result may be limited by the server or by its hosting network rather than by your connection.
• The test runs in a browser. Browser overhead, extensions and the device's CPU cap the achievable figure, especially on phones and older computers. Multi-gigabit connections cannot be measured accurately this way.
• Download uses files of at most 10 MB. On very fast connections the transfer ends before TCP reaches full speed, which understates the result.
• Latency is measured with HTTP requests, which adds a small, fairly constant overhead compared with ICMP ping.
• One run is a snapshot. Background traffic, a busy moment at the ISP or on our server, and radio conditions change the result from run to run.
• The test cannot tell you whether a slow result is caused by your device, your Wi-Fi, your ISP or the path to our server. The steps above are how you find out.
• There is no account, so the page keeps no history of your results across visits; note them down if you are building a case for your ISP.