How SpeedSnap Measures Your Connection

This page documents exactly what SpeedSnap does when you press Start, what each number on the results screen is calculated from, where the test server is, what gets stored, and — just as importantly — what this kind of test cannot tell you. It is written from the code that actually runs in your browser. If something here reads as a limitation rather than a selling point, that is deliberate: a speed test you cannot check is a speed test you cannot trust.

Last updated August 15, 2026 · Maintained by the SpeedSnap team

The test sequence, in order

A full run is five steps. Nothing is simulated and nothing is estimated from your device or browser type — every number comes from real traffic to and from the test server.

1. Reachability check. Before anything is measured, the browser makes one request to the test server with a 5-second timeout. If it fails, the test refuses to start and tells you the server is unreachable rather than showing you a made-up result.
2. First latency burst. 10 requests, with a 120 ms pause between them. The first 2 are discarded as connection warm-up.
3. Download. Exactly 15 seconds, 6 parallel connections, run inside a Web Worker.
4. Upload. Exactly 15 seconds, 6 parallel connections, also in the Web Worker.
5. Second latency burst. 20 requests, with a 100 ms pause between them, first 2 discarded again. This is the burst that produces the ping and jitter you see — it overwrites the reading from step 2.

The two transfer phases are exactly 15 seconds each, and the two latency bursts add a few seconds more, so a complete run takes a little over half a minute. If you stop the test partway through, the run is aborted and nothing is saved.

How download and upload speed are measured

Both throughput phases run in a Web Worker — a separate thread from the page. This matters more than it sounds: if the measurement ran on the main thread, the browser would be splitting its attention between rendering the animated gauge and processing incoming data, and the gauge would slow down the very thing it is displaying. Moving the transfer off the main thread removes that interference.

Download

Six connections open in parallel, staggered 300 ms apart so they do not all ramp up at the same instant. Each one requests a large block of test data from the backend with a random query string attached so nothing can be served from a cache. As soon as one request finishes, that connection immediately starts another, so all six stay saturated for the full window. Bytes are counted from the browser's own progress events as the data arrives.

The first 1,500 ms is a grace period: those bytes are excluded from the final figure. This keeps the connection's ramp-up out of the number, since TCP starts conservatively and accelerates. Speed is then calculated as the bytes transferred after the grace period divided by the time elapsed after the grace period, converted to megabits per second. The on-screen figure refreshes every 200 ms while the test runs. At 15 seconds the transfers are aborted and the final value is calculated from everything counted up to that point.

Upload

Identical structure in reverse: 6 parallel connections, 300 ms stagger, 1,500 ms grace period, 15 seconds total. Each connection posts a 20 MB block of data to the server, and bytes are counted from the browser's upload progress events. One consequence worth knowing: the browser reports upload progress as data is handed to the network stack, not as the server acknowledges it, which is another reason the grace period exists — the opening moments of an upload can look faster than the link really is.

The overhead factor

Both figures are multiplied by 1.06 before being shown. The browser only counts the payload it handed you; it does not count the TCP/IP and HTTP headers that also travelled down your line to deliver that payload. The 1.06 multiplier is a +6% allowance for that protocol overhead, and it is the same convention used by other browser-based speed tests. It is an estimate, not a measurement. Your real header overhead depends on packet sizes and your connection type, so treat the last few percent of any speed test result — ours included — as approximate.

How ping is measured, and why it reads higher than a command-line ping

This is the single most useful thing to understand about any browser speed test, so it gets stated plainly:

SpeedSnap's ping is an HTTPS round trip, not an ICMP ping.

The ping command in a terminal sends an ICMP echo packet, which the target machine's network stack answers almost instantly, below the level of any web server. A browser cannot send ICMP packets at all — the API simply does not exist in JavaScript, for good security reasons. So SpeedSnap does what every browser-based test must do: it makes a real HTTPS request — a HEAD request to a near-empty endpoint on the test server, with a random query string so nothing is answered from a cache — and times how long the round trip takes, from just before the request is sent to the moment the response comes back.

That timing therefore includes several things a command-line ping never touches:

• the network round trip itself — the part you actually want;
• the web server accepting the connection and the backend script running and replying;
• TLS negotiation on the very first request of a burst;
• the browser's own request scheduling and event-loop timing.

