How to Test Your True Local Network Speed Between Two Computers
Your internet speed test tells you nothing about how fast two computers on your own network can talk to each other. To measure that, you need to test the local link directly — and the method you choose changes the answer.
Why test local network speed at all?
Most people only ever run an internet speed test, which measures the path from one device out to a server on the far side of your ISP. That number is capped by whatever plan you pay for. Local network speed — the rate at which two machines inside your home move data between each other — is a completely separate thing, and it's usually much higher than your internet plan. A gigabit LAN can move data at roughly 940 Mbps between two wired PCs even if your internet is only 200 Mbps.
You'd want to measure it when you're copying big files to a NAS, backing up a laptop over the network, streaming media between rooms, or troubleshooting why one device feels sluggish while others are fine. If those transfers crawl, the bottleneck is almost always local — a slow cable, a tired Wi-Fi link, or one weak network adapter — not your ISP. For the broader distinction, see our guide on LAN vs. internet speed tests.
Tip: Before blaming your router, figure out whether the slow path is even on your side of the modem. Our walkthrough on whether your ISP or home network is the bottleneck covers how to split the problem in half.
The methods, from rough to rigorous
1. File-copy timing (quick and dirty)
The simplest test: copy a large file from one computer to another over the network and time it. Divide the file size by the seconds it took. A 10 GB file that copies in 90 seconds is moving about 111 MB/s, or roughly 890 Mbps — healthy for gigabit Ethernet.
The catch is that this measures the whole chain, not just the network. If either computer's hard drive can't read or write fast enough, you're timing the disk, not the wire. A spinning hard drive often tops out around 100–150 MB/s, and a cheap USB stick can be far slower. Use it for a gut check, not a verdict.
2. iperf3 (the standard)
iperf3 is the free, cross-platform tool network engineers actually use. It sends synthetic traffic straight from memory to memory, so disks never enter the picture — you measure the network and nothing else. You run it on both machines: one as a server, one as a client.
On the receiving machine (the server):
iperf3 -s
On the other machine (the client), pointing at the server's local IP address:
iperf3 -c 192.168.1.50
By default it runs a 10-second test and prints a per-second breakdown plus a summary. Read the last two lines: the sender and receiver totals in Mbits/sec are your real throughput. On wired gigabit you should see roughly 900–950 Mbps; anything much lower points to a cable, adapter, or duplex problem.
A few flags worth knowing:
-Rreverses direction (server sends, client receives) — useful because some links are asymmetric.-P 4runs four parallel streams, which can reveal headroom a single stream misses, especially on Wi-Fi and multi-gig links.-t 30extends the test to 30 seconds so a brief Wi-Fi hiccup doesn't skew the average.
Note: iperf3 measures TCP throughput by default, which is what file transfers use. If your numbers look oddly capped at, say, exactly 100 Mbps on hardware that should do gigabit, you've almost certainly got a device negotiating at Fast Ethernet — a bad cable or port forcing the link down a tier.
3. OS built-in transfer
Windows File Explorer and the macOS Finder both show a live transfer-rate readout during a network copy. It's essentially a friendlier version of file-copy timing, with the same disk-speed caveat. Handy because it needs nothing installed, but treat the peak number, not the stop-start average, as your best estimate — and only trust it when both machines have fast SSDs.
4. App-based LAN tests
Purpose-built LAN speed-test apps run a client and server for you and present results without command-line setup. A LAN speed test like PulseLAN falls into this bucket: it's aimed at measuring the local link specifically rather than your internet connection, which sidesteps the most common mistake of testing the wrong path entirely.
Methods compared
| Method | Accuracy | Difficulty | What it isolates |
|---|---|---|---|
| File-copy timing | Low–medium | Very easy | Whole chain (network + both disks) |
| iperf3 | High | Moderate | Network only (memory to memory) |
| OS built-in transfer | Low–medium | Very easy | Whole chain, live readout |
| App-based LAN test | Medium–high | Easy | Local link (varies by app) |
Interpreting the number against your link speed
Every wired connection negotiates a link speed — 100 Mbps, 1 Gbps, 2.5 Gbps, and so on. Your measured throughput should land a bit below that ceiling because of protocol overhead. On a gigabit link, ~940 Mbps of usable TCP throughput is the practical maximum, not a disappointment. If you see 940, you're done. If you see 300 on gigabit hardware, something is wrong. And remember that networking is quoted in bits while file managers show bytes — an 8× difference that trips everyone up. Our guide on megabits vs. megabytes untangles it.
Wired vs. wireless testing
Always test wired first to establish a clean baseline, then test Wi-Fi separately. Wired results are steady; Wi-Fi results swing with distance, interference, and how many other devices share the airtime. If your wired iperf3 result is great but Wi-Fi is a third of that, the network core is fine and the wireless leg is your limiter — a normal outcome worth understanding rather than fixing blindly. See Ethernet vs. Wi-Fi for local transfers for what to expect from each.
Common pitfalls
- Disk speed masquerading as network speed. The single most common error. Use iperf3 to rule the disks out, or copy to and from RAM disks.
- Antivirus and firewall scanning. Real-time scanning can throttle file copies as each block is inspected. iperf3's synthetic traffic sidesteps this, which is partly why it and a file copy can disagree.
- One slow NIC or cable. A single device stuck at 100 Mbps drags every transfer involving it. Check each machine's reported link speed in its network settings.
- Testing through Wi-Fi when you meant to test wired. A laptop docked but still on Wi-Fi will report wireless numbers. Confirm which interface is actually carrying the traffic.
- Background traffic. A cloud backup or system update running mid-test steals bandwidth. Close it or the result understates your link.
Beyond raw speed, latency and consistency matter for anything interactive — our guide on throughput, latency, and jitter explains why a fast link can still feel laggy.
Start with a quick file copy to sense the ballpark, then confirm with iperf3 when the number surprises you. Test wired to set a baseline, test Wi-Fi to see the cost of going wireless, and always keep bits and bytes straight. Once you know your true local speed, every future "why is this slow?" question gets much easier to answer.