PCAPNG File Documentation

Summary

A PCAP Next Generation file (.pcapng) is a recording of network traffic — a “packet capture” saved by a network analyzer such as Wireshark, tcpdump or dumpcap. It is the modern, default capture format and the successor to the older .pcap, storing the raw packets plus metadata like interface details and nanosecond timestamps in a block structure. Open it with Wireshark (free, on Windows, macOS and Linux). Its MIME type is application/x-pcapng. It is not a document: you analyze it packet by packet to troubleshoot networks or investigate security events.

Technical details

FeatureValue
Full namePCAP Next Generation Capture File
File extension.pcapng
MIME typeapplication/x-pcapng
Format typeBinary network packet capture, block-structured
DeveloperWireshark-led; IETF OPSAWG community specification
Introducedcirca 2010; Wireshark default from v1.8 (2012)
SpecificationIETF OPSAWG pcapng Internet-Draft
Open standardYes
Byte orderEither — declared per section by the Byte-Order Magic
Magic number0A 0D 0D 0A (Section Header Block type) at offset 0
Byte-Order Magic1A 2B 3C 4D at offset 8 (byte-swapped if big-endian)
StructureSequence of typed blocks (SHB, IDB, EPB, NRB, ISB)
Timestamp resolutionConfigurable, down to nanoseconds (via IDB option)
Multiple interfacesYes — several capture interfaces in one file
Per-packet commentsYes (block options)
PredecessorClassic pcap (.pcap / .cap), magic D4 C3 B2 A1
Opens inWireshark, tshark, tcpdump, NetworkMiner, CapLoader
Related extensions.pcap, .cap, .etl, .snoop
File signature (magic bytes)
0A 0D 0D 0A … 1A 2B 3C 4D

A pcapng file begins with a Section Header Block. The first 4 bytes are the block type 0A 0D 0D 0A (this is also the pcapng magic number). The 32-bit block total length follows, and a Byte-Order Magic value of 1A 2B 3C 4D appears at offset 8. That magic reads 1A 2B 3C 4D in a big-endian file and byte-swapped as 4D 3C 2B 1A in a little-endian file, so a reader checks it before trusting any length field. This distinguishes pcapng from the older classic pcap format, whose magic is D4 C3 B2 A1 (or A1 B2 C3 D4) at offset 0. Wireshark auto-detects both.

What is a PCAPNG file?

A .pcapng file is a saved recording of network traffic: a “packet capture” that stores the frames a network analyzer observed crossing a wire or interface, together with metadata about where and when they were captured. PCAP Next Generation is the block-structured format that replaced the classic libpcap (.pcap) format. Wireshark adopted it as its default save format with version 1.8 in 2012, so most captures written by modern Wireshark are pcapng even when the file happens to be named .pcap. It is an open, community-maintained specification (an IETF OPSAWG Internet-Draft) rather than a proprietary format, which is why it is so widely supported.

The file is not human-readable and holds no text or images to view directly. What it contains is the raw bytes of captured frames plus the timing and interface information needed to interpret them; you analyze it in a tool that decodes each protocol layer. Everything below is about how pcapng arranges those bytes into blocks.

The block model: everything is a typed block

A pcapng file is a flat sequence of blocks, and every block shares the same envelope. Because each block declares its own length, a reader can skip a block type it does not recognise and keep going, which is what makes the format extensible without breaking older tools.

Generic block
  +0   Block Type          uint32
  +4   Block Total Length  uint32   (length INCLUDING both length fields)
  +8   Block Body          variable
  ...  Block Total Length  uint32   (repeated at the end)

The trailing copy of the Block Total Length is deliberate: it lets a reader walk the file backwards as well as forwards, and it is a consistency check — the value at the end must equal the value at the start. All blocks are padded to a multiple of 4 bytes. The block body can carry options, a list of type-length-value entries terminated by an opt_endofopt (code 0) entry, which is how per-packet comments, interface names and timestamp settings are attached.

The five block types you meet