The practical result: expect SpeedSnap to report a higher number than a terminal ping to the same host. That is not a bug and it is not the test being wrong — it is a different, slightly larger thing being measured. It is also why the first 2 requests of each burst are thrown away: they carry the connection-setup cost, and including them would inflate the result.

Of the samples that remain, SpeedSnap sorts them, drops the fastest 20% and the slowest 20% — rounded down, so on a full 18-sample burst three readings are removed from each end and the middle 12 are averaged. (If fewer than five samples survive, it falls back to their median instead.) This trimmed average is more stable than a plain mean, which a single unlucky spike can drag upwards. Because the reported ping comes from the burst that runs after the transfer phases, it is measured on a link that has just gone quiet again.

For what the resulting number means in practice, see what is ping and what is latency.

How jitter is calculated

Jitter comes from the same 20-request burst that produces the ping. After the 2 warm-up requests are discarded, 18 samples remain. SpeedSnap takes the absolute difference between each consecutive pair of samples — sample 2 minus sample 1, sample 3 minus sample 2, and so on, giving 17 differences — and reports the average of those differences.

In other words, jitter here answers: on average, how much did each round trip differ from the one immediately before it? A connection whose ping is 40, 41, 39, 40 ms has near-zero jitter. One whose ping is 20, 70, 25, 65 ms has high jitter even though the average of both might look similar.

Two honest caveats. First, jitter is calculated from the untrimmed sample set, unlike ping — no outliers are removed, so one spike genuinely does raise the number. Second, 18 samples gathered over a burst of a few seconds — each request is followed by a 100 ms pause, so the whole burst runs for roughly 20 round trips plus two seconds of pauses — is a short window. It is enough to catch a connection that is consistently unstable, but a problem that appears once a minute may not land inside it. If you suspect intermittent instability, run the test several times rather than trusting one figure. Our jitter guide covers how to read the result.

Where the test server is

SpeedSnap runs one test server. It is in New Jersey, United States.

The server picker on the results page exists, but it currently has a single entry, so every test — from every country — measures your connection to that one machine in New Jersey. The consequences are worth spelling out:

• Your ping is a measure of your distance to New Jersey, plus your own connection's overhead. If you are testing from South Asia, the Middle East or Oceania, a ping in the hundreds of milliseconds is mostly the speed of light through a lot of fibre, not a fault on your line.
• Your download and upload figures are long-distance figures. Throughput over a long path is more sensitive to congestion and to the routing your ISP chooses than a test to a server in your own city would be.
• The ping in your game or video call will differ, because those connect to their own servers, which are usually much closer to you. Use SpeedSnap's ping to compare your connection against itself over time, and to spot a genuinely unstable link — not as a prediction of your in-game ping.

Tests run from North America, and from the US East Coast in particular, will therefore see lower latency than tests run from elsewhere. That is a property of the test setup, not of the connections being tested.

What SpeedSnap stores, and what it does not

Storage is opt-in. A banner asking "Save your results to our database?" appears after your first test. The default, before you answer, is that nothing is stored, and choosing "No thanks" keeps it that way for that browser until you clear your browser data. Only when a test completes, passes a basic sanity check, and you have clicked Allow on that banner is one row written to SpeedSnap's results database (hosted on Supabase). That row contains:

• the four measurements — download, upload, ping, jitter;
• the ISP name, city, country and country code returned by an IP-based lookup;
• whether the device is mobile or desktop, derived from the browser's user-agent string;
• the test server's name and city;
• a fingerprint hash.

The fingerprint is a SHA-256 hash of your IP address combined with your user-agent string, computed in your browser. Only the resulting hash is sent; the hash itself cannot be reversed back into an IP address. It is used for three things and nothing else: restoring your test history if you clear your browser storage, syncing the achievement badges tied to your own runs, and holding you to one review per ISP. Because it is derived from your IP, it changes when your IP changes.

Not stored: there is no account, no sign-up, no email address, no name, no password, and no raw IP address in the results row. Your IP is necessarily visible to the server handling your requests — that is how the internet routes traffic back to you — but it is not written into the results table.

Three further disclosures that belong here rather than in fine print:

• A third-party geolocation service may see your IP. SpeedSnap first asks its own backend to identify your ISP and city. If that lookup fails or comes back without an ISP or city, your browser falls back to the third-party API ipapi.co, which means that service receives a request directly from your IP address.
• The site loads Google Analytics. Page views, Web Vitals measurements and completed-test events are recorded there.
• The site also loads Yandex Metrica, with its click map and Webvisor session-recording features enabled. That is a second analytics vendor, and Webvisor means your interactions with the page can be replayed. We would rather say so here than let you discover it in a network tab.

