How VelocityVerify Measures Your Internet

Most internet speed tests are simpler than they look. They download a file, measure the time, and call it done. We go further — because download speed alone is not a reliable proxy for whether your connection will handle real-world use.

I. What We Measure (and Why Each Metric Matters)

• Download speed (Mbps): Multi-stream parallel TCP download to saturate the pipe. We use adaptive stream counts (4–12+) rather than a fixed number, which produces accurate results on both slow DSL and multi-gigabit fibre.
• Upload speed (Mbps): Same approach as download, reversed. Upload is frequently the bottleneck for video conferencing and remote work, and ISP plans are often highly asymmetric.
• Unloaded latency (ping, ms): Round-trip time to our edge server with no other traffic in flight. Measured as the median of multiple samples, not a single probe.
• Jitter (ms): Standard deviation of latency over multiple probes. High jitter is often more disruptive than high average latency in video calls and gaming.
• Bufferbloat grade (A–F): Latency measured while the link is saturated. This is the metric that reveals whether your router's queue management is causing lag spikes under load. See our deep-dive article on the measurement algorithm.

II. Server Infrastructure & Routing

Our test infrastructure uses independent edge nodes — not servers co-hosted by ISPs or CDNs that might receive priority treatment. This is a deliberate design choice: we want our test traffic to compete for the same queue space as your regular Netflix stream or Zoom call, because that's the condition that actually matters for your experience.

Tests are routed to the geographically nearest available node. Server selection is transparent: the server region used for your test is logged with the result so you can see which edge it hit.

III. Anti-Gaming Measures

Some ISPs have been accused of detecting speed test traffic by pattern-matching on known test endpoints or User-Agent headers and routing that traffic through priority queues, producing artificially good results. We address this with several countermeasures:

• Test traffic runs over standard HTTPS on port 443. No special headers identify it as a speed test.
• Payload sizes are randomised within bounds per measurement interval to prevent byte-count pattern recognition.
• Test server endpoints rotate across the available node pool.
• Server-side validation rejects results that fall outside physical plausibility bounds (e.g., download results that exceed the theoretical maximum of the detected link type). This is the input clamping referenced in our changelog from July 2026.

IV. Hardware Review Standards

All routers, mesh systems, and modems reviewed on our platform undergo physical testing in an isolated lab environment.

• Baseline integrity: All baseline tests use direct Cat6a/Cat7 Ethernet to eliminate wireless interference variables.
• Controlled wireless: Wi-Fi throughput and signal attenuation tests are conducted in a standardised environment with defined wall-penetration distances.
• Full metric set: We report loaded latency, unloaded latency, jitter, and bufferbloat grade — not just throughput.

V. Data & Privacy

Test results are stored in our Supabase database. IP addresses are hashed using a one-way function before storage — we cannot reverse the hash to recover your IP. We store: anonymised speed measurements, ISP name (from public IP lookup), approximate region (country/state), timestamp, and the parameters of the test (stream count, server used). We use this data exclusively to generate aggregate statistics and data-driven editorial content. It is not sold, shared with advertisers, or used to build user profiles.

For full data handling details, see our Privacy Policy.

Our Team

• Younes Kirat, CCNA, CWNA — Director of Network Diagnostics
• Sarah Jenkins — Lead Telecommunications Analyst

Our Editorial Policy covers how we handle corrections, affiliate disclosures, and editorial independence.