TXT · Text & Data tools

PCAP Viewer

Capture file
Drop a .pcap or .pcapng file hereEthernet, Linux cooked, raw IP and loopback captures, up to 200 MB.

Shareable link

Settings are written to the URL as you change them. Nothing differs from the defaults yet.

Open a packet capture and read it the way Wireshark shows it: a packet list, a decoded detail tree for the selected frame, the raw bytes, and a filter bar that narrows the list to one host, one port or one conversation. Capture files from tcpdump, Wireshark, tshark, dumpcap and most routers open directly.

pcap and pcapng

The classic libpcap format is a 24-byte header followed by records, each with a timestamp, captured length and original length. The header’s magic number tells the reader the byte order and whether timestamps carry microseconds or nanoseconds, and the parser honours all four combinations. One link type applies to the whole file.

pcapng is a block format. A Section Header Block sets the byte order, Interface Description Blocks declare each capture interface with its own link type and timestamp resolution, and Enhanced Packet Blocks refer back to an interface by index. A capture taken on eth0 and any at once therefore lands as Ethernet frames and Linux cooked frames in one file, and each is decoded by its own interface. Simple Packet Blocks, which carry no timestamp, show a time of zero.

The packet list

Each row is one frame: the packet number, the time since the first packet in seconds to six decimals (or the absolute wall-clock time with the toggle), source and destination, the highest protocol recognised, the length on the wire and a one-line summary. For TCP the summary carries the flags, sequence and acknowledgement numbers, window and payload length; for DNS the transaction id, the question and the first answers; for TLS the handshake type and the server name; for HTTP the request or status line.

Addresses come from the highest layer that has them. An ARP frame shows MAC addresses, an IPv4 or IPv6 packet shows IP addresses. IPv6 addresses are shortened per RFC 5952, so 2001:0db8:0000:0000:0000:0000:0000:0002 reads 2001:db8::2.

Click a row to decode it, or move with the arrow keys once the list has focus. The list pages at 500 rows; filtering applies to the whole capture, not the current page.

Decoded layers

The detail pane lists every layer the dissector recognised, outermost first, each one collapsible.

  • Frame: capture time, captured and wire lengths, link type and the protocol chain.
  • Ethernet II: addresses and EtherType. A tagged frame adds an 802.1Q layer with priority and VLAN id, and double tagging (QinQ) is followed.
  • ARP: hardware and protocol types, opcode, and the sender and target pairs.
  • IPv4: header length, DSCP, identification, DF and MF flags, fragment offset, TTL, protocol, checksum, and any options as hex. A non-first fragment stops here, since its payload has no transport header.
  • IPv6: traffic class, flow label, hop limit and the chain of extension headers that was skipped to reach the transport protocol.
  • TCP: ports, raw sequence and acknowledgement numbers, flags, window, and the MSS, window scale, SACK and timestamp options from the SYN.
  • UDP: ports, length and checksum.
  • ICMP and ICMPv6: type and code by name, identifier and sequence for echo, the target address for neighbour discovery.
  • DNS: flags, response code, every question and every answer, authority and additional record with its type, TTL and decoded data for A, AAAA, CNAME, NS, PTR, MX, TXT, SRV and SOA.
  • HTTP/1.x: the request or status line and each header, when a TCP payload begins with a method or HTTP/.
  • TLS: each record in the segment with its content type, version and length. A Client Hello adds the offered versions, cipher suite count, server name, ALPN protocols, supported groups and the JA3 string with its MD5 hash. A Server Hello adds the negotiated version and cipher suite.

The hex pane beside it is the standard dump: offset, 16 bytes in two groups of 8, and the printable ASCII.

Display filters

The filter bar reads a subset of Wireshark’s language, so filters copied from a Wireshark session usually work unchanged.

A protocol name on its own keeps packets that carry that protocol: dns, tls, arp, icmpv6. A field with a comparison keeps packets where any value of the field matches, so ip.addr == 10.0.0.1 matches source or destination and tcp.port == 443 matches either port. ip.addr == 192.168.0.0/16 matches a range. Numbers accept decimal or 0x hex, strings may be quoted, and contains and matches (a regular expression) are case-insensitive.

tcp.port == 443 && tls.sni contains "cdn"
dns.qry.name contains example && !dns.flags.response == 1
(http || tls) && ip.src == 10.0.0.2
tcp.flags.syn == 1 && tcp.flags.ack == 0
frame.len > 1400
tls.ja3_hash == 579ccef312d18482fc42e2b822ca2430

