This test transfers sample data between your browser and the LumaProbe server. Close large downloads and run it more than once before drawing conclusions.
Run several tests at different times for a representative result.
Download and upload show transfer capacity in megabits per second. Latency measures response time, while jitter shows how much that response varies. Failed requests can indicate instability but are not an ICMP packet-loss measurement.
The test first sends eight small HTTPS requests and records their round-trip time. It displays the average of the successful samples as latency and the standard deviation as jitter. It then downloads three generated six-mebibyte blocks and uploads one six-mebibyte block, calculating transfer rate 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. The relatively short data sample keeps 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. Latency describes response delay, while jitter describes how much that delay changed. Failed requests are unsuccessful HTTPS samples and can point to instability when they recur.
Compare the result with the minimum or estimated speed in your contract under the measurement conditions specified by your provider. A lower Wi-Fi result does not prove the line is slow. If Ethernet is healthy but Wi-Fi is not, investigate placement, interference and coverage before reporting a broadband fault.
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 →
No browser test is exact. Device performance, browser limits, server distance and other network traffic affect the result. Compare repeated tests under the same conditions.
Test results are stored only in your browser when local storage is available. The public application does not create a user account or central result profile.
Repeat the test, pause other traffic and compare Wi-Fi with Ethernet. Change one condition at a time so the cause becomes clearer.
Some links may earn us a commission at no extra cost to you. Recommendations are categories, not paid rankings.
Affiliate disclosure