Packet Capture Size Calculator

Link rate:

Enter the monitored link speed, then choose the rate unit.

Average utilization:

Use monitoring data when available; 35% on a 1 Gbps link means 350 Mbps average traffic.

Capture duration:

Set the planned capture window for incident, baseline, or retention sizing.

Captured traffic share:

Use 100% for full capture, lower values for sampled or heavily filtered captures.

Average packet size:

Use packet-length stats from a short sample; 750 bytes is a mixed-traffic planning value.

bytes

Snap length:

Use full-size values such as 1518 for Ethernet frames, or a smaller value for header-only captures.

bytes

Capture file format:

Choose classic PCAP for lean packet records or PCAPNG when metadata blocks are expected.

Storage reserve:

Reserve free space for capture bursts, filesystem overhead, indexing, and tool metadata.

Available storage:

Enter the capture partition, appliance quota, or object-storage budget to check fit.

Compression ratio:

Use measured archive results for your traffic; encrypted or already-compressed payloads may stay near 1:1.

Captured FCS bytes:

Most host captures omit FCS. Use 4 only when the capture source confirms FCS is stored.

bytes

Metric	Value	Detail	Copy
{{ row.metric }}	{{ row.value }}	{{ row.detail }}

Check	Status	Action	Reason	Copy
{{ row.check }}	{{ row.status }}	{{ row.action }}	{{ row.reason }}

Duration	Base capture	Required storage	Packets saved	Write rate	Copy
{{ row.durationDisplay }}	{{ row.baseCaptureDisplay }}	{{ row.requiredStorageDisplay }}	{{ row.packetsDisplay }}	{{ row.writeRateDisplay }}

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Packet captures can consume storage faster than the link speed suggests. A two-hour capture on a busy interface is not just a time window; it is a stream of packets, per-packet record headers, optional padding, snap length choices, and reserve space that must fit before the capture starts.

This packet capture size calculator estimates how much disk space a planned capture needs from link rate, average utilization, capture duration, retained traffic share, average packet size, snap length, file format, compression, and storage reserve. It also checks the modeled result against an available storage target so a short investigation does not turn into a dropped or truncated capture.

The most important inputs are the traffic rate that will actually be seen by the capture point and the number of bytes saved from each packet. Full-packet captures preserve more evidence, but they grow quickly. Header-only or sampled captures can be much smaller, yet they may remove the payload bytes or packet population needed for later analysis.

Packet capture storage flow from traffic rate and duration to retained packets, per-packet bytes, overhead, and required storage

Use the result as a planning estimate, not as a promise that a capture host will keep up with every burst. The storage number answers disk fit; the packet-rate and write-rate outputs help identify when CPU, driver buffering, or disk flush behavior also need attention.

Technical Details:

Capture sizing starts with traffic volume, then converts that volume into packet records. Link rate is expressed in bits per second, utilization reduces it to the average traffic rate, and captured traffic share reduces the saved packet population when filters, direction selection, or sampling are part of the plan.

Snap length changes the byte count written for each saved packet. If the configured snap length is below the average packet size plus any captured frame check sequence bytes, the model saves only the snap length value for each packet and flags the capture as truncating packets. If the snap length covers the average packet, the stored packet bytes match the modeled average.

Formula Core:

The formulas below show the storage path from traffic assumptions to the final disk requirement. Percent values are used as fractions, and compression is entered as a ratio such as 2:1.

\begin{matrix} R_{avg} & = & R_{link} \times u \\ P_{saved} & = & \frac{R_{avg}}{8 \times B_{avg}} \times s \times T \\ B_{packet} & = & \min (B_{avg} + B_{fcs}, B_{snap}) \\ B_{base} & = & B_{file} + P_{saved} \times (B_{packet} + B_{record} + B_{pad}) \\ B_{required} & = & \frac{B_{base}}{C} \times (1 + q) \end{matrix}

Format Overhead:

