Measure the download speed, upload speed, latency and jitter of the connection you are using right now. The test transfers real data to a server on Cloudflare's network and reports how much it used, so the figures come from real transfers rather than simulation.
The whole run takes about twenty seconds. It downloads and uploads real data, so on a metered mobile plan it will use part of your allowance; the exact amount transferred is shown with the result.
A speed test measures how fast data moves between your device and a server. This one runs real transfers to Cloudflare's network and reports download, upload, latency and jitter, plus the exact amount of data used — nothing is simulated. Takes about twenty seconds, in megabits per second, the decimal unit providers advertise.
What Is a Speed Test and What Does This Tool Do?
What does this tool do?
It runs three separate measurements. First it sends a series of tiny requests and times each round trip, which gives latency and jitter. Then it downloads several megabytes and times the transfer, which gives download speed. Then it uploads several megabytes and times that, which gives upload speed. The size of each transfer adapts to how fast your connection turns out to be, so a slow link is not made to move forty megabytes, and the total amount of data used is reported with the result.
Every figure is calculated from data that actually moved, and if part of the test cannot run, that part is left blank rather than filled in with a guess.
Why is this useful?
Because the speed on your bill is the speed to your building, not the speed at your desk. Old Wi-Fi hardware, distance from the router, a congested evening, a neighbour on the same cable segment or a VPN can all take a large bite out of it. Measuring from the device you are actually using tells you what the applications on that device have to work with, and comparing a Wi-Fi result against a cabled one usually settles the question of whether the problem is your connection or your network.
Who uses this tool?
• People checking a new connection: confirm you are getting roughly what you are paying for after an installation or an upgrade.
• Anyone whose video calls break up: latency and jitter matter far more than raw speed for calls, and this shows both.
• Remote workers: check upload speed, which is what carries your camera and your file transfers, and which is usually much lower than download.
• People diagnosing Wi-Fi: run the test beside the router and again in the far room to see what the walls cost you.
• Gamers and streamers: a stable, low-jitter connection matters more than a big number.
How Do You Use This Tool?
1. Close other downloads, streams and backups first, otherwise you are measuring what is left over rather than what you have.
2. Press Start test and leave the tab in the foreground until it finishes.
3. Watch the dial and the status line. The dial fills while a transfer is still running and shows the average of everything measured up to that instant, so on a slow connection you can see the run progressing instead of a line that sits unchanged for a minute. The status line names the stage and the megabytes used.
4. Press Stop at any point to abandon the run. It cancels the transfer in progress rather than just hiding it.
5. Run it two or three times, a minute apart, and use the best result. A single run can be spoiled by a moment of congestion.
Example results for three sample connections
These are illustrative figures, not recorded measurements. The data totals were worked out by hand from the transfer rules in How the results are calculated, so a real run will land close to them rather than exactly on them.
| Scenario | Download and upload | Latency and jitter | Data transferred (approx.) |
|---|---|---|---|
| Home fibre sold as 40 Mbit/s, tested on a cable | 38.6 Mbit/s down, 21.4 Mbit/s up | 34 ms median, 3 ms jitter | About 57 MB |
| The same line from a laptop two rooms away on 2.4 GHz Wi-Fi | 14.2 Mbit/s down, 8.5 Mbit/s up | 36 ms median, 4 ms jitter | About 23 MB |
| Older DSL line sold as 4 Mbit/s | 3.2 Mbit/s down, 0.6 Mbit/s up | 62 ms median, 12 ms jitter | About 6.5 MB |
Reading them. The first row is a healthy result: download within a few percent of the advertised figure, and jitter small enough for video calls. The second row is the same line, and latency barely moved. That is the clue: the connection to the internet is fine and the Wi-Fi hop is the bottleneck, so arguing with the provider will not improve that number. In the third row the download is about a fifth below the advertised figure and upload is thin, which on a long old copper line is common but worth raising with the provider if it persists. The data totals differ because the transfer sizes adapt: the fast line moves roughly nine times as much data as the slow one.
What is being measured
The result describes the whole path, not just the line you pay for. That is why a poor Wi-Fi hop caps the number while latency stays normal, and why a wired run is the fairest test of the connection itself.
How Do You Read the Results?
Download speed
Bytes arriving divided by the time they took, in megabits per second. Timing starts when the first byte lands, so the delay before the transfer begins is left out of the throughput figure and reported as latency instead.
Normal: close to the advertised speed on a cable, and lower over Wi-Fi. Worth a second look: a figure far below the plan on a cabled connection, or one that swings widely between runs a minute apart.
Upload speed
The same measurement in the other direction, timed from the first byte leaving your device until the server confirms it has received the lot. On most home connections it is far lower than download, which is usually a deliberate choice by the provider rather than a fault.
Normal: well below download on cable and DSL, and close to download on full fibre. Worth a second look: "not measured" while download worked, which often points to a firewall or extension blocking uploads.
Latency
Ten tiny requests are sent and every round trip is timed. All ten count, because the connection to the test server was already open before the first of them left — it was opened while the page was finding a server that answers — so none of the ten carries the setup cost. The figure is the median of the requests that came back, with the fastest of those beside it, and if fewer than ten answered the row says how many did. The median is used rather than the average so one delayed sample cannot distort it. Under roughly 50 ms feels immediate; above 150 ms is noticeable on a call.
Normal: under about 50 ms to a Cloudflare site near you. Worth a second look: above 150 ms, or a sudden jump after you switched on a VPN, which sends your traffic on a detour.
Jitter
The average change from one round trip to the next. Low jitter matters more than raw speed for calls and games, because audio and video need packets arriving at a steady rate, not merely arriving quickly. It needs two answered requests before it means anything, so when only one came back the row says it was not measured instead of showing zero. The standards body's term for this is delay variation (RFC 3393); this tool uses a simpler version based on round-trip times rather than one-way delays.
Normal: under about 10 ms. Worth a second look: above about 30 ms, the usual reason a call breaks up even though the speed looks fine.
First connection
The first request made to the host that ends up answering — the one that goes looking for a test server — timed on its own. It carries the DNS lookup and the TCP and TLS handshakes, which is why it is normally much slower than the latency figure and says very little about the speed of the connection itself. When the address that finally answers is not the first one tried on that host, the connection was already open by the time the working path was found, and the row says the setup cost was not isolated rather than passing a warm round trip off as a cold one. On a run started moments after the last one, the browser may still be holding that connection open, so the figure can read much like latency.
Normal: noticeably higher than latency, often by a few hundred milliseconds at most. Worth a second look: a figure of several seconds, which may point to slow DNS or a filtering network.
Data transferred
How many megabytes the run actually used, download and upload together. Worth reading before you repeat the test on a metered mobile plan. It counts the payload bytes the test moved; headers and protocol overhead are not included, so real usage is a little higher.
Normal: a few megabytes on a slow line up to several tens on a fast one. The stage limits keep a run below roughly 70 MB.
Test server, Tested from, and Cloudflare location
Test server names the host that actually answered, since more than one is tried. Tested from is your network's name and approximate location, read from our own lookup service at ip.myipshow.com, falling back to the test server's own response headers and reading "Not available" if neither can name it. Cloudflare location is the edge site that served the transfer, taken from the response headers when they can be read. None of the three changes the measurement; they record where it was taken.
Normal: speed.myipshow.com and a Cloudflare site in or near your country. Worth a second look: a far-away location, which is common behind a VPN, or a fallback host, which means the first one could not be reached.
What this tool cannot tell you
• It is not your line's maximum. Wi-Fi, an older device, browser overhead and anything else using the connection at the time all cap the figure.
• One server, one network. The same connection tested against a server in another country, or on another provider, can return a different number.
• No packet loss. Ordinary web requests do not expose individual packets, and the operating system retransmits anything lost before the page finds out, so a loss figure worked out from them would be a guess. The old packet loss reading has been removed rather than estimated from something else.
• Upload is measured conservatively. The clock runs until the server confirms it has the data, so one round trip is included and a very fast link can read a little low. It is also why the dial holds still during an upload while the megabyte count keeps climbing: the browser can say how many bytes it has handed to the connection, but that runs ahead of what has crossed the network, and no figure goes on the dial that the result would not stand behind.
• It cannot say where a bottleneck is. The whole path arrives as one number; comparing a Wi-Fi run with a cabled one is how you narrow it down.
• It is not a test of any one service. A streaming or gaming service may reach you over a different route, so a good result here does not guarantee that service will perform well.
Download, Upload, Latency and Jitter: Which Number Matters?
Most people look at the biggest number and stop. The four figures answer different questions, and the one that explains a problem is often not the one in large type. The table sets them side by side.
| Measurement | What it describes | Matters most for | Common misreading |
|---|---|---|---|
| Download speed | How much data arrives per second | Streaming, large downloads, updates | A faster plan can fail to help if the Wi-Fi hop is the real limit |
| Upload speed | How much data leaves per second | Video calls, cloud backups, sending large files | Expecting it to match download, when many plans set it lower by design |
| Latency | How long one small request takes to be answered | How responsive browsing, calls and games feel | Treating it as speed: a link can be fast and still have high latency, for example behind a VPN |
| Jitter | How much that delay changes from one request to the next | Calls, live video and games | Ignoring it because the average latency looks fine |
How the Results Are Calculated
Every figure this tool reports comes from bytes that actually moved during your run. The run is arranged in four stages, and each stage feeds the next: a server is found first, then latency is sampled against it, then download runs, and upload runs last against a server that was verified to accept a body.
Stage 1: finding a server that answers
Three hosts are tried in a fixed order — MyIPShow's own endpoint at speed.myipshow.com (a Cloudflare Worker), then the same Worker on its workers.dev fallback address, then Cloudflare's own public speed test endpoint at speed.cloudflare.com. On the first host three download paths (/__down?bytes=, /download?bytes=, /?bytes=) and three upload paths (/__up, /upload, /) can be attempted; the other two hosts have one path each. If a host does not answer at all, the next host is tried straight away. A probe only wins if it returns a body of the requested size, 2,000 bytes, give or take two hundred. The upload probe starts at the host that served the download, so upload normally uses the same host, and the result shows both names when they differ. The result names whichever host actually answered, because the responders are not the same machine.
Stage 2: latency and jitter
Ten requests, each asking for ten bytes, are sent to the winning download path, spaced seventy milliseconds apart, and every round trip is timed individually. All ten samples count towards the figure. The reason none is dropped as a warm-up is that the connection to that host was already open from the probe stage — the first handshake was paid before the pings began — so there is no cold request among the ten to hold back.
The Latency row is the median of the samples that returned, not the average, so a single delayed reply cannot drag the figure. The fastest sample is shown beside it. If fewer than ten requests came back, the row says how many did, and if none came back it reads not measured rather than 0 ms.
The Jitter row is the average of the absolute change between each round trip and the one before it. It needs at least two answered samples before the figure means anything, so a single reply produces not measured, not a zero.
Stage 3: download and upload
Each direction runs a warm-up transfer first, and the speed from that warm-up picks the size of the transfers that are actually counted:
• Download. A 1 MB warm-up. Under 5 Mbit/s, the counted transfers are 2 MB each; under 25, 5 MB; under 100, 10 MB; 100 and above, 25 MB. The stage stops once 8 seconds of counted transfer time have built up or it has moved 50 MB, whichever comes first.
• Upload. A 500 KB warm-up, scaled the same way: under 2 Mbit/s uses 1 MB transfers, under 10 uses 2 MB, under 50 uses 5 MB, 50 and above uses 10 MB. The stage stops at 5 seconds of counted time or 20 MB.
Download speed is the number of bytes received, times eight, divided by the elapsed time in seconds, divided by a million. The clock starts when the first byte of a transfer lands, so the delay before a transfer begins is left out of the throughput figure and shows up as latency instead. Upload uses the same formula but starts its clock when the first byte leaves and stops only when the server confirms it has the whole body, which folds one round trip into the measurement. That is deliberate: it is why a very fast link can read slightly low on upload, and why the dial holds still during an upload while the megabyte count keeps climbing.
Stage 4: first connection, data used, and where the labels come from
The First connection row is the first probe request sent to the winning host, timed on its own so that it carries the DNS lookup, the TCP handshake and the TLS handshake. It is only reported when that probe was genuinely the first request made to that host during the run. When the winning path was found on a second or third attempt on the same host, the connection was already open by the time the working path was discovered, and the row says the setup cost was not isolated rather than passing a warm round trip off as cold.
Data transferred is the sum of every payload byte moved during the run — probes, warm-ups and counted transfers alike — not just the two transfers that produced the download and upload figures. Headers and protocol overhead are not counted.
Tested from comes from our own lookup service at ip.myipshow.com. If that lookup fails, the test server's own response headers are read instead. If neither can name the network, the row reads Not available rather than being dropped. Cloudflare location is taken from the cf-meta-colo response header, falling back to the suffix of the cf-ray header when the first is missing.
What is deliberately left out
• No packet loss. Ordinary web requests do not expose individual packets, and the operating system quietly retransmits anything lost before the page finds out. A packet loss percentage worked out from them would be a guess, so the reading was removed rather than estimated.
• No live upload speed. The upload progress event counts bytes the browser has accepted for sending, which runs ahead of what has actually crossed the network. Turning that into Mbit/s would put a number on screen that the Upload row is built to avoid, so only the byte count moves during an upload and the speed figure appears when the transfer is confirmed complete.
• No warm-up in the result. The warm-up transfer is timed but excluded from both speed figures on purpose. The dial is reset to zero before the transfers that count begin, so a warm-up reading never appears beside a counted one.
When Would You Use This Tool?
Checking a new connection
Run it wired, or as close to the router as you can, and compare the download figure with what you were sold.
Calls that break up
Read latency and jitter before download speed. Unstable delay ruins a call that plenty of bandwidth cannot save.
Working from home
Upload carries your camera and your file transfers, and it is the number most home plans are thinnest on.
Mapping Wi-Fi dead spots
Test in each room. Where speed collapses but latency holds steady, the Wi-Fi is at fault, not the line.
Planning a big transfer
A 2 GB upload over a 20 Mbit/s link takes about thirteen minutes. Knowing the number sets the expectation.
Before calling support
Two or three timestamped results, taken at different times of day, make the conversation much shorter.
What Speeds Do You Need for Common Activities?
Speeds are quoted in megabits per second, decimal, so 1 Mbit/s is one million bits. A file size in megabytes is eight times larger than the same figure in megabits, which is why a 25 Mbit/s connection downloads at roughly 3 MB per second. For reference, as of October 2026 the United States raised its fixed broadband benchmark to 100 Mbit/s down and 20 Mbit/s up in 2024, and Netflix recommends 15 Mbit/s or higher for 4K. The figures below are rough guides, not guarantees, and services change their recommendations from time to time.
| What you are doing | Download needed (rough guide) | Also matters |
|---|---|---|
| Browsing, email, messaging | 1 to 5 Mbit/s | Latency, for pages that feel snappy |
| HD video (720p), one stream | 3 Mbit/s or more | Steady speed rather than a high peak |
| Full HD video (1080p), one stream | 5 Mbit/s or more | Add for each extra viewer |
| 4K video, one stream | 15 Mbit/s or more | Sustained speed for the whole film |
| HD video call | 3 to 4 Mbit/s | Upload and jitter, far more than download |
| Online gaming | 3 to 6 Mbit/s | Latency and jitter decide the experience |
| Sending large files or backups | Download matters little | Upload speed above all |
What If Speed Is Not the Problem?
A connection can be fast and still feel broken. If pages hesitate before loading, or a call stutters while a download runs happily in the background, the number to look at is delay rather than throughput. The ping tool measures response time against any host you name, which is more useful than a single figure against one server. A VPN is the other common culprit, since it adds a detour and its own encryption overhead to every packet: the VPN checker will tell you whether your traffic is going through one.
About the data
The transfers go to MyIPShow's own test server at speed.myipshow.com, a Cloudflare Worker, so the machine you measure against is normally the Cloudflare location nearest you. If that name cannot be reached the page tries the same Worker's workers.dev address, and then Cloudflare's own public speed test endpoint, so a result is still possible while the Worker is down. The result names whichever host answered. The measurements are taken live in your browser during each run, not looked up from a database. The network name shown with the result comes from our own lookup service at ip.myipshow.com, or from the test server's own response headers when that is unavailable. That service draws on Cloudflare Radar and ipwho.is, and may keep an address's result for up to six hours (thirty minutes when no city was found). The test servers and that service see your IP address, as any server you connect to does. This page does not store your results: the recent results list lives in your own browser and the Clear button deletes it.
What Other Tools Work With This One?
Sources and Further Reading
• FCC: increase of the fixed broadband speed benchmark (2024): the US regulator's move to a 100 Mbit/s down, 20 Mbit/s up benchmark.
• Netflix-recommended internet speeds (Netflix Help Center): the service's own figures for HD, Full HD and 4K streaming.
• RFC 3393, IP Packet Delay Variation Metric (IETF): the standard definition of delay variation, the formal name for jitter.
Frequently Asked Questions
Why is my speed lower than what I pay for?+
The figure you pay for is the speed to your building under ideal conditions, and it is usually described as up to that number. Wi-Fi, the age of your device, other people in the house and the busy evening hours all take a share. A result within about ten percent of the advertised speed on a wired connection is often considered healthy.
Why is upload so much slower than download?+
Because many home connections are designed that way. Cable and DSL technologies divide the available capacity unevenly on the assumption that people consume far more than they send, so an upload speed of a tenth of the download is common. Full fibre connections are the exception and are often symmetric.
What counts as good latency and jitter?+
As a rough guide, under 50 ms of latency feels immediate for browsing and is comfortable for calls and most games. Between 50 and 150 ms is usable but noticeable, and above 150 ms conversations start to overlap. Jitter under about 10 ms is good, and jitter above 30 ms is the usual reason a call breaks up even though the speed test looks fine.
How much data does this test use?+
It depends on how fast your connection turns out to be, because the transfer sizes adapt: a slow link is measured with a few megabytes, a fast one with more. The exact total is reported with the result so you can see what it cost, which is worth checking before repeating the test on a metered mobile plan.
Does a VPN slow the test down?+
Usually, yes. Your traffic takes a detour to the VPN server before it reaches anything else, and it is encrypted and decrypted on the way, which adds latency and often costs some throughput. If you want to know your line speed, test with the VPN switched off, then switch it on and compare.
Why do two runs give different numbers?+
Because a network is shared and conditions change from second to second. Another device starting a download, a neighbour on the same cable segment, or ordinary congestion between networks will all move the result. Run the test two or three times a minute apart and treat the best figure as the closest to your real capacity.
Why does this tool not show packet loss?+
Because ordinary web requests do not expose packets. Browsers report requests and responses, not the individual packets underneath them, and the operating system retransmits anything lost before the page finds out. A packet loss percentage worked out from ordinary requests would be a guess, so this page reports what it can measure instead.
Should I test over Wi-Fi or a cable?+
Use a cable to judge the connection itself, since it removes the most common bottleneck from the measurement. Use Wi-Fi when the question is what a particular room or device actually gets. Running both is the fastest way to find out whether to fix your network or complain to your provider.
Which server does the test measure against?+
A server on Cloudflare's global network, so the machine at the other end is normally the Cloudflare location nearest you rather than one in another country. The page tries MyIPShow's own endpoint first and falls back to Cloudflare's public speed test endpoint if that one cannot be reached, and the result names whichever host answered. If neither responds, the test says so plainly instead of showing a number, which usually means an ad blocker, a privacy extension or a firewall is blocking the requests.
How the Internet Speed Test Works
What it measures: Download speed and upload speed in megabits per second (Mbps), plus latency and jitter in milliseconds.
What it is based on: Throughput is how much data moves per second between your device and the test server. Latency is round-trip delay (RFC 2681), and jitter is the variation in delay between packets (RFC 3393).
Limits of the result: Results are capped by your Wi-Fi signal, your device, other people using the connection, the distance to the test server and the time of day. The test shows the path to the test server, not to every website. For the most reliable figure, use a wired connection and run it more than once.
Sources: RFC 2681 (round-trip delay) · RFC 3393 (delay variation) · Cloudflare: what is latency?
Last reviewed October 4, 2026 · Editorial Policy · How our tools work
Comments:
Post a Comment