BlockRole
Section Header Block (SHB)Starts a section: magic, byte order, version, optional metadata
Interface Description Block (IDB)Describes one capture interface: link type, snap length, timestamp resolution
Enhanced Packet Block (EPB)One captured frame: interface id, timestamp, lengths, raw packet bytes
Name Resolution Block (NRB)Optional address-to-name mappings recorded with the capture
Interface Statistics Block (ISB)Optional per-interface counters (packets received, dropped)

The Section Header Block and byte order

Every pcapng file opens with a Section Header Block, and its first four bytes, 0A 0D 0D 0A, double as the format’s magic number. That value is not accidental: it contains a carriage return and a line feed, so common file-transfer corruption that rewrites line endings visibly damages the magic and flags a broken file. Immediately notable is the Byte-Order Magic at offset 8, the constant 0x1A2B3C4D. A reader must inspect this field before interpreting any length, because pcapng does not fix an endianness: if the four bytes read 1A 2B 3C 4D the section is big-endian, and if they read 4D 3C 2B 1A it is little-endian. The SHB also carries the major/minor version and a section length, and can hold options such as the operating system and the capturing application.

A file can contain more than one section, each introduced by its own SHB with potentially its own byte order — useful when captures are concatenated. This is why the specification talks about “the current section”: interface definitions and packet blocks belong to the SHB that precedes them.

After the SHB come one or more Interface Description Blocks, one per capture interface. Each IDB records the LinkType (the link-layer encapsulation, for example Ethernet or 802.11), a SnapLen giving the maximum number of bytes captured per packet (a capture may keep only the first N bytes of each frame), and options that configure the interface. The most important option is if_tsresol, the timestamp resolution: pcapng timestamps are 64-bit integer counts of time units since the epoch, and this option sets how large a unit is. That is how the format supports nanosecond (or finer) precision where the older pcap format was limited to microseconds. Because IDBs are numbered in order, each packet later refers to its interface by a small integer index into this list — the mechanism that lets one file hold packets from several interfaces at once.

Enhanced Packet Blocks: where the packets live

The actual captured frames are stored in Enhanced Packet Blocks, the workhorse of the format. Each EPB carries the packet plus the context needed to place and measure it:

Enhanced Packet Block body
  Interface ID        uint32   which IDB this packet came from
  Timestamp (High)    uint32   upper 32 bits of the 64-bit timestamp
  Timestamp (Low)     uint32   lower 32 bits (unit set by if_tsresol)
  Captured Length     uint32   bytes actually stored (<= SnapLen)
  Original Length     uint32   real length of the frame on the wire
  Packet Data         variable padded to 32 bits
  Options             variable e.g. a per-packet comment

The two length fields matter: Captured Length is how many bytes are present in the file, while Original Length is how long the frame really was on the wire. When a capture was snapped short, Original Length exceeds Captured Length, so an analyst knows the frame was truncated rather than genuinely tiny. The 64-bit timestamp is split into high and low halves and interpreted using the resolution declared in the packet’s IDB. An EPB can also carry option comments, which is how Wireshark lets you annotate an individual packet — something classic pcap cannot store.

PCAPNG versus classic PCAP

The older pcap format is a single global header followed by a flat list of packet records — one interface, microsecond timestamps, no comments, no sections. Pcapng’s block model adds four capabilities that the block structure makes possible: multiple interfaces in one file (via numbered IDBs), nanosecond timestamps (via if_tsresol), per-packet and per-interface metadata (via options), and forward extensibility (unknown blocks are skipped by length). Wireshark reads both, and many tools that ask for “a pcap” actually accept pcapng too.

When a tool genuinely requires classic pcap, convert with editcap -F pcap in.pcapng out.pcap or Wireshark’s Save As. That conversion is lossy: features pcap cannot represent — extra interfaces, sub-microsecond timestamps, comments — are flattened or dropped. To read a capture on the command line, tshark -r file.pcapng and tcpdump -r file.pcapng both work (modern libpcap reads pcapng), and tshark can export the dissected packets to text, CSV or JSON for scripting.

References