Tracert vs PathPing: Which Command is Better for Network Diagnostics?

 The honest answer to the question in the title is neither — and the reason is that both commands lie to you in exactly the same way.

They produce output that appears to show loss and latency at specific points along a path. In a large proportion of cases, that apparent loss is an illusion produced by how routers handle a particular kind of traffic, and administrators act on it anyway. Support tickets get opened with internet providers over hops that were never dropping anything.

So this article covers what each tool does, and then the more useful skill: reading their output without being misled. Choosing between tracert vs pathping matters far less than interpreting either of them correctly.

What Tracert Does

Traceroute works through an elegant trick involving the time-to-live field in the IP header.

Every packet carries a TTL value, decremented by one at each router. When it reaches zero, the router discards the packet and sends back an ICMP "time exceeded" message identifying itself.

Tracert exploits this deliberately. It sends packets with TTL set to 1, which expire at the first router and reveal its identity. Then TTL 2, revealing the second. It continues incrementing until the packets reach the destination or hit the maximum hop count, which defaults to 30.

Three probes are sent per hop, which is why you see three latency figures on each line.

The command:

tracert google.com

Useful options:

• -d skips reverse DNS lookup of each hop. This makes the trace dramatically faster, and it is the option you should use by default.
• -h maxhops limits how far it will go.
• -w timeout sets the wait per probe in milliseconds.
• -4 or -6 forces the address family.

Tracert completes in seconds and tells you the path. That is its purpose and it does it well.

What PathPing Does Differently

PathPing performs a traceroute first, then does something tracert does not: it sends a large number of packets to every hop and computes loss statistics for each.

The command:

pathping google.com

The first phase resembles tracert. The second phase then tests each hop over an extended period — by default around 25 seconds per hop — before producing a report showing loss percentage at each point.

This is genuinely more informative than three probes per hop. Three samples cannot distinguish between a hop that drops one percent of traffic and one that drops nothing.

The cost is time. A path with 15 hops takes roughly six minutes. In an incident, that is a long time to stare at a screen.

Options worth knowing:

• -n skips name resolution, which speeds up the first phase considerably.
• -q queries reduces the number of packets per hop from the default of 100.
• -p period shortens the interval between packets.
• -h maxhops limits the trace depth.

Combining -n -q 20 produces a result in a fraction of the default time while still giving a far better sample than tracert.

The Lie Both of Them Tell

Here is the thing that most guides omit, and it invalidates a great deal of the conclusions people draw.

Generating an ICMP time-exceeded message is not something a router does in hardware. It is handled by the router's control plane — its general-purpose processor — which is also busy with routing protocols, management, and everything else. Routers therefore deprioritise and rate-limit these responses aggressively.

The consequence: a router may show 50 percent loss in a traceroute while forwarding your actual traffic flawlessly. It is not dropping your packets. It is declining to spend processor time replying to probes aimed at itself.

Asterisks at a hop mean the same thing. Many routers are configured never to respond to these probes at all. A row of asterisks in the middle of a trace is usually a policy decision, not a failure.

How to Read Intermediate Loss Correctly

The rule that resolves this is simple and worth memorising.

Loss at an intermediate hop that does not continue at subsequent hops is not real. If hop 6 shows 40 percent loss and hops 7 through 12 show zero, hop 6 is forwarding perfectly. It simply does not like answering probes.

Loss that appears at one hop and persists through every hop afterwards, including the destination, is real. That is the signature of an actual problem, and the first hop where it appears is where to look.

Apply this to any trace output and most alarming-looking results become uninteresting. It also prevents the common and embarrassing scenario of reporting a fault to a provider based on a hop that was never dropping anything.

The Other Distortions

Several more effects produce misleading output, and knowing them prevents wasted investigation.

