Ping Results Analyzer

Target label:

Hostname, IP, ticket label, or service name represented by this ping sample.

Packet loss gate:

Use 0 for strict reachability checks or a small tolerance for noisy wireless paths.

Jitter gate:

Measured from reply-to-reply RTT deltas, not from the operating-system summary line.

High RTT gate:

Set near the user-facing latency budget for this target or path.

Ping output:

Paste one ping run with reply lines plus the packet-loss and RTT summary when available.

{{ fileStatus || 'Drop ping TXT, LOG, or OUT output onto the textarea.' }}

Ping input needs attention

{{ error }}

Sample row limit:

Keep long continuous ping runs readable in the sample ledger.

samples

Metric	Value	Interpretation	Copy
{{ row.metric }}	{{ row.value }}	{{ row.note }}

Seq	RTT	TTL	Flag	Source line	Copy
{{ row.sequence }}	{{ row.rttDisplay }}	{{ row.ttlDisplay }}	{{ row.flag }}	{{ row.sourceLine }}

Finding	Severity	Evidence	Suggested next check	Copy
{{ row.finding }}	{{ row.severity }}	{{ row.evidence }}	{{ row.nextCheck }}

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Ping results are a quick reachability record, but the important signal is rarely one number. Packet loss, round-trip time, timeout lines, sequence gaps, and sudden latency jumps can point to different parts of a network problem. Reading them together helps separate a missing route from a busy wireless link, a blocked ICMP path, or a short sample that is too thin to trust.

Ping Results Analyzer turns pasted ping output into a structured network reachability summary. It accepts Linux/iputils, macOS/BSD, Windows, and generic ping-style text, then reports packet loss, average round-trip time (RTT), jitter, high RTT samples, timeout lines, and the parsed output format. The target field is only a report label, so the page does not run a new ping against that host.

The result is best used as a triage brief, not as a final network diagnosis. Ping can be filtered, deprioritized, or answered differently from application traffic. A clean ping does not prove HTTP, SSH, DNS, or a game session is healthy, and a failed ping does not always prove the service itself is down. The value comes from turning a raw terminal excerpt into evidence that is easy to compare, copy, and hand off.

Pasted text and local TXT, LOG, or OUT files are analyzed in the browser session. The page reads the uploaded file text, normalizes line endings, and produces tables, charts, CSV, DOCX, and JSON from the parsed sample. The copied and downloaded results can still contain internal hostnames or IP addresses, so handle them like any other network diagnostic artifact.

Technical Details:

Most ping utilities send ICMP Echo Requests and measure the time until matching Echo Replies return. The analyzer does not create packets or contact the target. It reads the text produced by a ping run and extracts reply samples, packet counts, timeout markers, and summary statistics when they are present.

Reply lines are reduced to sequence number, RTT, optional time-to-live (TTL), and the original source line. Summary rows are handled separately because operating systems expose them differently. Unix-style summaries such as packets transmitted, Windows summaries such as Sent = and Received =, Linux rtt min/avg/max/mdev, and macOS/BSD round-trip min/avg/max/stddev are all recognized when they appear in the text.

Rule Core

Ping result parser surfaces and interpretation rules
Surface	How it is derived	How to read it
Parsed format	Looks for Windows packet text, macOS/BSD `stddev`, Linux/iputils `mdev`, or generic reply timing.	Use it as a parser confidence clue, especially when copied output came from several systems.
Packet loss	Uses the packet summary when available, otherwise infers sent and lost packets from reply and timeout lines.	Any loss above the configured gate becomes a finding; 10 percent or more is marked high severity.
Average RTT	Uses the operating-system summary average when present, otherwise computes the mean from parsed reply RTT values.	Good for broad distance or path comparison, but it can hide a few painful spikes.
Jitter estimate	Computes the average absolute change between adjacent parsed reply RTT values.	High jitter means the path is not just slow; it is changing from one reply to the next.
High RTT samples	Counts reply samples at or above the configured high RTT gate.	Useful when a few spikes matter more than the overall average.
Missing reply sequence	Compares parsed sequence numbers from replies and timeout lines and reports gaps that remain unexplained.	A gap may be a dropped packet, an omitted log row, or text that did not match a timeout pattern.

Calculation Core

