PCAP Analyzer

Read a packet capture in your browser without installing Wireshark

You have a .pcap or .pcapng file and a question about it: which host is flooding the link, what is that machine talking to, is there anything on the wire that should not be there. Opening Wireshark is the complete answer, but it is not always the fast one — you may be on a borrowed laptop, a locked-down jump box, or a phone. This analyzer reads the capture directly in the browser tab and gives you the summary layer of that answer in a few seconds: how many packets, over what span of time, which protocols, which hosts, which conversations, which ports.

The capture never leaves your machine. The file is read with the browser's own FileReader and parsed by JavaScript running in your tab. There is no upload, no server-side job, no temporary storage. That matters more here than for almost any other kind of file: a packet capture from a production network routinely contains session cookies, internal hostnames, credentials sent over plaintext protocols and the shape of your entire internal addressing scheme. If a browser tool asks you to upload a capture, you have handed all of that to someone else. This one does not ask.

What the parser actually reads

Both major capture container formats are supported. Classic libpcap files are recognised by all four magic numbers — big-endian and little-endian, microsecond and nanosecond variants — so a capture written by tcpdump on a big-endian appliance opens the same as one from Wireshark on a laptop. PCAPNG files are read through the common block subset: the Section Header Block (which also settles byte order), the Interface Description Block (which carries the link type), and Enhanced and Simple Packet Blocks.

Inside each frame, the link layer is decoded for the types below, then IPv4 or IPv6, then the transport header.

At layer 3 the parser identifies IPv4, IPv6 and ARP. At layer 4 it reads TCP, UDP, ICMP and ICMPv6, pulling source and destination ports and, for TCP, the flag bits: FIN, SYN, RST, PSH, ACK and URG. An application-protocol label is attached by matching either port against a table of well-known services — SSH, Telnet, FTP, SMTP, DNS, DHCP, TFTP, HTTP, Kerberos, POP3, NTP, MS-RPC, NetBIOS, IMAP, SNMP, BGP, LDAP, HTTPS, SMB, IKE, Syslog, RADIUS, RDP, SIP, mDNS, MySQL, PostgreSQL, MSSQL, Oracle, VNC, Redis, Elasticsearch, Memcached, MongoDB and others.

What you get on screen

• Capture overview — packet count, total bytes on the wire, elapsed duration from first to last timestamp, capture start time, container format, link type name and file size.
• Transport protocols — TCP, UDP, ICMP, ICMPv6 and "other" with counts and percentage of total packets.
• Application protocols — the top twelve service labels derived from ports, with packet counts.
• TCP flags — how many packets carried each flag across the whole capture.
• Top talkers — the ten busiest IP addresses by bytes, counting each address whether it appeared as source or destination.
• Top conversations — the ten heaviest host pairs by bytes. The endpoint pair is sorted before it is keyed, so both directions of the same conversation are merged into one row rather than appearing twice.
• Top ports — the ten most frequent ports, with a service label where one is known. Ephemeral ports above 49151 are excluded so the client side of every connection does not swamp the list.
• Export summary — a plain-text file containing the overview, protocol counts, top talkers and top conversations, ready to paste into a ticket.

A triage workflow that fits the summary

Find the noisy talker. Start with Top Talkers, which is sorted by bytes rather than packets, because a link is saturated by volume. If one internal address holds most of the bar, drop to Top Conversations and read who it is paired with. A single host pushing tens of megabytes to one external address is a very different story from the same host spreading the same volume across two hundred peers — the first looks like a backup or an upload, the second looks like a scan.

Read the protocol mix against expectation. A server segment that is normally HTTPS and DNS suddenly showing a large ICMP share, or a large "other" share, is worth a second look. So is a Top Ports list containing services nobody remembers enabling. The Application Protocols panel is the fastest way to notice that Telnet, FTP, or SNMP is still alive somewhere on the segment.

Check the TCP flag balance. The flag counts are a whole-capture total, not per-flow, but they are still informative in bulk. A large SYN count with a small ACK count is the signature of connections that are being attempted and not completed — port scanning, a host hammering a dead service, or a firewall silently dropping traffic. A high RST count says something is actively refusing connections.

Spot the shape of beaconing. Command-and-control traffic tends to look small and regular: a modest byte total, a high packet count, one external peer, repeated over the life of the capture. In this tool you see that as a conversation with a lot of packets but comparatively few bytes, sitting in the list next to a single external address. The tool does not compute inter-packet timing, so it cannot confirm the fixed interval that would make the case — treat it as a lead, then take the pair into Wireshark and apply a filter such as ip.addr == x.x.x.x to look at the timing directly.

Locate plaintext credentials — but expect to finish elsewhere. This is the honest limit of the tool. It does not inspect payloads, so it cannot show you a password. What it can do is tell you that packets crossed the wire on port 21, 23, 25, 110, 143, 161 or 389, which is exactly the list of protocols that carry credentials in the clear. Seeing FTP or Telnet in the Application Protocols panel is the finding; extracting the string is a job for Wireshark's Follow TCP Stream on that conversation.

What this tool deliberately does not do

The design tradeoff is deliberate. Everything above the line can be computed from headers alone, with no network calls, in a tab. Everything below it needs either payload reassembly or an external service, and the second of those would break the privacy guarantee that makes the tool worth using on a real capture.

Limits and caveats worth knowing before you trust a number

• 100 MB file ceiling. Larger files are rejected with a message rather than crashing the tab. Trim the capture in Wireshark first — apply a display filter and use File → Export Specified Packets.
• 200,000 packet ceiling. Beyond that, parsing stops and the results banner tells you the analysis covers the first N packets. Percentages are then percentages of what was read, not of the whole file.
• PCAPNG timestamp resolution is assumed to be microseconds. The if_tsresol interface option is not parsed. A pcapng file written with nanosecond resolution will show an implausible start time and duration — the packet, protocol and host figures are unaffected, but treat the clock with suspicion if it looks wrong. Classic pcap files carry resolution in the magic number and are handled correctly in both variants.
• Truncated captures stop cleanly. If a capture was cut off mid-record — a killed tcpdump, an incomplete download — parsing stops at the last complete packet and reports what it read rather than failing outright.
• "Total traffic" is wire length, not captured bytes. Sums use the original on-wire length of each packet, so a capture taken with a snaplen (for example tcpdump -s 96) still reports realistic volume even though only the first bytes of each packet were stored.
• An unrecognised magic number is refused. Files that are not pcap or pcapng — a .etl from Windows netsh, an .erf, a compressed .pcap.gz — produce a clear error. Decompress or convert first; editcap and tshark both write standard pcapng.

Getting a capture worth analysing

On Linux or macOS, tcpdump -i eth0 -w capture.pcap writes a classic pcap; add -s 0 if you want full packets and -c 50000 to stop after a fixed count. Capturing on -i any produces a Linux cooked capture, which this parser handles. On Windows, Wireshark's default save format is pcapng. From a firewall or switch, export in pcap or pcapng rather than a vendor format. If your capture is much larger than the ceiling here, the most useful trim is usually by host or by time window rather than by protocol — you want the whole story of one machine, not a fragment of everything.

Once you have a shortlist of suspicious external addresses from the Top Talkers and Top Conversations panels, the natural next step is pulling those addresses out as structured indicators — the IOC extractor takes pasted text and returns deduplicated IPs, domains, URLs and hashes ready for a ticket or a blocklist.