TCP Capture Viewer

How to use this TCP capture viewer

1. Export a capture as classic .pcap (in Wireshark: File → Export Specified Packets → .pcap format).
2. Upload the .pcap file above.
3. Use the conversation filter to isolate one connection and follow its handshake and sequence numbers.

How does this work?

Your capture file never leaves your device. It's parsed directly in the browser from the raw .pcap bytes — Ethernet, IPv4 and TCP headers are decoded locally to build a readable table, grouped by conversation and with 3-way handshakes flagged automatically.

The three-way handshake — what it actually establishes

TCP's three-way handshake (SYN, SYN-ACK, ACK) isn't just a greeting — it exists specifically to let both sides agree on a starting point for sequence numbers before any real data flows. Each side picks its own random Initial Sequence Number (ISN) and communicates it during the handshake, which both establishes a shared reference point for tracking exactly which bytes have been sent and received, and — because the ISN is randomized rather than predictable — makes it much harder for an attacker to inject forged packets into an existing connection by guessing what sequence number would be accepted. A capture missing this handshake at the start of a conversation (jumping straight into data) usually means the capture started partway through an already-established connection, not that the connection itself skipped the handshake.

Reading TCP sequence and acknowledgment numbers

Sequence and acknowledgment numbers track bytes, not packets, which is why they don't simply increment by one for each packet in a capture. A packet's sequence number represents the byte offset of the first byte of data it carries relative to the connection's starting ISN, so a packet carrying 1,460 bytes of payload causes the next packet's sequence number to jump by 1,460, not by 1. The acknowledgment number in the other direction indicates the next byte the receiver expects, which is why an ACK number stalling at the same value across multiple packets — rather than advancing — is a classic sign of a stuck or dropped packet, since the receiver is repeatedly confirming it's still waiting for the same byte.

Why FIN and RST endings mean very different things

How a TCP conversation ends carries real diagnostic meaning. A FIN-based close is a graceful, cooperative shutdown — each side sends a FIN when it has no more data to send, the other acknowledges it, and the connection winds down cleanly with both sides in agreement that it's finished. An RST (reset) is abrupt and one-sided: it signals that one side is immediately abandoning the connection, often because it received data for a connection it doesn't recognize, encountered an error, or a service on that port isn't actually listening. Seeing RST packets where you'd expect a normal FIN close is frequently a genuinely useful diagnostic signal — a service crash, a firewall actively blocking the connection, or an application-level error — rather than a routine, expected end to the conversation.

The .pcap vs .pcapng distinction, and why it matters here

Modern Wireshark defaults to the newer .pcapng format, which extends the older format with support for multiple network interfaces in a single file, richer per-packet metadata (comments, name resolution information), and a more flexible block-based structure overall. Classic .pcap, despite being older and less feature-rich, has a comparatively simple, fixed structure that's straightforward to parse reliably in a browser without needing to handle pcapng's more complex, extensible block types — which is exactly why this tool currently supports .pcap specifically. Exporting a capture as classic .pcap from Wireshark (rather than saving in its newer default format) is a quick, one-step conversion that makes a capture compatible with tools like this one.

Limitations of this tool

This viewer parses classic .pcap files with Ethernet, IPv4, and TCP headers — it doesn't yet support the newer .pcapng format, doesn't decode non-TCP protocols (UDP, ICMP, and others appear in the packet list but without detailed protocol-specific parsing), and doesn't support live packet capture, since browsers have no access to your device's network interfaces — it only analyzes files you've already recorded elsewhere, typically with Wireshark or a similar tool. Everything runs in your browser's memory, so very large captures (hundreds of megabytes) can be slow to process; this tool works best for the kind of focused, targeted capture you'd take specifically to debug one connection, not for analyzing a full day's worth of network traffic.