CAP File Documentation

Summary

A .cap file is almost always a network packet capture: a recorded trace of network traffic saved by a sniffer such as Wireshark, tcpdump or Microsoft Network Monitor. Each record holds a timestamp plus the raw bytes of one captured frame. Most .cap files use the classic libpcap format (magic D4 C3 B2 A1), which Wireshark opens on Windows, macOS and Linux. Its MIME type is application/vnd.tcpdump.pcap. Identify one by its header bytes, not its extension.

Technical details

FeatureValue
Full namePacket Capture file (network trace)
File extension.cap
MIME typeapplication/vnd.tcpdump.pcap
Format typeBinary network packet capture
Common on-disk formatlibpcap (classic pcap); also NetMon and Sniffer variants
Developerlibpcap/tcpdump group; Microsoft (NetMon); NAI/NetScout (Sniffer)
Introducedlibpcap/tcpdump format, early 1990s
Open standardPartial — pcap documented in an IETF draft
Byte orderEither — the magic number encodes which
Magic number (little-endian)D4 C3 B2 A1
Magic number (big-endian)A1 B2 C3 D4
pcapng magic0A 0D 0D 0A (newer, block-based variant)
Global header length24 bytes
Per-packet record header16 bytes (timestamp + captured/original length)
Current pcap version2.4 (major 2, minor 4)
Primary toolWireshark (auto-detects the variant)
Related extensions.pcap, .pcapng, .etl, .snoop
Specificationdatatracker.ietf.org/doc/html/draft-gharris-opsawg-pcap
File signature (magic bytes)
D4 C3 B2 A1

Offset 0, 4 bytes — the classic libpcap magic number. It doubles as a byte-order flag: a reader that sees D4 C3 B2 A1 knows the writer used the opposite endianness, while A1 B2 C3 D4 means the same endianness, so the magic tells the parser how to read every multi-byte field that follows. The newer block-based pcapng variant instead begins 0A 0D 0D 0A. A .cap may also be a Microsoft Network Monitor or NAI Sniffer capture with a different header; Wireshark identifies the variant from these bytes, not from the .cap extension.

What is a CAP file?

A .cap file is a packet capture: a recorded trace of network traffic, saved off a network by a packet sniffer so it can be analysed later or on another machine. Each entry in the file is one captured frame — an Ethernet, IP, TCP or UDP packet — stored with a timestamp and the raw bytes as they went over the wire. Captures like this are the core artefact of network troubleshooting, protocol analysis, security investigation and Wi-Fi auditing. The tools that write them include tcpdump and Wireshark (libpcap format), Microsoft’s Network Monitor, and the legacy NAI/NetScout Sniffer.

The .cap extension is genuinely ambiguous: a handful of unrelated programs (some games, the Capella music editor, certain printer utilities) also use it. But when a file called .cap comes from networking work, it is one of a few closely related capture formats, and the dominant one is libpcap. The rest of this article describes the libpcap layout in detail, since that is what most .cap files really are, and explains how to tell the variants apart from their bytes.

The libpcap global header, field by field

A classic pcap file is a single 24-byte global header followed by a sequence of packet records. The global header describes the whole capture and, crucially, tells the reader how to interpret every field after it. Its layout is:

offset  size  field            meaning
  0      4    magic_number     D4 C3 B2 A1  (byte-order + timestamp precision)
  4      2    version_major    2
  6      2    version_minor    4
  8      4    thiszone         GMT-to-local offset (almost always 0)
 12      4    sigfigs          timestamp accuracy (in practice 0)
 16      4    snaplen          max bytes captured per packet
 20      4    network          link-layer type (LINKTYPE_*)

The magic_number is doing more than identifying the file. Because it is a known 32-bit constant, its byte order reveals the writer’s endianness: a reader that sees A1 B2 C3 D4 reads the file in its own byte order, while D4 C3 B2 A1 (the bytes swapped) tells it to byte-swap every integer field. A variant magic 4D 3C B2 A1 signals that packet timestamps are in nanoseconds rather than microseconds. The version_major/version_minor pair has been 2.4 for decades. The snaplen is the snapshot length: the maximum number of bytes the capturing tool kept from each packet (capturing only the first 96 or 128 bytes is common when only headers are needed). The network field is the link-layer type — for example the constant for Ethernet, or for 802.11 Wi-Fi — and it tells the parser how to decode the very first bytes of every packet’s data.

Per-packet records: header plus captured bytes

After the global header, the file is just a run of packet records, each a 16-byte record header immediately followed by that packet’s bytes:

offset  size  field         meaning
  0      4    ts_sec        timestamp, seconds since the Unix epoch
  4      4    ts_usec       microseconds (or nanoseconds) within the second
  8      4    incl_len      number of packet bytes actually stored here
 12      4    orig_len      original length of the packet on the wire
 16    incl_len  data       the captured frame bytes

The two length fields matter and differ. orig_len is how large the packet really was on the network; incl_len is how much of it was saved, and it can be smaller when snaplen truncated the packet. A reader walks the file by reading a 16-byte header, then reading exactly incl_len bytes of data, then repeating — there is no index and no per-packet magic, so the file is strictly sequential. The timestamp’s sub-second field is microseconds by default, or nanoseconds if the global magic said so. The captured data is the raw frame; how to decode its first bytes comes from the global header’s network link-layer type, and from there a dissector peels off each protocol layer (Ethernet then IP then TCP, and so on).

pcap, pcapng, NetMon and Sniffer variants

Several on-disk formats share the .cap extension, and they are distinguished by their opening bytes. Classic libpcap is the flat header-plus-records format above. pcapng (pcap Next Generation) is a newer, block-structured format that begins with a Section Header Block whose magic is 0A 0D 0D 0A; it can hold multiple interfaces, richer metadata and comments, and it is what modern Wireshark writes by default (usually as .pcapng, but sometimes saved as .cap). Microsoft Network Monitor and the legacy NAI/NetScout Sniffer each use their own container headers.

First 4 bytesFormat
A1 B2 C3 D4 / D4 C3 B2 A1Classic libpcap (same / swapped byte order)
4D 3C B2 A1libpcap with nanosecond timestamps
0A 0D 0D 0Apcapng (block-based)
Other vendor headerNetMon / Sniffer capture

The practical upshot is that you should never trust the extension to tell you the format. Wireshark auto-detects all of these from the header and decodes them the same way, which is why it opens a .cap regardless of which tool produced it. If Wireshark refuses a .cap, that is a strong sign the file is not a network capture at all but one of the unrelated .cap formats.

CAP versus PCAP: usually the same bytes

People often ask how .cap and .pcap differ. Usually they do not: both commonly contain the identical libpcap format, and the only difference is which extension the capturing tool chose to write. In many cases you can rename a .cap to .pcap and every tool treats it the same. Where a .cap is actually a NetMon or Sniffer capture, opening it in Wireshark and choosing Save As “Wireshark/tcpdump pcap” normalises it to standard pcap. The extension is a label; the header is the truth.

Why a CAP file is sensitive, not executable

A .cap is passive data: it is a record of bytes, not a program, so opening one cannot execute code. The real concern is confidentiality. A capture contains whatever traffic was on the wire, which can include clear-text passwords, session cookies, authentication tokens, internal IP addresses and hostnames. Anyone who reads the file reads that traffic. Treat captures as confidential, and do not upload a sensitive one to a public online analyser, because that hands the raw traffic to a third party. Two further cautions follow from the format’s ambiguity: verify a file’s magic bytes before trusting its extension, since a file that is .cap by name could be a different format or a disguised executable, and remember that a WPA-handshake capture is intended for password cracking, so handle it accordingly.

References