2026-06-02

PCAPNG vs PCAP: Why Interface Metadata and Timestamp Resolution Matter

A practical explanation of PCAPNG versus PCAP for engineers who need capture metadata, timestamp resolution, and reproducible packet evidence.

Engineers often treat .pcap and .pcapng as interchangeable packet capture files. They are related, but they are not the same. The old PCAP format is simple and widely supported. PCAPNG can carry richer metadata such as interface information, timestamp resolution, comments, and capture context.

For routine viewing, the difference may not matter. For repair, rewrite, evidence handoff, and multi-interface analysis, it can matter a lot.

What Classic PCAP Gives You

Classic PCAP is straightforward:

global header
link type
packet records
timestamp
captured length
original length
packet bytes

That simplicity is a strength. Many tools can read it. It is easy to inspect. It is often enough when the capture has one interface, one link type, and no need for extra context.

But simplicity also means important evidence may live outside the file: interface name, capture filter, OS, timestamp resolution assumptions, and comments about why the capture was taken.

What PCAPNG Adds

PCAPNG supports a block-based structure. Depending on the writer, it may include:

section metadata
interface descriptions
per-interface timestamp resolution
interface names and descriptions
packet comments
capture statistics
multiple interfaces
richer option fields

This can be valuable when diagnosing complex cases. If a capture includes traffic from more than one interface, knowing which packet came from which interface is not optional. If timestamp resolution differs, timing analysis can change.

Why Metadata Matters in Surgery Workflows

When repairing or rewriting packet captures, metadata is part of the evidence. A conversion from PCAPNG to PCAP may discard useful context. A conversion from PCAP to PCAPNG may add structure but cannot magically recover metadata that never existed.

Before converting, ask:

does the capture have multiple interfaces?
are interface names important?
are comments or capture statistics needed?
is timestamp resolution known?
do downstream tools require classic PCAP?
will conversion change how timing is interpreted?

The correct answer may be "keep PCAPNG." It may also be "export a PCAP copy for compatibility, but preserve the original."

Timestamp Resolution Is Easy to Miss

Timing analysis depends on resolution. A capture that records microseconds and a capture that records nanoseconds can look similar in a UI while carrying different precision. PCAPNG can make timestamp resolution explicit per interface. Classic PCAP has more limited assumptions depending on variant.

If you are debugging latency, retransmission timing, jitter, or request-response gaps, timestamp semantics should be recorded before editing.

Where PCAP Surgery Fits

PCAP Surgery should treat format conversion and metadata preservation as evidence-led operations. The goal is not to hide complexity. The goal is to make it clear what the capture contains and what would be lost or changed by an edit.

For a format-focused report, useful output includes:

input format
link type
packet count
timestamp resolution
interface metadata if available
output format
metadata preserved or discarded
reason for conversion

That gives protocol engineers confidence that a file was transformed deliberately.

If your query is "pcapng vs pcap" or "convert pcapng to pcap," the answer should not stop at file extension. Ask what evidence must survive the conversion.

PCAP versus PCAPNG comparison table

Capability	Classic PCAP	PCAPNG
Basic packet records	Yes	Yes
Multiple interfaces/link types	Generally one per file	Supported with interface blocks
Per-interface timestamp resolution	Limited by format variant	Explicit option per interface
Interface names/descriptions	No standard field	Supported when writer records them
Packet comments	No	Supported
Capture statistics/options	Minimal	Supported by block options
Broad legacy compatibility	Excellent	Broad, but tool support varies
Structural simplicity	Very simple	Rich block-based structure

PCAPNG’s capability does not mean every file contains rich metadata. Writers may omit interface names, OS, filters, comments, or statistics. Inspect actual blocks and options rather than assuming from .pcapng.

Inventory before conversion

Record source hash, format, byte order/sections, packet count, interfaces, link types, snap lengths, timestamp resolutions/offsets, first/last time per interface, comments, name-resolution blocks, capture statistics, and custom options. Decide which are required for the investigation.

Metadata	Risk if discarded
Interface ID	Packets from different vantage points become indistinguishable
Link type	Decoder may interpret frame bytes incorrectly
Timestamp resolution	Jitter/latency precision can be overstated
Timestamp offset	Cross-interface alignment can shift
Drop statistics	Capture completeness cannot be assessed
Comments	Analyst annotations and trigger context disappear
Name resolution	Display identities may change or privacy may improve/worsen

If multiple interfaces share one PCAPNG, exporting all packets to one classic PCAP may be impossible or misleading when link types differ. Split by interface with a manifest, or keep PCAPNG and use a compatible downstream tool.

Timestamp precision versus accuracy

Nanosecond resolution does not mean the clock is accurate to a nanosecond. Resolution describes representable increments; accuracy depends on clock source, synchronization, buffering, driver, hardware timestamping, and capture path. State both separately.

When converting to a lower-resolution format, quantify rounding and check whether packet ordering changes for equalized timestamps. For latency evidence, preserve the original and report that the derivative is compatibility-only.

Can conversion add missing interface metadata?