Full details of both analytics tools are in the privacy policy. To be unambiguous about it: SpeedSnap is free and requires no account, but it is not a no-tracking or no-data-collection product, and nothing on this site should be read as claiming otherwise.

Your own test history — up to your last 100 results — is kept in your browser's local storage, along with your settings. Clearing your browser data clears it.

Results that are discarded

Not every completed run is stored, and there are two separate gates. The first is consent, described above: if you have not clicked Allow on the storage banner, nothing is sent to the database at all, no matter how clean the numbers are. The second is a sanity check applied only to results that did have consent — a result is rejected before it reaches the database if its download speed is zero or negative, if its upload speed is negative, if its ping is below 1 ms or above 2,000 ms, or if any of those three numbers is not a finite value. A sub-millisecond ping is impossible for an HTTPS round trip to a remote server and indicates a measurement fault; a zero download means the run failed or was aborted rather than finished. Those runs still display on your screen, but they are kept out of any shared figure, because a public number built from impossible rows is worse than no number at all.

ISP names

The ISP label attached to a result comes from a WHOIS-style lookup on your IP address. On residential connections that field is frequently the account holder's own name rather than a company. Before an ISP name reaches the public ISP leaderboard or the ISP comparison tool it is passed through a filter — isPublishableISPName in the site code, mirrored as is_publishable_isp_name in the database so the API cannot be queried around it. In order, that filter:

• drops blank values and placeholders — Unknown, N/A, none, null, private, reserved, localhost and similar;
• drops anything beginning with a personal title or name prefix — Md, Mohammad, Mr, Dr, Engr, Sri and others — even if a company word appears later in the string;
• publishes values matching a list of known consumer provider brands, either as a phrase (Virgin Media, Sky Broadband, Deutsche Telekom) or as a single unambiguous token (Comcast, Vodafone, Jio, Telstra);
• drops values shaped like a personal name — two or three capitalised words — unless they also carry a strong industry word (Telecom, Broadband, Fibre, Networks, Wireless) or a distinctive legal form (Ltd, GmbH, Pvt, Sdn Bhd). A generic business word such as Web, Net, Group, Media, Digital or Enterprise deliberately does not rescue them, because "Firstname Lastname Enterprise" is a person and "Hong Kong Broadband" is not;
• treats the roughly twenty brand names that are also common human names (Cox, Zain, Tim, Shaw, Claro, Orange, Frontier, Spectrum) as a brand only when the value is the bare brand on its own or a corporate word sits alongside it;
• otherwise publishes the value only if it contains one of a fixed list of corporate or industry words, and drops it if it does not.

Two limits on that are worth stating plainly rather than leaving implied. It is a heuristic, not a guarantee. The last rule means an unfamiliar name that happens to contain a broad word like net, digital or media can still pass, while a genuine small ISP whose name contains none of the listed words will be dropped. We accept losing real providers from a listing; publishing a private individual's name next to their city and connection speed is the outcome the filter exists to prevent.

And it does not cover every surface. The community ISP-review picker on the insights page builds part of its list from the ISP name recorded in your own device's local test history, which is checked only for being non-empty and not "Unknown" — so a value this filter would reject can still appear there on your own device, and a review submitted under that name is stored and served without the same check. If you would rather not have your connection's WHOIS label recorded at all, do not submit a review.

What this test cannot tell you

Every measurement method has a boundary. These are ours.

