Free PCAP and PCAPNG Analyzer

A short paragraph plus a few ranked findings. Each finding has three lines: What we saw (the raw observation), What it means (plain-English interpretation), What to do (a concrete next step). Cleartext credential leaks rank highest because the capture itself becomes sensitive; then critical root causes, then TCP health summary, capture quality, and informational notes.

JA3 (the original spec) builds a string from a TLS ClientHello: TLS version, cipher list, extension types, supported_groups, and ec_point_formats, with GREASE values filtered out. The MD5 of that string is the JA3 hash. Different software produces different shapes, so the same hash usually means the same client (a specific Chrome version, curl, Python requests, Go default, or a specific malware family). The tool ships with a small known-JA3 lookup so common tools are labeled by name.

Each unique 5-tuple flow gets a letter grade based on: did the handshake complete (SYN, SYN+ACK, final ACK), what percentage of data segments were retransmits, did the receive window hit zero (buffer stalls), did either side send RST mid-flight, and the time-to-first-byte after the handshake. Healthy flows grade A. Heavy retransmits or zero-window stalls grade B or C. Connections closed by RST grade D. Connections that never completed the handshake grade F.

HTTP Basic Auth headers, HTTP form POSTs with password fields, FTP USER and PASS commands, any Telnet payload (Telnet has no encryption), SMTP AUTH on port 25 or 587 without prior STARTTLS, IMAP LOGIN on plain port 143, POP3 USER and PASS on plain port 110. Each leak shows a redacted snippet and a concrete fix. Findings contribute to a privacy grade A-F. The tool also offers an "Export leak packets .pcap" button so you can extract just the offending packets for review or stripping.

Some malware uses a Domain Generation Algorithm to compute random-looking domain names so its command-and-control server does not need a fixed location. The heuristic flags DNS queries whose leftmost label is at least 8 characters, alphanumeric, and has Shannon entropy above 3.0 (real subdomains like "www" or "example" stay below this). Combined with a high NXDOMAIN ratio it strongly suggests an infected host on the network.

Yes. The tool can re-emit a smaller classic .pcap containing only the packets you care about. Two presets are built in: "Export failing flows .pcap" (every packet from grade D and F TCP flows) and "Export leak packets .pcap" (every packet flagged by the cleartext credential detector). The exported file opens in Wireshark like any other capture.

Several signals: the share of packets that hit the declared snaplen (suggests payload was truncated at capture time), the idle ratio (how many seconds had no packets, useful to spot long quiet stretches that bloat the file), orphan ACKs and orphan RSTs (flows that were already in progress when capture started or packets that were dropped at capture time), parse errors, and the ratio of SYNs vs SYN+ACKs to infer whether the capture point was client-side, server-side, or in the middle. The tool tells you whether to recapture and how.

For each TCP flow that took over 1 second total, the tool decomposes the time into: handshake RTT, time-to-first-byte after handshake (server compute), retransmit overhead, and zero-window stall time. The biggest component is named the bottleneck. For example, a 12.4-second conversation where 11.8 seconds was server wait will be marked as a server bottleneck, not a network problem.

No. Without decrypting anything, the size and timing pattern of packets often gives away the application. Streaming video shows up as sustained large packets with low size variance. VoIP / RTP shows up as small packets at fixed intervals. Bulk download is a short burst of large packets. Interactive shells are small irregular packets. Tor / fixed-MTU VPNs show highly uniform sizes. The classifier labels each TLS-shaped flow with the most likely category and the reason.

IP packets carry a Time-To-Live (or Hop Limit on IPv6). Modern stacks set the initial TTL to a standard value: 64 for Linux / macOS / BSD, 128 for Windows, 255 for Cisco / routers. The observed TTL is the initial value minus the number of hops the packet crossed. The tool snaps the observed TTL up to the nearest standard initial value and reports the OS family and hop count. Confidence is high when only one TTL is seen for a host, lower when several different TTLs appear.

Conversations are paired by the unordered pair of source and destination IPs. The diff lists which conversations are new (in "after" only), removed (in "before" only), or changed (significant packet or byte delta). It also lists hosts and TLS SNI hostnames added or removed, and which root causes are now resolved or newly present. Useful for "the network was fine yesterday, here is today, what changed".

No. The file is parsed in your browser. You can verify in the browser dev tools network tab during upload. Captures often contain auth cookies and credentials, so this matters; treat the file as sensitive even when staying local.

SYN floods (high SYN count with low ACK from one source), TCP RST storms, ARP spoofing (one IP claimed by multiple MACs), TCP port scans (one source touching many ports on one destination), unusually high DNS query volumes to a single resolver, NXDOMAIN storms, and high TCP retransmission rates per flow. These come in addition to the verdict and root-cause sections; the verdict synthesises across them.