The analyzer keeps summary-derived and row-derived values distinct. Packet loss prefers the operating-system packet summary because that is the run's own accounting. When no summary exists, the fallback uses parsed replies and timeout lines.

\begin{array}{lcl} loss percent & = & \frac{transmitted - received}{transmitted} \times 100 \\ jitter estimate & = & average of adjacent absolute RTT changes \end{array}

Linux mdev and macOS/BSD stddev are treated as the deviation value printed by the ping utility. If a run has reply samples but no deviation summary, the page computes population standard deviation from the parsed RTT values. The jitter estimate is separate from both values because it asks how much one reply changes from the previous reply.

Latency Bands

Latency band mix buckets
Band	RTT range	Use in the result
Sub-20 ms	`0` to less than `20` ms	Usually local, nearby, or very low-latency routing evidence.
20-50 ms	`20` to less than `50` ms	Common for regional paths and many user-facing services.
50-100 ms	`50` to less than `100` ms	Often acceptable for normal web use, but worth comparing against the service budget.
100-200 ms	`100` to less than `200` ms	May be noticeable for interactive work, voice, gaming, or remote desktop.
200+ ms	`200` ms and above	Usually deserves context, especially if mixed with lower-latency replies in the same run.

The visible sample ledger can be capped from 5 to 300 rows so long runs stay readable. That display limit does not change the full parsed series used by the charts, JSON export, packet summary, or latency band mix.

Everyday Use & Decision Guide:

Use the analyzer when a ticket, chat thread, incident note, or terminal capture includes ping output that needs a cleaner read. It is especially useful for comparing a local gateway test with a public target test, checking whether a short outage had actual packet loss, or showing that a path is reachable but unstable.

Start with gates that match the question. A packet loss gate of 0% is appropriate for strict reachability checks. A small tolerance can make sense for noisy wireless or cellular paths, but do not hide loss just because the application retries around it. The high RTT gate should reflect the path or service being investigated, not a universal internet rule.

Use Packet loss gate to decide when loss becomes a finding. Loss above the gate appears in the findings table.
Use Jitter gate when voice, streaming, games, remote desktop, or interactive shells feel inconsistent even though average RTT looks fine.
Use High RTT gate when a few spikes can hurt the user experience more than the mean value suggests.
Use Sample row limit only to keep the visible ledger readable. It is not a filter on the analysis itself.

For incident work, compare like with like. A five-packet sample can show an obvious failure, but it cannot describe a whole hour. A gateway ping and an internet ping answer different questions. A service hostname can also sit behind CDN, firewall, VPN, or resolver behavior that makes ICMP evidence useful but incomplete.

Do not treat TTL as a direct hop count without knowing the sender's initial TTL value. In this page, TTL is row evidence beside the RTT sample. It is helpful for spotting changes in reply character, but the analyzer does not convert TTL into a route map.

Step-by-Step Guide:

Work from source quality to findings, then export only after the parsed sample matches the ping run you intended to review.

Enter a Target label. Use a hostname, IP address, ticket label, or service name that will make exported rows understandable later.
Set Packet loss gate, Jitter gate, and High RTT gate. The defaults are strict on loss, moderate on jitter, and permissive on individual RTT spikes.
Paste one ping run into Ping output, browse for a TXT, LOG, or OUT file, drop a file onto the textarea, or load one of the built-in sample runs.
Click Normalize after copying from a terminal or ticket. It trims trailing spaces and normalizes line endings without changing the meaning of the output.
If the summary says Check output, confirm the text includes reply timing lines or a recognizable packet summary.
Read Ping Health Snapshot first. It shows parsed format, packet loss, average RTT, jitter estimate, high RTT sample count, and timeout line count.
Open Connectivity Findings for the short incident note. Each finding includes severity, evidence, and a suggested next check.
Use RTT Sample Ledger when you need row-level proof, especially around a spike, timeout, or suspected omitted sequence.
Use the trend chart, latency band mix, CSV, DOCX, image, or JSON export after the parser evidence is credible.

Interpreting Results:

The summary headline tells you whether the current sample has input issues, high-severity reachability loss, other latency findings, or no threshold finding. The badge row is a compact status line, but the tables explain why the headline changed.