• Very fast connections under-report. On a multi-gigabit line the bottleneck usually stops being your connection and becomes something else: JavaScript processing the incoming data, your Wi-Fi adapter, your device's CPU, or the long path to a single server on the other side of the country. A browser-based test cannot escape this. If you are on a gigabit-plus plan and the result looks low, the test may simply have run out of headroom before your line did.
• Wi-Fi adds variance you cannot see. A Wi-Fi test measures your connection and your wireless link at the same time, and cannot separate them. Distance from the router, walls, interference and band choice all move the result. For a measurement of the line itself, use Ethernet — see Wi-Fi vs Ethernet.
• A VPN skews everything. It routes your traffic through an extra hop, adds encryption overhead, and changes the apparent location and ISP of your connection. Latency goes up and throughput usually goes down. Turn it off before testing your actual service.
• Results vary by time of day. Shared infrastructure gets busier in the evening. A single test is a snapshot of one moment on one path; several tests at different hours tell you far more than one.
• Other traffic on your network counts against you. A console downloading an update or a TV streaming in another room is using the same line the test is measuring.
• No latency-under-load measurement. Ping is measured before and after the transfers, never during them. That means SpeedSnap will not reveal bufferbloat — the latency spike that appears specifically when your connection is saturated. A connection can score well here and still feel terrible during a large upload.
• No packet loss measurement. The test measures four things: download, upload, ping and jitter. A browser cannot count individual dropped packets, and if one of SpeedSnap's latency requests fails outright it is skipped rather than recorded. If you need to investigate loss, see what is packet loss.
• It measures one path, not the internet. The result describes the route between your device and one server in New Jersey at one moment. A different destination — a game server, a CDN edge, a work VPN endpoint — is a different path and may perform completely differently.

Getting the most accurate result

1. Use Ethernet if you can. It removes the largest single source of variance.
2. Stop other traffic. Pause downloads, cloud syncs and streams on every device before you start.
3. Disable your VPN unless the VPN is what you are trying to measure.
4. Close what you are not using. The test needs your device to process data quickly; a laptop at full CPU load will under-report.
5. Test more than once, at different times of day, and compare the pattern rather than fixating on one figure.
6. Read the trend, not the decimal. Two runs minutes apart will not match exactly. That is normal on every speed test.

Once you have a result, what each number actually means walks through how to interpret it, and why is my internet so slow covers what to do when the figures come back worse than expected.

Frequently Asked Questions

Is SpeedSnap's ping the same as a command-line ping?

No. Browsers cannot send ICMP packets, which is what the ping command uses. SpeedSnap times a full HTTPS request to the test server instead, so the number includes web server and backend processing time and browser scheduling on top of the pure network round trip. Expect SpeedSnap's ping to read a few milliseconds higher than a command-line ping to the same host. It is still a valid measure of responsiveness and is directly comparable between runs.

Where is the SpeedSnap test server?

SpeedSnap runs one test server, located in New Jersey, United States. Every test measures your connection to that machine, so the ping you see reflects the distance between you and New Jersey. Testing from Europe, Asia, Africa or Oceania will produce a high ping that is a function of geography, not necessarily a fault with your connection.

How is jitter calculated?

SpeedSnap sends 20 latency requests after the transfer phases, discards the first 2 as connection warm-up, and keeps the remaining 18 samples. Jitter is the average of the absolute differences between each consecutive pair of those samples. Unlike the ping figure, no outliers are trimmed, so a single spike raises the jitter number.

Why is my speed test result lower than the speed I pay for?

Common reasons are Wi-Fi rather than Ethernet, other devices or apps using the connection during the test, distance to the test server, an older phone or laptop that cannot process data fast enough, and the fact that most plans are advertised as an "up to" figure measured at the router rather than at your device. A browser-based test also has a practical ceiling on very fast lines, so multi-gigabit connections routinely under-report.

What data does SpeedSnap store about my test?

A row is only written to SpeedSnap's database if you allow it in the consent banner shown after your first test; the default, before you answer, is that nothing is stored. If you allow it, a completed test writes one row containing the four measurements, the ISP name, city, country and country code returned by an IP lookup, whether the device is mobile or desktop, the test server's name and city, and a fingerprint hash. There is no account, no email address, no name and no raw IP address in that row. Your own test history is kept in your browser's local storage either way.

Does SpeedSnap measure packet loss?

No. The test measures four things: download speed, upload speed, ping and jitter. A browser cannot count individual dropped packets, and if one of SpeedSnap's latency requests fails it is skipped rather than recorded, so no packet-loss figure comes out of the measurement.

Why does my result change every time I test?

Because your connection is shared and the path to the server is shared. Congestion on your own network, at your ISP, and anywhere along the route between you and New Jersey shifts from second to second. Variation of some percent between runs is expected behaviour, not a broken test. Consistent, repeatable results across several runs at different times are what a stable connection looks like.

A shorter version

If you want the plain-language walkthrough rather than the engineering detail, how a speed test works covers the same three phases without the caveats, and how to test your internet speed covers running one properly. When you are ready, the free speed test takes about half a minute.