• Asymmetric return paths. Traceroute shows the outbound path only. The reply from each hop may return by an entirely different route, and the latency figure includes both directions. A hop showing high latency may have a slow path back rather than a slow path forward.
• Equal-cost load balancing. When multiple paths exist, consecutive probes may take different routes. The resulting trace shows hops that are not actually sequential, mixing two paths into one apparent list.
• MPLS tunnels. Traffic crossing a provider's label-switched network may traverse many devices that never appear in the trace, because the tunnel hides them. A single displayed hop may represent a long journey.
• ICMP rate limiting. Even a router that responds normally will stop responding under a burst of probes, producing loss that appears and disappears depending on how hard you test.
• Firewalls dropping probes. A corporate firewall will often block traceroute traffic entirely, ending the trace at its boundary regardless of what lies beyond.
• Latency increasing at the last hop only. Usually the destination host deprioritising ICMP, not a network problem.

When Tracert Is the Right Tool

• Establishing the path. Which route does traffic take, and is it the one you expect?
• Detecting routing changes. Comparing today's path against a recorded baseline.
• Finding where a path stops entirely. The last responding hop narrows the search considerably.
• Confirming a VPN is routing correctly, by checking whether traffic enters the tunnel.
• Speed. When you need an answer in ten seconds.
• Identifying routing loops, visible as the same hops repeating.

When PathPing Is Worth the Wait

• Intermittent problems where you need statistics rather than a snapshot.
• Quantifying loss at a specific point, with enough samples to be credible.
• Building evidence for a provider, where a three-probe traceroute will be dismissed.
• Confirming a fix, by comparing loss figures before and after a change.
• Situations where you can afford the time, typically planned investigation rather than live incidents.

The Better Answer: MTR

Both Windows tools are adequate and neither is the best available. MTR combines the two approaches and improves on both.

It performs a continuous traceroute, updating live, showing per-hop loss and latency statistics that accumulate while you watch. You get PathPing's statistical depth with tracert's immediacy, and you can leave it running while a problem occurs.

On Windows it is available as WinMTR. On Linux and macOS, mtr is usually a package away.

The workflow it enables is one neither native tool supports well: start MTR, wait for the user to report the problem happening, and look at which hop degraded at that moment.

Reading the Hostnames Along the Path

One skill worth developing: the reverse DNS names of intermediate hops carry a surprising amount of information, and learning to read them tells you where you are in the world without any additional tools.

Providers follow loose naming conventions, and common elements recur:

• Airport codes identify locations — lhr for London, fra for Frankfurt, cai for Cairo, nyc or jfk for New York. A hop named with a distant airport code when your traffic should be local indicates the path is taking a detour.
• Interface descriptors such as ae, bundle, or xe indicate link types and aggregation on the provider's equipment.
• Role indicators such as edge, core, border, agg, or cust describe where in the provider's hierarchy that router sits.
• Exchange point names such as ix or peer mark where traffic moves between providers, which is frequently where problems occur.

This is why running tracert without -d is occasionally worth the extra time despite being slower. Seeing that your traffic to a server in the same city is routing through another continent explains a latency problem instantly, and no amount of loss statistics would have revealed it.

The caveat is that these names are set by whoever administers the device, may be outdated, and occasionally reflect nothing at all. Treat them as a strong hint rather than as fact.

A Practical Workflow

1. Start with tracert -d to establish the path quickly.
2. Apply the persistence rule to any apparent loss before drawing conclusions.
3. Identify the first hop where loss persists through every subsequent hop.
4. Determine whose equipment that is — yours, your provider's, or beyond.
5. If it is yours, investigate that device directly rather than through probes.
6. If it is not yours, run PathPing or MTR to gather statistics that will withstand scrutiny.
7. Capture the output with timestamps, because a provider will ask when it occurred.
8. Run a control test to a different destination, to establish whether the problem is path-specific or general.

That final step is frequently skipped and frequently decisive. If every destination shows the same behaviour, the problem is near you, and no amount of tracing toward one particular site will find it.

The Summary

Tracert answers "which way does traffic go and where does it stop." PathPing answers "how much is being lost, and where." MTR answers both, continuously, and is the better tool where you can install it.

But the tool matters less than the interpretation. An administrator who understands why routers deprioritise probe responses will reach correct conclusions with either command. One who does not will misread both, confidently, and spend the afternoon chasing a hop that was working perfectly the whole time.