PCAP Analyzer

Drop a packet capture — .pcap or .pcapng — and get the first-ten-minutes view: the conversations that moved the bytes, every DNS question and answer, the cleartext HTTP requests, the TLS server names and JA3 fingerprints, and a short list of credentials that crossed the wire unencrypted. The file never leaves your device: it is parsed in this page, not uploaded, because a capture is evidence and evidence does not get posted to strangers' servers.

Or drop the file anywhere in this box. Parsing happens in chunks with a progress readout, so a multi-megabyte capture does not freeze the tab.

What the first ten minutes are for

A capture is usually taken in a hurry — something is slow, something is talking to the wrong place, something is suspected — and opened under pressure. The order of questions matters more than any single answer. Start with the conversations: sorted by bytes, they say who actually used the network in the window, and the surprise is usually visible immediately — a workstation holding a long conversation with an address nobody recognises, a server uploading far more than it downloads, a protocol that should not be there at all. Then DNS, because names are intent: the queries a host made are the closest thing a capture has to a browsing history of what it was trying to reach, and the answers pin those names to addresses at the moment of the capture, not as DNS resolves today. Then TLS metadata: encryption hides content, not existence — the SNI names and JA3 fingerprints still say which services were contacted and what kind of client software made the connection. Finally the cleartext surprises: the HTTP requests and credential warnings, because in 2026 any password crossing a network readable by a passive observer is an incident on its own, whatever the original question was. The companion guide, first ten minutes with a packet capture, walks that order as a workflow, including when to stop triaging and open Wireshark instead.

Three honest limits shape what this page claims. It does not reassemble TCP streams — it reads packets one by one and aggregates them into flows, so an HTTP request or ClientHello that the capture split across segments can be missed; captures taken on a host (rather than a tap) also show segmentation offloading artefacts, a caveat the guide explains. It does not decrypt anything: there is nowhere to paste a key log, deliberately, because key logs are among the most sensitive files that exist and they do not belong in a web page. And its credential list is a set of recognised patterns, not an audit — absence of a warning is not evidence of absence. What it does guarantee is the direction of data flow: your capture is read by code running in your browser tab and is never uploaded, logged or shared, so the triage itself cannot become the leak. For captures that begin on a live server, the port scanner shows what the host exposes and the email header analyser covers the other file that arrives during an incident — the suspicious message itself.

Frequently asked questions

Where does my capture file go?

Nowhere. The file is read and parsed in this page, on your device, and nothing is uploaded, transmitted or stored — the page makes no network request when it analyses a file. That is a deliberate design, because a packet capture is one of the most sensitive files on a network: it holds internal addresses, hostnames, and — in cleartext protocols — literal credentials. It also works offline once the page has loaded, which is where a capture usually gets read anyway: on the machine that took it, often during an incident.

Which capture formats and link types are supported?

Classic PCAP in either endianness, with microsecond or nanosecond timestamps, and PCAPNG — section, interface, enhanced and simple packet blocks, plus name-resolution blocks, whose recorded names are shown in the summary. Link types: Ethernet (including VLAN-tagged frames), raw IP, BSD loopback, and Linux cooked SLL and SLL2. IPv4 and IPv6, TCP, UDP and ICMP are decoded. Other link types are counted in the protocol mix but not decoded, and the summary says so rather than staying silent.

What can it not do?

Three limits, stated plainly. It does not reassemble TCP streams — analysis is per packet plus per-flow aggregation, so a ClientHello or HTTP request split across segments can be missed. It cannot decrypt anything: TLS and other encrypted traffic yields metadata only (server name, ALPN, JA3), never content. And its credential findings are sightings, not a clean bill of health — it flags the cleartext patterns it recognises (HTTP Basic, FTP, SMTP AUTH, POP3, IMAP, telnet), and the absence of a flag proves nothing about protocols it does not inspect. For deep work — stream following, protocol dissectors, decryption with key logs — use Wireshark; this page is the first ten minutes, not the whole investigation. The companion guide, first ten minutes with a packet capture, lays out that triage order.

What is the JA3 fingerprint shown for TLS connections?

JA3 is a standard way to fingerprint a TLS client from its ClientHello: the TLS version, cipher suites, extensions, elliptic curves and point formats, listed in order as decimal numbers (with GREASE values removed), joined into one string and hashed with MD5. Two clients with the same library and settings produce the same JA3; a scanner or malware family often has a characteristic one. It identifies the client software's habits, not the user, and it changes when libraries update — treat it as a clustering hint, not an identity.

How large a capture can I open?

Files up to 25 MB. That ceiling is deliberate: the whole file plus the analysis structures live in your tab's memory, and a desktop browser handles that comfortably, while a phone may not. In testing, a 10 MB capture with ~90,000 packets parsed in about a second. For anything bigger, filter first at capture time or with editcap/tcpdump on your own machine — tcpdump -r big.pcap -w slice.pcap host 203.0.113.10 — and bring the slice here.