Windows command-line guide
Packet Loss Test CMD: Check and Diagnose Loss in Windows
Run a packet loss test CMD workflow with Windows built-in commands. Start with a repeatable ping, read the packet summary, then compare targets or use pathping before you blame Wi-Fi, your ISP, or a remote service.
Run the browser packet loss testQuick Start: Run a Packet Loss Test in CMD
For a useful first packet loss test CMD check, open Command Prompt and send 100 echo requests to a stable public target. Press Windows + R, type cmd, press Enter, then run the command below. It takes longer than the four-request Windows default and gives you a more meaningful sample.
Wait for the command to finish. Do not judge the connection from one slow reply in the scrolling output. The summary at the bottom shows packets sent, received, and lost. If Lost is above zero, repeat the same test before changing any settings because a short disturbance or a target that limits ICMP replies can mislead you.
100-request public-target test
ping -n 100 1.1.1.1Typical clean summary
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss)
Minimum = 18ms, Maximum = 31ms, Average = 22ms- Use -n 100 to choose 100 echo requests; Windows sends four by default.
- Keep the target and packet count unchanged when comparing two tests.
- Run the test while the lag, call breakup, or disconnect is actually happening.
- Treat the first result as evidence to confirm, not a complete diagnosis.
Choose the Right Target Before You Test
A ping result describes only the path between this Windows computer and the target you chose. The destination determines what the result can tell you. Testing your gateway checks the first local hop. Testing a stable public IP adds your modem, ISP, and an internet route. Testing a service hostname focuses on the route to that service, but the service may ignore or limit ping.
Find the Default Gateway by running ipconfig and looking under the active Wi-Fi or Ethernet adapter. Common home gateway addresses include 192.168.0.1 and 192.168.1.1, but use the value shown on your computer instead of guessing. Then compare the gateway result with a public target using the same packet count.
Find and test the local gateway
ipconfig
ping -n 100 <your-default-gateway>Compare a public destination
ping -n 100 1.1.1.1
ping -n 100 8.8.8.8| Target | What a loss result suggests | What a clean result does not prove |
|---|---|---|
| Default gateway | A local Wi-Fi, Ethernet, adapter, cable, or router path needs attention | The modem, ISP, and wider internet path are healthy |
| Stable public IP | Loss exists somewhere from your device through the public route | Every game, call, or service route has the same result |
| Specific service | The issue may be destination- or route-specific when other targets are clean | The service accepts and prioritizes ICMP like application traffic |
How to Check Packet Loss in CMD Results
The packet summary is the main answer when you check packet loss CMD output. Sent is the number of echo requests Windows transmitted. Received is the number of echo replies that returned before the timeout. Lost is Sent minus Received, followed by the percentage. With 100 requests, each missing reply equals one percentage point.
Minimum, Maximum, and Average are round-trip times for the replies that arrived. A large gap between Minimum and Maximum can reveal unstable latency, but standard ping does not report a formal jitter metric or late-packet threshold. Zero loss with wide latency swings can still feel poor in a game or call.
Request timed out means Windows did not receive the expected reply before the timeout. That can represent congestion or loss, but it can also mean a firewall or remote device is not answering ICMP. Name-resolution errors are different: if a hostname fails but an IP address works, DNS may be the problem rather than packet delivery.
| CMD field | Meaning | How to use it |
|---|---|---|
| Sent | Echo requests transmitted | Confirm the test used the intended sample size |
| Received | Echo replies returned | Compare it with Sent |
| Lost and loss % | Requests without a reply in this test | Repeat if it is above zero and compare targets |
| Minimum / Maximum / Average | Round-trip time for successful replies | Look for unstable spread as well as the average |
| Request timed out | No reply arrived before the timeout | Confirm with other targets before assigning a cause |
Run a Longer Ping Packet Loss CMD Test
Intermittent loss can disappear during a 100-request test. Use continuous ping when the problem happens only during a game, meeting, upload, or busy evening. Windows keeps sending requests until you stop it. Press Ctrl + C to stop and print the final statistics. Ctrl + Break displays statistics without ending the test.
A longer packet loss test CMD run is useful only when you label the conditions. Record the target, connection type, start time, duration, and whether other devices were busy. Change one variable at a time. For example, compare Wi-Fi with Ethernet while keeping the computer, target, and test window as similar as possible.
You can also force IPv4 or IPv6 when a hostname has both address types. A difference between the two tests is a clue about protocol-specific routing or configuration, not automatic proof that the protocol itself is defective.
Continuous test
ping -t 1.1.1.1Fixed count and protocol family
ping -n 300 -4 1.1.1.1
ping -n 300 -6 one.one.one.one- Use Ctrl + C to stop a continuous test and retain the summary.
- Test during the symptom, not only when the connection feels normal.
- Repeat at different times if the pattern may follow peak-hour congestion.
- Save comparable results before contacting an ISP or service provider.
Use Tracert and Pathping to Find Where Loss Starts
Ping measures one destination but does not show the path. Tracert discovers the sequence of hops by changing the packet time-to-live value. It is useful for route context, but three probes per hop are too small a sample to measure packet loss reliably. An asterisk means that a reply was not received for that probe; some routers simply do not return those diagnostic messages.
Pathping first discovers the route and then sends repeated probes to routers along it. Microsoft documents it as a way to calculate network latency and loss at intermediate hops. It can take roughly 90 seconds or longer because it gathers statistics after displaying the route. The /n option skips hostname lookup and can make the initial display faster.
Read the pattern through to the destination. A middle router can limit replies addressed to itself while still forwarding traffic normally. If one hop looks bad but every later hop and the final target are clean, do not report that router as the cause. Loss that begins at one link and continues through later hops to the destination is more meaningful.
Route overview
tracert 1.1.1.1Route with loss statistics
pathping /n 1.1.1.1| Command | Best use | Main limitation |
|---|---|---|
| ping | Measure replies and round-trip time to one target | Does not locate the path segment |
| tracert | See the likely route and hop latency | Very small sample; asterisks are not proof of forwarding loss |
| pathping | Collect hop and link loss statistics over time | Slower and still affected by ICMP response policy |
Use the Test Pattern to Isolate the Problem
Diagnosis comes from comparing results, not from one percentage. Start with the gateway, then a public target, then the affected service if it responds to ping. Use Ethernet as a controlled comparison when possible. This sequence narrows the fault domain without claiming that CMD can identify every dropped application packet.
If both Wi-Fi and Ethernet lose packets to the gateway, check the computer, adapter, cable, router port, and router load. If only Wi-Fi loses packets to the gateway, interference, signal strength, channel congestion, or the wireless adapter is more likely. If the gateway stays clean but multiple public targets lose packets, collect repeated wired results before escalating to your ISP.
If public targets are clean and only one service is affected, the service, region, or route may be specific to that application. Use its published diagnostics or support instructions where available. Avoid changing DNS, firewall, router firmware, VPN settings, and cables all at once because you will not know which change affected the result.
| Observed pattern | Most useful next step |
|---|---|
| Loss to the gateway on Wi-Fi only | Move closer, reduce interference, then compare Ethernet |
| Loss to the gateway on Wi-Fi and Ethernet | Check adapter, cable, router port, router load, and another device |
| Gateway clean; several public targets lose packets | Repeat wired tests and document times before contacting the ISP |
| Only one service or region is affected | Test the actual endpoint and check service-specific status or support |
| CMD is clean but real-time apps still struggle | Measure jitter and late packets during the symptom and compare the application route |
Common Command Prompt Test Mistakes
A CMD packet loss test is simple, but interpretation is where most errors happen. Four default requests are not enough for an intermittent problem. One destination cannot represent the whole internet. A test performed after the symptom disappears cannot describe the failing time window. And a middle-hop timeout in tracert or pathping is not automatically a broken router.
Do not treat a successful ping as proof that bandwidth, jitter, application servers, or UDP traffic are healthy. ICMP echo traffic may take a different path or receive different policy treatment. Conversely, 100% loss to one target does not prove your internet connection is down if other IP targets work; that destination may block ping.
Keep the evidence comparable. Use the same command, target, packet count, connection type, and time window when testing a change. Record the complete summary rather than copying only the worst reply. A reproducible pattern is more useful to an ISP or administrator than a single screenshot without context.
- Do not diagnose intermittent loss from the four-request default.
- Do not use only one target or only one time of day.
- Do not confuse DNS failure with packet loss to a working IP address.
- Do not treat one unresponsive intermediate hop as proof of end-to-end loss.
- Do not claim a clean ICMP test proves every application path is clean.
Cross-Check CMD With the Browser Test
Command Prompt is useful because it is built into Windows and produces a repeatable ICMP result. The PacketLossTest.dev browser test provides a complementary view of packet loss, latency, jitter, and late packets using the site's real-time test flow. Run it while the symptom is happening, then compare the timing with your CMD evidence.
The two tests are not interchangeable. Different targets and traffic methods can produce different results. Agreement across CMD, the browser test, and the affected application strengthens the evidence. A disagreement is also useful: it tells you to examine the target, protocol, route, or time window before choosing a fix.
Packet Loss Test Command Prompt FAQ
How can I see if I have packet loss in CMD?
Open Command Prompt and run ping -n 100 1.1.1.1. When the test ends, read the Packets line. The Lost value and percentage show how many ICMP echo replies did not return during that test. Repeat the test against your gateway and another public target before deciding where the problem is.
How do I ping 100 packets in CMD?
Run ping -n 100 followed by a hostname or IP address. For example, ping -n 100 1.1.1.1 sends 100 echo requests. Windows normally sends four requests, so the -n 100 option creates a more useful sample without running indefinitely.
Should I use ping, tracert, or pathping for packet loss?
Start with ping to measure loss to one destination. Use tracert to see the route when you need path context. Use pathping when you need repeated loss and latency statistics for the routers and links along that route. Asterisks or loss at one intermediate hop are not proof of end-to-end loss if later hops and the destination remain clean.
What does Lost = 0 (0% loss) mean in Command Prompt?
It means every ICMP echo request received a reply during that test window. It does not guarantee that every application, destination, protocol, or time of day is loss-free. If symptoms are intermittent, run a longer test while the problem is happening and compare more than one target.
Why can CMD show 0% packet loss while my game or call still lags?
The ping target, protocol, route, and test window may differ from the game or call. A clean ICMP test to a public resolver can coexist with jitter, late packets, congestion on another route, or loss affecting application traffic. Test the actual service when possible and cross-check latency, jitter, and late packets in the browser.
Why does one pathping hop show loss when the final destination is clean?
Some routers limit or deprioritize replies addressed to themselves while continuing to forward other traffic. If one middle hop reports loss but later hops and the destination do not, that pattern can be diagnostic-response rate limiting rather than real forwarded-packet loss. Loss that begins at one point and continues to the destination is stronger evidence.
Next Steps After the CMD Test
A packet loss test CMD result is the beginning of diagnosis. If you measured loss, compare the gateway, at least two public targets, and the affected service. Repeat the test over Ethernet and during the failing period. Then use the pattern to choose the smallest relevant next action.
Use the acceptable packet loss guide to interpret the percentage, the causes guide to understand the likely layer, and the fix guide only after the evidence narrows the problem. That order prevents random settings changes and gives you a cleaner before-and-after comparison.