Packet Capture Size Calculator
Estimate packet capture storage from traffic rate and duration with snapshot limits, file overhead, compression and capacity reserve checks.| Measure | Value | Planning meaning | Copy |
|---|---|---|---|
| {{ row.label }} | {{ row.value }} | {{ row.note }} |
| Check | Finding | Next action | Copy |
|---|---|---|---|
| {{ row.label }} | {{ row.finding }} | {{ row.action }} |
| Duration | Base capture | Required storage | Saved packets | Copy |
|---|---|---|---|---|
| {{ row.duration }} | {{ row.base }} | {{ row.required }} | {{ row.packets }} |
Introduction:
A packet capture has to keep up with traffic while writing a bounded amount of evidence to storage. Link speed alone gives a worst-case ceiling, not a realistic file size. Average utilization narrows the traffic rate, a capture filter determines what share is retained, and snapshot length limits how many bytes are saved from each matching packet.
Packet size matters twice. Dividing average traffic by average packet size estimates packets per second, while the saved bytes per packet determine payload storage. Many small packets create more records and therefore more container overhead than the same traffic volume carried in larger packets. A short snapshot can reduce data per packet, but it may remove transport fields, application payload, or bytes needed for stream reassembly.
| Decision | Storage effect | Evidence risk |
|---|---|---|
| Narrower capture filter | Reduces retained traffic share | May exclude a related flow |
| Shorter snapshot length | Saves fewer bytes per packet | Can truncate payload or later protocol decoding |
| Longer duration | Raises size almost linearly | Increases exposure and review burden |
| Compression | Reduces stored bytes when data compresses | Assumed ratios can be optimistic |
| Reserve | Adds headroom after compression | Does not prevent capture drops |
Capture format adds its own structure. Classic pcap has a file header and a fixed header for every packet. A minimal pcapng Enhanced Packet Block carries a larger per-packet record and pads packet data to a four-byte boundary. Real pcapng files may add interface descriptions, options, statistics, name resolution, or other blocks beyond this planning model.
Enough disk space does not guarantee a complete capture. CPU pressure, kernel buffers, filter width, write throughput, storage latency, and burst traffic can still cause drops. Packet files can also contain credentials, cookies, tokens, private addresses, and payload data. Keep the interface, filter, snapshot, duration, access permissions, and retention as narrow as the investigation allows.
How to Use This Tool:
Base the estimate on representative traffic statistics and the exact capture policy planned for the run.
- Enter Link rate, Average utilization, and Capture duration. Changing a unit preserves the same physical rate or duration.
- Set Retained traffic share to 100% for all observed traffic or to a measured estimate for the intended filter.
- Enter a representative Average packet size and the Snapshot length. Use a full-packet snapshot when later analysis needs payload or stream reconstruction.
- Choose classic pcap, minimal pcapng Enhanced Packet Blocks, or packet data only. Treat packet data only as a comparison floor rather than a normal capture container.
- Open Advanced to add storage reserve, a measured compression ratio, optional captured FCS bytes, and available capacity.
- Compare Required storage with Available storage, then make sure the estimated Write rate and capture plan fit the host. Check actual drop counters during the run.
Interpreting Results:
Base capture includes captured packet bytes and the selected format's modeled headers and padding. Required storage divides that base by the compression ratio and then adds reserve. Compression ratio 1:1 means no reduction.
- Fits includes exact equality: required storage is less than or equal to available storage.
- Shortfall means required storage is greater than available storage; the negative margin is the missing capacity.
- No target means available storage is zero and no capacity comparison was requested.
- Truncation reports the share of modeled packet bytes removed by snapshot length. Zero truncation does not prove every real packet was captured in full.
- Write rate is the modeled uncompressed container bit rate, useful for checking sustained disk throughput before reserve or archival compression.
Technical Details:
Network rate uses decimal bit-rate units: Kbps, Mbps, Gbps, and Tbps are powers of 1,000. Storage uses binary units: MiB through PiB are powers of 1,024 bytes. Eight bits are converted to one byte before packet counts and file bytes are assembled.
Formula Core:
The model estimates saved packet count from traffic rate and average packet size, then adds captured bytes, per-record overhead, optional pcapng padding, compression, and reserve.
| Symbol | Meaning | Unit |
|---|---|---|
| R | Normalized link rate | bits per second |
| u | Average utilization | percent |
| a | Average packet size | bytes |
| s | Retained traffic share | percent |
| t | Capture duration | seconds |
| f | Captured FCS allowance | bytes per packet |
| l | Snapshot length | bytes per packet |
| g | pcapng alignment padding | bytes per packet |
| z | Compression ratio | ratio |
| v | Storage reserve | percent |
Rule Core:
| Format | File header | Per packet | Padding rule |
|---|---|---|---|
| Classic pcap | 24 bytes | 16 bytes | None added by this model |
| pcapng Enhanced Packet Block | 48 bytes | 32 bytes | Packet data padded to a four-byte boundary |
| Packet data only | 0 bytes | 0 bytes | None; comparison floor only |
Captured bytes per packet equal the smaller of average packet size plus the FCS allowance and snapshot length. For pcapng, padding is 0 through 3 bytes so packet data ends on a four-byte boundary. The 48-byte pcapng file allowance represents a minimal section and interface setup; options and extra blocks are deliberately omitted.
Inputs allow 0% utilization or retained traffic share as explicit zero-traffic boundaries. Snapshot length and average packet size must be whole numbers from 1 through 262,144 bytes. Compression ranges from 1:1 through 100:1, but only a measured ratio should be used for operational planning.
Capture Planning Limits:
The estimate describes file volume, not capture completeness or safe evidence handling.
- Validate the filter and snapshot length on a short run before starting a long capture.
- Monitor packets received, captured, and dropped; a nonzero kernel-drop count means the saved evidence is incomplete.
- Measure write throughput on the actual storage path and leave room for bursts, filesystem allocation, rotation, and indexes.
- Restrict access to capture files and remove them when their diagnostic or evidentiary purpose ends.
Worked Example:
Short filtered pcapng capture
A 100 Mbps link at 50% utilization, captured for one minute with a filter retaining 50% of traffic, averages 100-byte packets. With a 63-byte snapshot, four FCS bytes, minimal pcapng Enhanced Packet Blocks, 2:1 compression, and 10% reserve, the estimate saves 1,875,000 packets and requires 99,000,026.4 bytes, about 94.4 MiB. That fits inside 256 MiB, but the 39.4% truncation estimate means the snapshot must still preserve the fields needed for the investigation.
References:
- PCAP Capture File Format, IETF Datatracker, May 2026.
- PCAP Next Generation Capture File Format, IETF Datatracker, March 2026.
- dumpcap manual page, Wireshark.
- How to capture full packets with tcpdump, Simplified Guide.
- How to troubleshoot dropped packets in tcpdump, Simplified Guide.