Capture format overhead used by the packet capture size calculator
Format option	Fixed file bytes	Per-packet bytes	Padding	Best fit
`Classic PCAP`	24	16	None in the modeled record.	Lean single-interface captures where extra metadata is not needed.
`PCAPNG EPB`	48	32	Captured packet data is padded to a 4-byte boundary.	Captures that may need richer metadata or multi-interface context.
`Packet data only`	0	0	None.	Rough byte-volume checks without capture-container overhead.

The PCAPNG option is intentionally a compact Enhanced Packet Block estimate. Real PCAPNG files can include section, interface, options, statistics, and name-resolution blocks, so use measured files when policy or tooling adds heavy metadata. For ordinary planning, the per-packet record cost usually matters much more than the fixed file allowance.

Status Rules:

How storage, packet-rate, snap length, and reserve statuses are assigned
Check	Rule used	Meaning
`Storage fit`	Shortfall below 0 bytes, tight margin below 15%, otherwise fits.	Shows whether the required storage fits the available target after reserve.
`Packet rate`	High at 50,000 pps, very high at 250,000 pps.	Warns when software capture and disk flushing deserve a separate performance check.
`Snap length`	Truncates when snap length is below average packet bytes plus captured FCS bytes.	Signals that payload or later reassembly evidence may be missing.
`Reserve`	20% or more is treated as healthy, 10% to 19% as caution, below 10% as weak.	Adds space for bursts, file-system overhead, indexes, and operational headroom.

Everyday Use & Decision Guide:

Start with the monitored interface speed only if that speed describes the traffic entering the capture point. A 10 Gbps port at 20% average utilization behaves like a 2 Gbps average traffic source for sizing, but short bursts can still require faster write storage than the average result.

Use Captured traffic share to account for filters, direction selection, sampling, or a narrow capture point. Keep it at 100% for a full capture. Lower it only when the capture rule or sampling policy really drops traffic before it is written, because this input directly reduces packet count and stored bytes.

Use a full-size Snap length when payload content, protocol reassembly, or forensic review may matter later.
Use a smaller snap length only when headers are enough and the retention goal is more important than payload evidence.
Choose Classic PCAP when you want a lean estimate for ordinary packet records.
Choose PCAPNG EPB when metadata or multi-interface context is likely to be part of the capture workflow.
Leave Compression ratio at 1:1 unless you have measured similar capture files. Encrypted or already-compressed payloads may not shrink much.
Keep reserve high for active incident work, because bursts, indexes, rotation files, and investigator exports can all consume space beyond the modeled file.

The Capture Budget table is the quickest read for a single plan: average traffic rate, retained traffic volume, packets saved, stored bytes per packet, base capture file, write rate, required storage, and an estimated count of 4 GiB rotation files. The Retention Checks table adds the operational warnings that usually matter before starting a long capture.

Open Capture Size Curve when the planned duration is flexible. The curve compares base capture and required storage across shorter and longer windows, making it easier to choose between a narrow incident capture, a longer baseline sample, or a reduced snap length.

Step-by-Step Guide:

Enter Link rate and select the matching unit. Use the monitored traffic ceiling, not a marketing speed, when you already have better data.
Set Average utilization and Capture duration. Both values scale the result directly, so replace defaults with observed traffic data when possible.
Set Captured traffic share for filters or sampling. If the validation warning appears, keep the value above 0% and no more than 100%.
Enter Average packet size, Snap length, and Capture file format. Use packet-length statistics from a short sample if you have them.
Add Storage reserve and Available storage to get a fit, tight-margin, or shortfall result.
Open Advanced only if compression or captured FCS bytes should change the estimate. Keep Captured FCS bytes at 0 unless the capture source confirms that those bytes are stored.
Review the headline required storage first, then use the budget, checks, curve, curve data, and JSON views for handoff or deeper inspection.

Interpreting Results:

Required storage is the final planning number after base capture size, compression, and reserve. Base capture file is still important because it drives average write rate and rotation count before any archive compression is applied.