Available fields: frame.number, frame.len, eth.src, eth.dst, eth.addr, vlan.id, arp.opcode, ip.src, ip.dst, ip.addr, ip.proto, ip.ttl, ipv6.src, ipv6.dst, ipv6.addr, tcp.srcport, tcp.dstport, tcp.port, tcp.seq, tcp.ack, tcp.len, tcp.flags, tcp.flags.syn and the other eight flags, tcp.stream, udp.srcport, udp.dstport, udp.port, udp.stream, icmp.type, icmp.code, icmpv6.type, dns.id, dns.qry.name, dns.qry.type, dns.resp.addr, dns.rcode, dns.flags.response, http.host, http.request.method, http.request.uri, http.response.code, http.user_agent, tls.sni, tls.alpn, tls.handshake.type, tls.handshake.version, tls.ja3, tls.ja3_hash. ip.addr also matches IPv6 packets, so one filter covers a dual-stack host.

A syntax error is reported under the bar with the token it stopped on, and the list keeps the last valid filter.

Follow stream

Select any TCP or UDP packet and press Follow stream. The filter becomes tcp.stream == N (streams are numbered in order of first appearance, separately for TCP and UDP), the list shows only that conversation, and a pane prints every payload in order. Each segment is prefixed with its direction, → from the side that sent the first bytes and ← back, and its packet number, so a request and its response can be read top to bottom. Non-printable bytes render as dots. The pane stops after 256 KB.

This is concatenation, not reassembly: retransmitted or out-of-order segments appear where they were captured.

Export

Export filtered as CSV writes the visible columns of every packet that passes the current filter, for a spreadsheet or a ticket.

Limits

  • Files up to 200 MB. Parsing runs in a background thread and the list pages, but the whole file is held in memory.
  • No TLS decryption, so anything after the handshake is Application Data.
  • No TCP reassembly: a TLS record or HTTP header split across segments is shown as far as the first segment goes and marked as continuing.
  • No dissectors for 802.11 radiotap, PPP, GRE payloads, SCTP, QUIC or the long tail of application protocols. Those frames appear in the list with their link or IP protocol name and the raw bytes.
  • No expert information, conversation statistics or graphs.

Example

A capture of one curl https://example.com from a laptop reads as: two DNS packets (A example.com and the response with its address), a TCP three-way handshake with the SYN carrying MSS 1460 and a window scale of 7, a TLS Client Hello with SNI=example.com and ALPN h2, http/1.1, a Server Hello negotiating TLS 1.3, then Application Data records, then FIN. Filtering on tls.sni contains example leaves the one Client Hello; Follow stream on it shows the whole connection in order.

Frequently Asked Questions

Classic libpcap files (.pcap, .cap) in little- or big-endian byte order with microsecond or nanosecond timestamps, and pcapng files with any number of interfaces and sections. Frames must use the Ethernet, Linux cooked (SLL and SLL2), raw IP, or BSD loopback link type. 802.11 radiotap, PPP and USB captures are listed as packets but not dissected.

Ethernet II with 802.1Q VLAN tags, ARP, IPv4 with options and fragment flags, IPv6 with hop-by-hop, routing, fragment, destination-option and AH extension headers, ICMP, ICMPv6, TCP with MSS, window scale, SACK and timestamp options, UDP, DNS and mDNS with compression pointers, HTTP/1.x request and status lines plus headers, and TLS records including Client Hello server name, ALPN, supported versions and a JA3 fingerprint, and the Server Hello cipher.

A subset of Wireshark display filters. Protocol names (tcp, udp, dns, http, tls, arp, icmp, icmpv6, vlan) test presence. Fields such as ip.addr, ip.src, ip.dst, ipv6.addr, tcp.port, udp.port, tcp.flags.syn, tcp.stream, frame.len, dns.qry.name, tls.sni, tls.ja3_hash, http.host and http.request.method take ==, !=, <, >, <=, >=, contains and matches. Combine with &&, ||, ! and parentheses. ip.addr == 10.0.0.0/24 matches a CIDR range.

Files up to 200 MB load. The whole capture is parsed in a background thread with a progress bar, then paged 500 packets at a time, so a capture of a few hundred thousand packets stays usable. Larger files should be split first, for example with editcap.

Select a TCP or UDP packet and press Follow stream. The list narrows to that conversation and a pane shows every payload in capture order, each segment marked with its direction and packet number. Bytes outside printable ASCII render as dots, and the pane stops after 256 KB of payload.

It covers the protocols most captures are made of and reads the same files, but it is a reader, not a replacement. There is no TCP reassembly across segments beyond concatenating payloads, no TLS decryption, no expert analysis, no IO graphs, and no dissectors for the long tail of protocols Wireshark ships.

JA3 is a fingerprint of a TLS Client Hello built from the version, cipher suites, extensions, elliptic curves and point formats the client offers, hashed with MD5. The same client software tends to produce the same hash across connections, which is why it is used to recognise clients in captures without decrypting anything.

Explore Our Tools

Browse all tools