Connection Quality · Network Tests
Internet Connection Info
See your connection type, estimated speed, latency and data-saver state from the browser itself.
Connection details
These figures come from the browser’s Network Information API, which is an estimate based on recent activity, not a speed test. Firefox and Safari do not expose it, so some values may read as unavailable there.
On this page
What this test measures
Modern browsers keep a running sense of how good your internet connection is, so websites can adapt, loading lighter media on a slow link, for instance. This test surfaces that internal estimate: your connection type, an approximate speed, the round-trip latency and whether a data-saving mode is switched on. It reads all of it instantly, transferring nothing.
The values come from the Network Information API, reached in JavaScript through navigator.connection. It exposes a small set of read-only properties, effectiveType, downlink, rtt, saveData and the connection type, none of which needs a permission prompt. Opening this page starts no transfer and no timer; the panel above simply prints what the browser already held in memory.
Instant, not a benchmark
Because it reports the browser’s existing estimate rather than running a transfer, it costs no bandwidth and returns immediately. The trade-off is that the figures are approximate, more a weather report than a stopwatch.
The values explained
| Value | Meaning |
|---|---|
| Effective type | Quality bucket, 4g down to slow-2g, based on recent throughput and latency |
| Downlink | Estimated download bandwidth in megabits per second |
| Latency (RTT) | Estimated round-trip time to send a packet and get a reply |
| Connection type | The physical medium where known: wifi, cellular, ethernet |
| Data Saver | Whether your browser is asking sites to reduce data usage |
Effective type is not read from your hardware; it is derived from the other numbers using fixed thresholds. The browser labels the link slow-2g when the round trip is at least 2,000 ms or downlink at most 50 kbps, 2g at 1,400 ms or 70 kbps, 3g at 270 ms or 700 kbps, and 4g in every other case. Those are pessimistic mobile-era bands, which is why a fast home connection and ordinary Wi-Fi both settle on 4g.
Downlink is capped at 10 megabits per second in the specification, and the round-trip figure is rounded to the nearest 25 ms, so neither is a precise instrument. Read them as buckets rather than readings.
Why it is an estimate
The browser calculates these numbers by watching how quickly recent requests completed, then smoothing that history into a prediction. It does not fire off a fresh test when you open this page, so if you have just started browsing, or your connection changed in the last few seconds, the figures may lag behind reality for a moment. Switching from Wi-Fi to mobile data can leave a stale 4g sitting there for a short while.
That smoothing is why the values feel slow to react: fast responses pull the estimate up, timeouts drag it down, and the browser avoids jumping on any single sample. It also means the numbers describe the traffic you have actually been generating, usually ordinary page loads rather than a sustained transfer.
For an accurate throughput measurement you still want a dedicated speed test that moves data in bulk. This tool answers a different question: what does my browser currently believe about my connection, and what is it telling websites on that basis.
Why some browsers show nothing
The Network Information API that powers most of these values is a Chromium feature. Chrome, Edge, Opera and other Chromium browsers implement it; Firefox and Safari deliberately do not, partly over fingerprinting concerns, since a detailed connection profile is one more way to tell devices apart. There is no workaround, so a page cannot obtain the values on those browsers at all.
On one of them you will see the speed and latency read as unavailable, while your basic online status still works. That status comes from navigator.onLine, a far older and universally supported signal that only reports whether the browser believes a network exists. The HTTP headers test shows what your browser does send with each request.
For developers this split matters. Code that branches on effective type has to cope with the property being missing entirely, so most sites treat these values as a hint to be tested for rather than a dependable input. An absent value means "unknown", never "slow".
What it is useful for
Developers use these signals to build considerate sites, deferring heavy assets when the effective type drops or honouring Data Saver by serving compressed images and skipping autoplay video. Seeing the values yourself explains why a site sometimes looks lighter on mobile data than on Wi-Fi, or why a video quietly refuses to start at full quality.
For everyday troubleshooting it is a quick sanity check. If a page feels slow, a glance here tells you whether your browser already thinks the connection is weak, before you hunt for other causes such as an extension or a busy server.
The numbers also pair usefully with a real measurement. The latency test sends timed requests and reports what actually happened, while this page reports what the browser expected. When the two disagree sharply, the estimate is usually the one that is out of date.
What it cannot tell a site
It is worth being clear about how little this signal gives away. Effective type, downlink and round-trip time are coarse buckets shared by enormous numbers of people, and they change from minute to minute. Two strangers on the same network will often report identical values, so the readings cannot identify you and are useless for recognising a returning visitor.
What the browser withholds matters just as much. Through this interface a page cannot read your IP address, your provider, your router model or the speed you actually pay for. Downlink is a capped estimate of recent throughput, not your plan’s headline rate, and the 10 Mbps ceiling means a gigabit line and a fast cable connection can read identically.
Data Saver deserves its own caution. It is a request, not a measurement: a site is free to ignore it entirely, and nothing about the signal is enforced. To see what your connection genuinely reveals, the IP address test and the WebRTC leak test show the parts that do identify you.