How to read packet capture size outputs
If you see	Read it as	Check next
`Storage shortfall`	The modeled capture does not fit the available target after reserve.	Shorten duration, filter traffic, lower snap length only if evidence allows it, or add storage.
`Tight margin`	The plan fits, but less than 15% of the target remains.	Add space or reduce the capture window before running an unattended capture.
`Truncates packets`	The snap length omits part of the average packet.	Confirm that headers are enough, especially for application payload, TLS metadata, or reassembly work.
`High` or `Very high` packet rate	Packet count may stress capture software even if storage capacity is sufficient.	Validate capture host CPU, driver buffering, ring size, and sustained disk write behavior.

A clean storage result does not prove packet loss will be zero. If the write rate, packet rate, or burst profile is near the capture system's limit, run a short rehearsal and compare dropped-packet counters before trusting a long production capture.

Worked Examples:

A default-style incident capture with a 1 Gbps link at 35% average utilization for 2 hours, full capture share, 750-byte average packets, a 1518-byte snap length, classic PCAP, no compression, and 20% reserve saves about 420 million packets. The base capture is about 299.63 GiB, and required storage rises to about 359.55 GiB after reserve. With 500 GiB available, the modeled margin is about 140.45 GiB.

A header-focused version of the same capture with a 128-byte snap length is much smaller because each saved packet writes only 128 packet bytes plus the 16-byte classic PCAP record header. The required storage falls to about 67.59 GiB, but the snap-length check warns that packets are truncated. That version may be acceptable for flow and header review, but not for payload evidence.

For a sampled high-speed plan, a 10 Gbps link at 60% utilization for 1 hour with 10% capture share, 900-byte average packets, a 256-byte snap length, PCAPNG EPB, 2:1 compression, and 25% reserve produces about 50.29 GiB required storage. The disk fit may look comfortable, while the packet-rate check still matters because the observed traffic rate is much higher than the retained share alone suggests.

FAQ:

Why can a capture file be larger than the retained traffic volume?

Each saved packet can add record overhead, and PCAPNG EPB also adds padding when the captured packet byte count is not aligned to a 4-byte boundary. Reserve then increases the final storage requirement after any compression setting.

Should snap length always match a full Ethernet frame?

Use a full-size value when payload, reassembly, or later forensic review may matter. Use a smaller value only when header evidence is enough and reducing disk use is an intentional tradeoff.

Why does the packet-rate warning use observed packets instead of only saved packets?

The capture point still has to inspect the observed traffic before filters or sampling reduce what is written. A high observed packet rate can stress CPU, kernel buffers, and capture software even when the saved file is smaller.

What should I fix when the calculator says "Check input"?

Look for zero or negative rate, duration, average packet size, or snap length; utilization outside 0% to 100%; captured traffic share outside greater than 0% through 100%; negative storage; compression below 1:1; or negative FCS bytes.

Do I need to upload a packet capture file?

No. The calculator works from numeric assumptions such as rate, duration, packet size, and format. It does not require packet payloads or capture files to estimate storage.

Glossary:

Average utilization: The share of the link rate expected to carry traffic during the capture window.
Captured traffic share: The percent of observed traffic retained after filters, direction selection, sampling, or capture-point scope.
Snap length: The maximum number of bytes saved from each packet.
Frame check sequence (FCS): Ethernet trailer bytes that most host captures omit, but some capture adapters can store.
Base capture file: The modeled capture size before compression and storage reserve.
Required storage: The final modeled disk requirement after compression and reserve.

Packet Capture Size Calculator

{{ result.summaryTitle }}

Technical Details:

Formula Core:

Format Overhead:

Status Rules:

Everyday Use & Decision Guide:

Step-by-Step Guide:

Interpreting Results:

Worked Examples:

FAQ:

Glossary:

References:

Packet Capture Size Calculator

{{ result.summaryTitle }}

Introduction:

Technical Details:

Formula Core:

Format Overhead:

Status Rules:

Everyday Use & Decision Guide:

Step-by-Step Guide:

Interpreting Results:

Worked Examples:

FAQ:

Glossary:

References: