Hardware
TesterNetwork Quality Tester
Test live WiFi and network quality: connection type, effective speed, downlink, round-trip time and jitter via the Network Information API, with CSV export.
Have feedback? Report bugs, suggest features, or share your thoughts — we read them allAbout Network Quality Tester
Monitor your network connection quality in real-time using the Network Information API. While direct Wi-Fi signal strength (RSSI) is not available through web APIs, this tool provides comprehensive network quality metrics including connection type, effective speed, bandwidth, round-trip time, and more. Perfect for diagnosing network issues, testing connection stability, and monitoring performance.
How to use:
- Click 'Start monitoring' to begin tracking network quality metrics.
- View real-time connection type and effective connection speed.
- Monitor downlink bandwidth and round-trip time (RTT).
- Check if data saver mode is enabled on your device.
- Run speed tests to measure download speed, latency and jitter.
- View connection quality rating based on current metrics.
- Review live session statistics (min / max / average RTT and downlink) and export a CSV log of RTT/downlink over time, or copy the run as JSON for a QA report.
Limitations
- Direct Wi-Fi signal strength (RSSI) is not accessible via web APIs for security reasons
- Network Information API support varies by browser and platform
- Desktop browsers may show limited information compared to mobile
- Some metrics may not be available on all networks
- Speed tests provide estimates and may vary based on server load
Browser Compatibility
- Chrome/Edge (Android): Full support
- Chrome/Edge (Desktop): Partial support
- Firefox: Limited support
- Safari: Not supported
- Best results on Android Chrome/Edge
Technical References
- MDN Network Information API: https://developer.mozilla.org/en-US/docs/Web/API/Network_Information_API
- W3C Network Information Spec: https://wicg.github.io/netinfo/
- Chrome Platform Status: https://chromestatus.com/feature/6338383617982464
Frequently Asked Questions
A speed test pushes a large payload to a server and measures the throughput, which tells you peak bandwidth in megabits per second but very little about how the connection behaves between transfers. This tool uses the Network Information API and live measurements of round-trip time (RTT) to small probes, plus the Effective Connection Type (effectiveType: slow-2g, 2g, 3g, 4g) inferred by the browser. The result describes responsiveness — how quickly your network responds to short requests — which is what determines feel for web browsing, video calls, gaming, and interactive apps. Two connections can both deliver 100 Mbps yet feel completely different when one has 20 ms RTT and the other has 200 ms.
Speed tests measure best-case throughput under ideal conditions: empty link, single large file, server near you. Real internet usage looks nothing like that. Video calls send and receive small frames every 33 ms, gaming requires consistent sub-50 ms RTT, and web pages issue dozens of small HTTPS requests where each request must finish round-tripping before the next can start. A connection with 1 Gbps download but 300 ms RTT or 5% packet loss will load slowly and feel laggy. Monitoring live RTT and connection type reveals the quality your apps actually see, helping you diagnose whether the issue is your Wi-Fi, your ISP, or the remote server when complaints arise.
Practical guidelines for general use: RTT under 50 ms is excellent for gaming and video calls; 50–100 ms is good and barely noticeable for most users; 100–200 ms feels laggy in real-time apps but works for web browsing; above 200 ms is annoying for any interactive use. Downlink: 0–1 Mbps is barely usable for HD video; 1–5 Mbps handles single 1080p stream; 5–25 Mbps handles 4K streaming and multiple devices; above 25 Mbps gives headroom for video calls plus background downloads. Note these are floors, not minimums — fiber to the home often shows 10 ms RTT and hundreds of megabits, which is overkill but creates a clearly snappier experience.
RTT jitter — variation in round-trip time — comes from queuing along the path. Each router and switch on the route maintains a queue of packets waiting to transmit; when the queue grows, packets wait longer and RTT rises. On a busy home Wi-Fi router, jitter often spikes when someone else starts a large download (bufferbloat). On cellular networks, jitter follows tower load and your distance to the cell. On ISP backbones, jitter rises during peak hours. Variations of 5–10 ms are normal, 20–50 ms are noticeable, and spikes above 100 ms typically indicate congestion. The Network Information API smooths these to give a stable estimate, but you can watch raw values fluctuate when you ping in a terminal.
effectiveType is a categorical estimate maintained by the browser based on observed RTT and downlink over recent traffic. The four values map roughly to: slow-2g (RTT ≥ 2000 ms or downlink ≤ 50 kbps), 2g (RTT ≥ 1400 ms or downlink ≤ 70 kbps), 3g (RTT ≥ 270 ms or downlink ≤ 700 kbps), 4g (everything faster). Note that the label refers to the experience, not your actual cellular generation — a heavily congested 5G connection can report 3g, and a fast Wi-Fi connection on a 2G phone reports 4g. Websites use this to adapt: serve lower-resolution images, defer non-essential scripts, or warn about heavy downloads. The values lag real-time changes by several seconds.
Wi-Fi signal strength (RSSI in dBm) is one input to network quality but does not directly equal it. A strong signal at −40 dBm guarantees a stable radio link but says nothing about congestion on the same channel, your uplink to the ISP, or the remote server. A weak signal at −80 dBm forces the AP to use lower MCS rates, increasing transmission time and exposing you to collisions, which raises RTT and reduces effective throughput even if the speedtest number looks acceptable. Browsers cannot directly query Wi-Fi RSSI on most platforms — that information is in the OS layer. Instead, the Network Information API reports the resulting application-visible RTT and downlink, which captures the end-to-end effect of poor signal.
These are related but not identical. Ping RTT (ICMP echo) measures the lowest-layer round-trip, often slightly optimistic because routers prioritize ICMP differently than TCP. TCP RTT is measured inside an active TCP connection during the data exchange and includes any retransmissions or congestion control delays. The Network Information API surfaces an estimate based on actual HTTPS request timing seen by the browser, which is closest to what your web app experiences — it includes TLS handshake overhead, HTTP/2 or HTTP/3 framing, and any server-side delays in addition to network propagation. For diagnosing whether your network is the bottleneck, the browser RTT is the most relevant; for diagnosing pure network path quality, use a command-line ping or mtr.
Wi-Fi 5 (802.11ac, 5 GHz only, theoretical 3.5 Gbps) is the baseline for modern usage. Wi-Fi 6 (802.11ax, both 2.4 and 5 GHz, theoretical 9.6 Gbps) introduced OFDMA which schedules multiple devices per transmission, dramatically improving performance in busy environments. Wi-Fi 6E adds the 6 GHz band (5.925–7.125 GHz in most regions) which is uncongested and supports wider 160 MHz channels. Wi-Fi 7 (802.11be) ratified in 2024 adds 320 MHz channels, Multi-Link Operation (devices use multiple bands simultaneously), and theoretical 46 Gbps. For most users today, Wi-Fi 6E gives the best real-world experience — Wi-Fi 7 routers exist but client devices are still catching up. Beware of routers labeled "AX" that only support 2.4 GHz, missing the main Wi-Fi 6 advantages.
CONNECTIVITY5
WUTOOLS