Ping result cues and first checks
Visible cue	Best first reading	What to verify next
Reachability Loss Detected	Packet loss or no parsed replies is severe enough to lead the result.	Run a longer sample and compare gateway, target, and intermediate hop behavior.
RTT jitter above gate	Reply times are changing sharply from one reply to the next.	Compare wired versus wireless, check uplink saturation, and look for queueing during the sample window.
High RTT samples	One or more replies crossed the configured latency spike gate.	Correlate the spike with application errors, CPU load, VPN changes, or busy links.
Missing reply sequence	Parsed sequence numbers have a gap not explained by a recognized timeout line.	Check whether the source excerpt omitted lines or used timeout wording the parser did not recognize.
No threshold finding	The parsed sample stayed below the configured loss, jitter, and high RTT gates.	Use a longer continuous test if the reported issue is intermittent.

The RTT trend is strongest for spotting shape: one isolated spike, repeated oscillation, or a steady path that shifted upward. The latency band mix is better for explaining the sample at a glance, because it shows whether most replies lived in one range or were scattered across several ranges.

Treat exported JSON as the most complete handoff format. It includes thresholds, source format, packet summary, RTT summary, findings, missing sequences, timeout lines, parsed samples, and latency band rows.

Worked Examples:

Linux-style sample with loss and jitter

The built-in Linux-style sample sends five packets, receives four replies, and reports 20.0% packet loss. The reply RTT values are 24.1, 26.8, 83.4, and 27.7 ms, with one timeout line for sequence 4. With the default loss gate at 0%, the finding is high severity. The average successive RTT change is about 38.33 ms, so it also crosses the default 20 ms jitter gate. Because the high RTT gate defaults to 120 ms, none of those replies is counted as a high RTT sample.

Windows sample with the same operational shape

The Windows sample uses different wording but describes the same pattern: five sent, four received, one lost, and an average RTT around 42 ms. The analyzer recognizes the Windows packet summary, extracts reply times from Reply from lines, and reports loss and jitter through the same findings table. That makes mixed operating-system evidence easier to compare in one incident note.

Gateway clean, remote target unstable

Run one ping to the local gateway and one to the remote service, then analyze them separately with the same gates. If the gateway sample has no loss and low jitter while the remote sample shows loss or spikes, the problem is more likely beyond the local Wi-Fi hop. If both samples show jitter or loss, start closer to the client, wireless link, VPN tunnel, or access router before blaming the remote service.

Short sample with no finding

A four-reply sample can stay under every gate and still miss an intermittent issue. The right reading is limited confidence, not proof of health. Increase the packet count, capture during the reported symptom window, and compare the same target from another network before closing a recurring complaint.

FAQ:

Does the page run ping for me?

No. It analyzes ping text you paste or load from a local text file. The target label is used in summaries and exports only.

Why does packet loss come from the summary instead of the visible reply rows?

When the ping output includes its own packet summary, that line is the best accounting for sent and received packets. The page infers loss from reply and timeout lines only when no recognizable summary exists.

Is jitter the same as mdev or stddev?

No. mdev or stddev describes spread around the average. The jitter estimate on this page is the average change between neighboring reply RTT values.

Why did a missing sequence appear when packet loss is zero?

The sequence check depends on parsed sequence numbers. A copied excerpt, omitted line, or unusual timeout message can leave a visible sequence gap even when the packet summary says no loss.

Can I use a huge continuous ping log?

Text files are limited to 1 MB in the file picker. Long pasted text can still be hard to review, so use the sample row limit to keep the ledger readable while keeping the full parsed data in charts and JSON.

Does a failed ping prove the service is down?

Not by itself. Firewalls, ICMP rate limits, VPN policy, target configuration, and routing can affect ping differently from the application protocol users care about.

Glossary:

RTT: Round-trip time, measured in milliseconds, from the sender to the target and back.
Packet loss: The share of transmitted ping packets that did not produce a received reply in the sample.
Jitter: Variation between neighboring reply times. This page estimates it from adjacent RTT changes.
TTL: Time to live, a field returned in many ping replies. It is useful row evidence but not a direct route length by itself.
mdev: The deviation value printed by Linux/iputils ping in its RTT summary.
Timeout line: A source line stating that a request timed out, had no answer yet, or could not reach the destination host.

References:

RFC 792: Internet Control Message Protocol, IETF, September 1981.
RFC 4443: ICMPv6 for IPv6 Specification, IETF, March 2006.
ping(8) Linux manual page for iputils, Michael Kerrisk, Linux man-pages project.