This test transfers sample data between your browser and LumaProbe’s United Kingdom server. Close large downloads, label the connection type and run it more than once before drawing conclusions.
Distance to the UK server can raise latency outside nearby regions.Uses about 24 MB per completed test.
Run several tests at different times for a representative result.
These are approximate single-device estimates, not guarantees. Other users, applications, routes and service requirements can change the experience. How the estimates are interpreted →
Download and upload show transfer capacity in megabits per second. Idle latency measures response time before the bulk transfer; loaded latency shows responsiveness while the download is busy. Jitter shows variation. Failed requests can indicate instability but are not an ICMP packet-loss measurement.
The test first sends ten small HTTPS requests and records their round-trip time. It displays the median successful sample as idle latency and the standard deviation as jitter. It then downloads three generated six-mebibyte blocks in parallel while sampling HTTPS latency under load, followed by one six-mebibyte upload. Transfer rates come from bytes completed and elapsed browser time.
These are real transfers between your browser and the LumaProbe server, not a package-speed estimate copied from the browser. A complete run transfers about twenty-four mebibytes plus small request overhead. The relatively short sample keeps data use reasonable, although a very fast connection may need a longer specialised test to reach its maximum sustained rate.
Use one device and one browser for comparisons. Pause cloud backups, game downloads, streaming and large file transfers, then note whether the device is connected by Wi-Fi, Ethernet, mobile data or a VPN. Run the check at least three times instead of choosing a single unusually good or bad result.
Change only one condition at a time. For a Wi-Fi problem, compare beside the router with the affected room. For a suspected broadband fault, add an Ethernet result if practical. Record the time because congestion and provider work can make the same connection behave differently during the day.
Download capacity matters for large files and simultaneous streams; upload capacity matters for video calls, backups and sending files. Idle latency describes response delay before the deliberate transfer. Loaded latency shows how responsive the route remained while the download was busy, while jitter describes how much idle delay changed. Failed requests are unsuccessful HTTPS samples and can point to instability when they recur.
The current LumaProbe node is in the United Kingdom. Distance and inter-network routing can raise latency or cap throughput for visitors elsewhere, so compare repeated results on the same route and use a nearer or provider-operated test where appropriate. A lower Wi-Fi result does not prove the broadband line is slow: if Ethernet is healthy but Wi-Fi is not, investigate placement, interference and coverage first.
A browser sees the complete path from this device to LumaProbe, including the device, local network, provider route and test server. It cannot isolate the broadband line on its own. Browser scheduling, security software, VPNs, extensions and background activity can also influence a short test.
Treat the result as diagnostic evidence, not a contractual line measurement or a live provider-outage declaration. A provider can test a different network boundary and report a different valid number. The most useful conclusion usually comes from controlled comparisons and repeated observations.
If every device is slow over both Ethernet and Wi-Fi, check the provider’s official status page, restart the router once and retest at several times. Keep dated results before contacting support. If only one room is slow, use the Wi-Fi speed page and compare beside the router.
If speed looks adequate but calls or games still fail, investigate latency, jitter and failed requests. A high download figure cannot rule out queueing, packet loss, DNS trouble or a fault affecting only one destination.
Read the complete LumaProbe test methodology and privacy notes →
Server distance, transfer size, browser behaviour, route, Wi-Fi and other traffic can all differ. Compare repeated tests made under the same conditions instead of treating one service as automatically correct.
Yes. A complete run transfers about twenty-four mebibytes plus small request overhead. Avoid repeated testing on a restricted mobile allowance.
No. Repeat it, pause other traffic and compare Ethernet with Wi-Fi. The device, local network, route and test server are all part of the measured path.
Some links may earn us a commission at no extra cost to you. Recommendations are categories, not paid rankings.
Affiliate disclosure