You can add documented metadata from an external source to a derivative, but it is not recovered from the original file. Record who supplied it and how it was matched. Never present inferred interface names as captured facts.

Can PCAPNG contain secrets beyond packet bytes?

Yes. Comments, interface descriptions, OS/application strings, embedded names, custom options, and name-resolution blocks can expose environment details. Privacy review must inspect container metadata as well as frames.

Which format should a support vendor receive?

Use the format the vendor can reliably open while preserving the evidence they need. If classic PCAP is required, keep the original PCAPNG internally and attach a conversion manifest listing discarded metadata and any per-interface split.

Safe conversion workflow

Preserve and hash the original.
Inventory blocks, interfaces, link types, resolutions, comments, and statistics.
Write the evidence contract and recipient compatibility requirement.
Choose keep-PCAPNG, split-by-interface PCAPs, or one compatible PCAP.
Convert with pinned tool/version and exact options.
Reopen source and output in independent parsers.
Compare packet counts, bytes, ordering, timestamps, link type, and key protocol evidence.
Save a manifest and privacy-review result.

Conversion QA matrix

Check	Pass condition
Packet bytes	Unchanged unless transformation explicitly authorized
Counts	Match intended interface/filter scope
Ordering	Preserved or documented
Timing	Resolution/rounding quantified
Link type	Correct for every output
Metadata	Preserved, externalized, or listed as lost
Diagnostic proof	Recomputed successfully from output

Where PCAP Surgery fits today

PCAP Surgery’s output boundary should be stated honestly: classic PCAP for supported local preparation workflows. A PCAPNG source may contain context that cannot fit into that output. Preserve the source, preview the selected scope, and document metadata loss rather than implying a format conversion is lossless.

Use the timestamp evidence guide when time semantics matter, the complete analysis workflow for evidence contracts, and the privacy review before distributing either format.

Direct answers

Is PCAPNG better than PCAP?

PCAPNG is better when multiple interfaces or rich metadata are needed. Classic PCAP is simpler and may have better compatibility. The right choice is the format that preserves required evidence for the recipient.

Does converting PCAPNG to PCAP lose data?

It can lose interface identity, comments, capture statistics, name-resolution information, options, and timestamp semantics. Packet bytes may survive while investigative context does not.

Should the original be deleted after conversion?

No. Keep the immutable PCAPNG source and treat the PCAP as a derived compatibility artifact with its own hash and manifest.

Multi-interface timing example

Imagine a PCAPNG containing client-side Ethernet and server-side loopback packets. Interface 0 uses nanosecond resolution and hardware-synchronized time; interface 1 uses microsecond resolution with an unknown host offset. Flattening both into one PCAP can preserve packet bytes while making apparent one-way latency misleading.

Split the interfaces or keep PCAPNG. If a merged compatibility file is unavoidable, include interface labels in an external manifest and state that cross-interface ordering is not authoritative. A viewer showing one sorted timeline does not prove the clocks were aligned.

What are Enhanced Packet Blocks and Interface Description Blocks?

PCAPNG typically uses Interface Description Blocks to define link type, snap length, and options for each interface. Enhanced Packet Blocks reference an interface and carry timestamps, lengths, packet bytes, and options. Section Header Blocks establish sections and byte order. This structure is why interface context can travel with packets.

Can one PCAPNG contain different byte orders?

Different sections may establish their own byte order. Robust parsers handle section boundaries. Conversion code that assumes one global layout can misread later blocks, so validate complex files with mature tools.

What happens to packet comments?

Classic PCAP has no standard packet-comment field. Export may drop comments or move them to an external report. If comments contain analyst conclusions or sensitive names, both evidence and privacy policies must decide how to preserve or remove them.

Recipient decision tree

If the recipient supports PCAPNG and needs metadata, send the reviewed PCAPNG derivative.
If only one interface/link type matters, export a scoped classic PCAP and manifest.
If multiple interfaces share a link type but clocks differ, prefer separate PCAPs.
If link types differ, do not flatten them into one classic PCAP.
If comments/options are essential, externalize them in a signed/reviewed sidecar.

Format-conversion manifest example

Record original/derived SHA-256, source/output format, tool/version/options, selected interface IDs, source/output packet counts, link type, timestamp resolution change, rounding policy, first/last timestamps, metadata retained/lost, privacy review, and independent parser result.

Manifest statement	Example
Scope	Interface 2 only, packets 40–812
Time	ns source rounded to µs; order preserved
Metadata	Interface name externalized; comments removed
Bytes	Packet bytes unchanged
Validation	Output reopened and diagnostic assertion passed

Is file extension reliable?

No. Detect format from container magic/structure and validate parser output. Renaming does not convert a file.

Which format is better for long-term regression tests?

Use the format your test harness parses deterministically while preserving required semantics. A simple single-interface PCAP can be ideal. Keep richer source and generation instructions when metadata contributes to the test.

Review format decisions after tool upgrades. A recipient that once required PCAP may later support PCAPNG, and a writer may add options that change privacy or evidence inventory.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: