Most people reach for speedtest.net or install the Ookla app to check their connection on a Mac. You don’t need either. Since macOS Monterey (macOS 12), every Mac has shipped with networkQuality, a command-line tool at /usr/bin/networkQuality that measures your connection and, unlike a plain speed test, tells you how the connection holds up while it’s busy. Run it with no arguments and it does the whole thing in about 15 seconds:
$ networkQuality
Uplink capacity: 34.720 Mbps
Downlink capacity: 110.246 Mbps
Responsiveness: Medium (153.923 milliseconds | 389 RPM)
Idle Latency: 85.363 milliseconds | 702 RPMFour numbers, no browser, no install, no ads. But two of those numbers aren’t what a normal speed test reports, and understanding them is the reason to use this tool instead of a website.
It says “capacity,” not “speed” — on purpose
The first two lines look like an ordinary speed test, but Apple labels them capacity rather than speed. That wording is deliberate: the tool opens multiple parallel connections and reports the maximum throughput it can reach, which is the ceiling your link can hit, not what any single download will sustain. On this run that ceiling was about 110 Mbps down and 35 Mbps up. Those figures will land in the same range as speedtest.net, and if a raw number is all you want, either tool answers the question.
The other two lines are where networkQuality earns its place.
RPM and responsiveness: the part a speed test skips
Responsiveness is measured in RPM — round-trips per minute under load. It answers a question capacity can’t: when your link is saturated (a big upload running, someone streaming), how quickly does a new request still get a reply? A connection can post a great capacity number and still feel terrible on a video call, because the moment traffic fills the pipe, latency balloons. That effect is bufferbloat, and RPM is built to expose it. Apple documents the metric and methodology in its support note on responsiveness; it also tracks the IETF’s responsiveness draft.
Higher RPM is better. The -v flag shows idle and loaded latency side by side, which is where the gap becomes obvious:
$ networkQuality -v
...
Idle Latency:
702 RPM (85.363 milliseconds)
Responsiveness: Medium
389 RPM (153.923 milliseconds)
Transport: 6043 RPM (9.928 milliseconds)
Security: 268 RPM (223.701 milliseconds)
HTTP: 974 RPM (61.598 milliseconds)
HTTP loaded: 220 RPM (272.102 milliseconds)Idle, a round-trip completed at 702 RPM (about 85 ms). Under load, the HTTP layer dropped to 220 RPM (about 272 ms) — the same connection got roughly three times slower to respond the instant it was busy. A website speed test would have shown you the capacity and none of this. The -v breakdown also splits the latency by layer, so you can see whether the delay is in the TCP handshake (Transport), TLS (Security), or the HTTP exchange, rather than getting one blended figure.
Use -s to catch upload bufferbloat the default run hides
By default the tool tests upload and download at the same time and reports one combined responsiveness score. That mirrors real use — a video call sends and receives at once — but it can average away a problem that lives on only one direction. The -s flag runs the phases sequentially and reports upload and download responsiveness separately. On the same connection that scored a single “Medium” a moment earlier, splitting it apart told a different story:
$ networkQuality -s
Uplink capacity: 43.653 Mbps
Downlink capacity: 107.253 Mbps
Uplink Responsiveness: Low (1.359 seconds | 44 RPM)
Downlink Responsiveness: Medium (148.659 milliseconds | 403 RPM)
Idle Latency: 82.049 milliseconds | 731 RPMDownload responsiveness was fine at 403 RPM, but upload collapsed to 44 RPM — a round-trip taking 1.36 seconds once the uplink was full. That is the signature of upload bufferbloat, and it’s exactly the kind of thing that makes a call unusable while a file is uploading, even though the capacity numbers look healthy. The combined default run folds that 44 into the download’s 400-plus and prints a reassuring “Medium.” If a connection feels bad under load but the plain networkQuality score looks acceptable, -s is the flag that separates the two directions and finds the weak one.
The flags worth knowing
Beyond -v and -s, three options cover most needs. -c produces JSON instead of the human summary, which is what you want for logging results over time or diffing two runs — it carries raw throughput in bits per second, base_rtt, the interface, and the OS build:
$ networkQuality -c
{
"dl_throughput" : 114852776,
"ul_throughput" : 36680816,
"base_rtt" : 85.89,
"interface_name" : "en0",
"responsiveness" : 347.75,
"os_version" : "Version 26.5.2 (Build 25F84)"
}
# trimmed: the full JSON also lists every handshake's raw latency array-I binds the test to one interface, so networkQuality -I en0 forces the test over Wi-Fi even if Ethernet is also connected — useful for comparing the two on the same machine. And -d or -u skip the download or upload phase when you only care about one direction. The full option list is in man networkQuality.
When to use this instead of Ookla or speedtest.net
Reach for networkQuality when you want the responsiveness picture — bufferbloat, latency under load, upload versus download behavior — or when you just want a fast, no-install, no-ad answer from the Terminal that you can script and log. Reach for Ookla or a web test when you specifically want to pick a nearby server, compare against your ISP’s advertised plan on a familiar scale, or measure against a location you choose. networkQuality connects to an Apple content-delivery host (an aaplimg.com node) that you don’t control, so its capacity figure reflects the path to that endpoint, not to any particular game or site.
What it doesn’t tell you
A single run is one snapshot on one path at one moment; numbers move noticeably between runs as the network and the chosen endpoint vary, so a low score is worth repeating before you trust it. It doesn’t report packet loss, jitter distribution, or the route your traffic takes — for the path itself, traceroute and ping are the right tools, and the broader set of built-in network commands is covered in the macOS network diagnostic commands guide. And because the endpoint is Apple’s, a great networkQuality result doesn’t guarantee a great connection to a specific server on the other side of the world. What it does give you, that a plain speed test doesn’t, is an honest look at how your link behaves when it’s actually working — which is usually the number that decides whether a call feels fine or falls apart.