PCAP Analyzer

Open a pcap or pcapng capture in the browser and read it packet by packet: every layer from Ethernet to DNS and TLS decoded, TCP problems found by Wireshark's rules, streams followed, and the bytes behind every field.

Overview

A packet capture records the frames that crossed a network interface, byte for byte, with the moment each one arrived. tcpdump and Wireshark write them as pcap or its successor pcapng. Reading one shows what actually happened: which names were looked up and how fast they were answered, which connections opened and how they ended, where data had to be sent twice, which server a TLS connection asked for, and what an unencrypted conversation said.

This tool reads the file in the browser, in a background worker, so the page stays usable while hundreds of megabytes are worked through. The capture is never uploaded.

Web interface

Drop a capture onto the field or click it to choose one; Open the sample capture loads a short recording made for this page, with a download that lost packets on the way. While the file is read, a bar shows how far it has got.

The list is drawn only where it is on screen, so a capture of 850,000 packets scrolls as easily as one of ten. Click a packet, or move with the arrow keys, Page Up, Page Down, Home and End. A TCP reset is marked in red in the Info column, and so is every packet the TCP analysis found a problem with.

Files and link types

A capture compressed with gzip or packed in a zip is recognised as such and has to be unpacked first. A file that ends in the middle of a packet is read up to the last whole one, and the Capture panel says where it stopped.

What is decoded

TCP sequence and acknowledgement numbers are shown relative to the start of each direction, as Wireshark shows them: the SYN is 0, and in a stream whose SYN was not captured the first segment counts as byte 1. The window is multiplied by the scale both sides announced in their SYNs. A TLS record that runs over several segments is named where it starts and where it ends.

The decoding was checked against tshark 4.6.8, Wireshark's command-line version, on six captures: pcap with microsecond and with nanosecond timestamps, pcapng, a capture cut to 64 bytes per packet, a Linux cooked capture and the sample. Lengths, times to the nanosecond, MAC and IP addresses, ports, TCP flags, relative sequence and acknowledgement numbers, window sizes, DNS IDs, names and answers, the TLS server name, HTTP methods, URIs and status codes, ICMP and ARP types, and the protocols in each packet all matched, packet for packet.

TCP analysis

Every TCP segment is checked the way Wireshark checks it: the rules, their order and their thresholds follow the function that does it in Wireshark 4.6.8, with Wireshark's default settings. What it finds is noted in front of the Info column in Wireshark's words, such as [TCP Retransmission] or [TCP Dup ACK 12#3], and explained under SEQ/ACK analysis in the details.

problem finds every packet with one of the first six. The initial round-trip time of a connection is the time from its SYN to the first acknowledgement after it, measured where the capture was taken, as Wireshark measures it.

Checked against tshark on two captures made for the purpose: a 3 MB download over a link that dropped 2% of its packets and reordered 3%, and a download read so slowly that the receiver's window filled up. Every retransmission, fast and spurious retransmission, out-of-order segment, gap, duplicate ACK and its number, zero window, full window, window update and keep-alive was flagged on exactly the packets tshark flags, and every initial round-trip time matched to the nanosecond.

DNS response times

A DNS response is paired with the query of the same ID in the same conversation, and its response time is the time between the two, which is how Wireshark measures it. The details of a query name the packet with its response, and the details of a response the packet with its query and the time. The DNS part of the Capture panel lists the slowest answers and the queries that got none in the capture, each a click away from its packet. The times matched tshark's to the nanosecond.

Follow TCP stream

Follow TCP stream appears above the details of a TCP packet, and as follow in the conversations. It puts both directions of the connection back together: each in the order of its sequence numbers, data sent twice only once, and data that arrived early after what comes before it. The two directions are shown in two colours, in the order they arrived, as text or as hex. A stretch the capture never saw is marked with how many bytes are missing.

Download saves the stream's bytes exactly as they were sent, both directions or one; Show its packets filters the packet list to the connection. Up to 4 MB of a stream are put back together, and the first 256 KB are shown on the page. On all eight connections in the test captures, the 3 MB download over the lossy link included, the bytes were identical to what tshark's Follow TCP Stream gives.

The filter

Every word in the filter must match. or separates alternatives, and not or ! in front of a word turns it round.

So tcp port 443 not 10.0.0.1 finds HTTPS traffic of every host but one, and retrans or rst finds the retransmissions and the resets. A word the filter cannot use is explained under the field, such as "port" needs a number from 0 to 65535 after it. The filter is not Wireshark's display filter language, which is a project of its own.

Conversations

A conversation is all traffic between two endpoints in both directions: two addresses and two ports for TCP and UDP, two addresses for ICMP and the rest. They are sorted by bytes, and the 500 largest are listed with their initial round-trip time and, for TCP, how many retransmissions, gaps, out-of-order segments, duplicate ACKs and zero windows they had. A click on one filters the packet list to it.

Limits

• Files up to 500 MB are read. In Chrome on a current Mac, a capture of 850,000 packets and 173 MB is read, TCP analysis included, in just over a second, and a search of the Info column across all of it takes about as long.
• Segments are put back together only to follow a stream. A TLS record that runs over several segments is named where it starts and where it ends, and an HTTP message that does is read as far as its first segment goes.
• Encrypted traffic stays encrypted. TLS and QUIC are shown only as far as they travel in the clear.
• The hex view shows the first 16,384 bytes of a packet, which only matters for captures taken before the network card split large segments.

How to capture

# macOS: the Wi-Fi or Ethernet interface is usually en0
$ sudo tcpdump -i en0 -w capture.pcap

# Linux: every interface at once, written as a Linux cooked capture
$ sudo tcpdump -i any -w capture.pcap

# Stop after 1000 packets, and only DNS
$ sudo tcpdump -i en0 -c 1000 -w dns.pcap port 53

tcpdump stops with Ctrl+C. Wireshark captures on macOS, Linux and Windows and saves pcapng. A capture holds whatever crossed the interface, often passwords, cookies and session tokens, so keep it only as long as you need it.

No API

Privacy

Nothing is uploaded. The file is read by a worker on this page and is gone when the page is closed. The sample capture comes from this site; it was recorded between two empty containers and holds no one's traffic.