TL;DR. PCAP Parser turns a pcap or pcapng file into a set of views in your browser: summary tiles, a protocol hierarchy, conversations, DNS, HTTP, TLS metadata, extracted files and an indicator list, with a filter box, a "flagged only" switch, UTC/local time and CSV/JSON export. Nothing is uploaded. This guide walks through each view with the built-in synthetic sample so you know what every column means and where the limits are.

The examples below use the Try a sample capture, a synthetic pcapng of a fictional incident on a workstation called FIN-WKS-07. All public addresses in it come from documentation ranges (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24). If you are still weighing your options for viewing a capture without installing software, start with how to open a pcap file online; if the capture holds client or personal data, read why local analysis matters first.

Step 1: load the capture

Open the in-browser pcap viewer and drop a file on the drop zone, or use Choose files or Choose a folder. You can drop several captures, a folder of rotated files or a ZIP archive; each one becomes a source you can select later.

The format is detected from the file's first bytes, so the extension does not matter. Classic pcap in both byte orders (microsecond and nanosecond) and pcapng with several interfaces are supported; the differences are covered in pcap vs pcapng. Compressed captures and unsupported formats are listed under Files not parsed with the reason.

Parsing runs in a Web Worker. The file is read in 8 MB slices and fed to a Rust parser compiled to WebAssembly, and a progress bar shows how far it is.

Step 2: read the summary tiles and notes

The top row shows packets, bytes on the wire, duration, conversations and the number of flagged items. Under it, the capture window gives the first and last timestamp.

Two notes deserve attention when they appear:

Packets cut by the capture's snaplen. Those packets were truncated at capture time. The sample has one.
Bytes missing from reassembled TCP streams. The TCP reassembly found holes, so some bodies or files will be incomplete.

If a list hits its size cap, a banner names it. The caps are 200,000 conversations, 100,000 DNS records, 50,000 HTTP and 50,000 TLS records, and 5,000 extracted files (256 MB of file data in total). Split very large captures if you need everything.

Step 3: open the protocol hierarchy

The collapsible Protocol hierarchy panel counts packets and bytes per protocol path, such as eth/ipv4/tcp/tls or null/ipv4/tcp/http. It answers "what kind of traffic is this?" before you read a single row. In the sample, TLS carries most of the bytes, and a second link type (null, BSD loopback) shows that the capture included the loopback adapter.

Step 4: review conversations

The Conversations tab lists one row per flow, keyed by its 5-tuple: protocol, client, client port, server, server port. The client is the side that opened the connection. Columns give packets, bytes, bytes sent by the client (Out) and duration; click a row for the per-direction detail, start and end times, and any TCP gap.

Sort by Out to find uploads. In the sample, one TLS conversation from 10.10.20.57 to 198.51.100.77 on port 443 sends about 1.3 MB and receives far less. It carries the Large outbound transfer flag, which PCAP Parser sets when a client sends at least 1 MiB to a public address and at least three times what it received.

Step 5: DNS, HTTP and TLS

DNS

The DNS tab shows each query with its type, result code and answers. Flags point at two patterns: Random-looking / long name (a name over 60 characters, or a label of 12 or more characters with high character entropy) and Rarely-seen domain (a registrable domain looked up only once and not on a short list of common background domains). The sample has two random-looking .info and .top names that return NXDOMAIN. How to read these without over-reacting is the subject of DNS analysis in a pcap.

HTTP

The HTTP tab pairs each request with its response: method, URL, status and content type. The detail sheet shows the request and response headers, user agent, referer and body sizes. The sample includes a download of tools.zip over plain HTTP, flagged Archive download because the body's magic bytes identify a ZIP.

TLS

TLS payloads are encrypted, but the ClientHello is not. The TLS tab shows the SNI, the offered version, ALPN values, and the JA3 and JA4 fingerprints. The detail sheet adds the server's negotiated version and chosen cipher, and the JA3S fingerprint. A session to a non-standard port (the sample has one on 4443) gets the Non-standard port flag. What these fingerprints mean is explained in JA3 and JA4 TLS fingerprinting.

Step 6: check extracted files

The Files tab lists objects rebuilt from HTTP bodies after reassembly, in both directions (download and upload). Each row gives the name, detected file type, size and SHA-256; gzip and deflate encodings are decoded first. Executables and archives are flagged from their magic bytes, not their names. Click a row and use Download file to save the object for sandboxing or hashing; handle it as potentially malicious. An object marked incomplete had missing bytes.

There is also an SMB tab listing SMB2 share connections and file or folder opens by path, with a flag on administrative shares.

Step 7: collect IOCs and export

The IOCs tab merges every IP, domain, URL and file hash from the other views into one de-duplicated IOC list, with a count, first and last seen, where it was seen (conversations, DNS, HTTP, TLS, files) and, for IPs, a scope (public, private, loopback, link-local, multicast). Filter on public to get the list you would look up in threat intelligence.

Every view has the same toolbar:

a filter box that searches every column of the current view;
a capture selector when several files are loaded;
Flagged only, to keep rows with at least one flag;
UTC / Local for timestamps;
CSV and JSON export of the rows currently shown.

Reading flags correctly

Flags are simple heuristics meant to guide triage, not verdicts. A backup job can look like a large outbound transfer; a CDN can produce random-looking names. Always confirm in the raw data, and open the same capture in Wireshark when you need packet-level detail. The tools comparison explains when to switch.

Known limits

PCAP Parser does not decrypt TLS, SSH, QUIC or SMB3. QUIC and HTTP/3 are counted but not decoded past UDP, IP fragments are counted but not reassembled, and files are carved from HTTP only. These are listed openly so a missing result is never mistaken for an absence of activity.

How to Use PCAP Parser: A Tour of Every View