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.

Review the packet-capture inputs

{{ error }}

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 }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Packet capture storage is a capacity question hidden inside a diagnostic task. A busy interface can fill hundreds of gigabytes during a short incident window, and the file size is not just the user payload that crossed the link. Capture files store packet bytes, timestamps, link-layer context, and a record for every packet that is kept.

Network teams capture packets when counters, flow summaries, and application logs cannot show exactly what happened on the wire. They may need a rolling appliance buffer, a short security evidence window, a before-and-after maintenance trace, or a remote capture that must finish without filling the disk. The storage plan has to be made before the run because the first symptom of a bad estimate is often dropped packets or a truncated file.

The basic vocabulary separates link capacity from actual traffic. Link rate is the nominal speed of the monitored interface, while utilization is the share of that capacity carrying traffic during the capture window. Captured share is the portion retained after direction, interface, filter, or sampling choices. Snapshot length, often called snaplen, caps the bytes saved from each packet. File format is the container used to store those packet records, such as classic pcap or pcapng.

Packet capture storage flow from traffic load and filter share through snap length, file format overhead, and reserve storage. — Packet capture storage depends on traffic load, captured share, snap length, file format overhead, and reserve space.

The common shortcut, multiplying bandwidth by time, is only a starting point. It ignores utilization, filtered traffic, packet count, per-packet file records, compression, and the storage margin needed for rotation and indexes. It also hides a counterintuitive effect: many small packets can create a larger file than expected because each packet adds a record even when the packet data is short.

Snapshot length is the main size-versus-evidence tradeoff. A short snaplen can preserve Ethernet, IP, TCP, UDP, and application headers while dropping much of the payload, which is useful for privacy and storage control. The same choice can also remove bytes needed for stream reassembly, full payload inspection, or later proof that a packet contained a specific value.

Packet capture planning factors
Planning factor	What changes	Common mistake
Traffic level	Average bytes arriving during the capture window.	Sizing from port speed instead of measured utilization.
Packet size	Packet count, record overhead, and write pressure.	Assuming one gigabit of small packets costs the same as one gigabit of large packets.
Snap length	Bytes saved per packet and how much evidence remains.	Choosing header-only capture before confirming the analysis needs.
File format	Fixed file headers, per-packet records, padding, and metadata support.	Comparing pcap and pcapng as if only packet bytes mattered.

A useful packet capture estimate is a planning range, not a promise. Build it from measured averages when possible, then add room for bursts, capture-host limits, filesystem behavior, file rotation, and the common discovery that the investigation needs a longer window than expected.

How to Use This Tool:

Start with the capture point you actually plan to use, then adjust the assumptions that can be changed before the run: duration, captured share, snap length, compression, and reserve.

Enter the Link rate for the monitored interface or aggregate, then choose Kbps, Mbps, Gbps, or Tbps.
Set Average utilization from monitoring data or a realistic incident estimate. Do not leave it at port speed unless the link is expected to run full.
Choose the Capture duration in minutes, hours, or days, and set Captured traffic share for filtering, sampling, direction selection, or partial mirror coverage.
Enter Average packet size and Snap length. Use a short sample capture or interface statistics when packet size is available.
Select Capture file format. Classic pcap, pcapng enhanced packet blocks, and packet-data-only estimates use different overhead assumptions.
Enter Available storage and Storage reserve. A zero storage target leaves fit unchecked, while a reserve gives the plan room for bursty traffic and rotation overhead.
Open Advanced when compression or captured frame check sequence bytes apply. Keep compression at 1:1 unless you have measured a representative archive ratio.

After the estimate appears, compare Required storage with your target, then review Retention Checks for storage margin, snap length truncation, packet-rate pressure, format overhead, compression, and reserve guidance.

Interpreting Results:

Required storage is the planning number because it includes the estimated capture file, optional compression, and the reserve percentage. Base capture file shows the uncompressed file estimate before reserve, while Compressed capture size shows the size after the entered compression ratio.

Packets saved, Stored bytes per packet, and Average write rate explain why two captures with the same bit rate can stress storage differently. High packet rates increase CPU interrupt load, timestamping work, and record writes, so the packet-rate warning is a reason to check the capture host as well as the disk capacity.

Packet capture result fields and checks
Result area	What to trust	What to double-check
`Capture Budget`	Traffic volume, packet count, format overhead, required storage, and a 4 GiB rotation estimate.	Whether the average traffic and packet size reflect the capture window, not a quiet baseline.
`Retention Checks`	Fit status, snap length warning, packet-rate label, compression assumption, and reserve quality.	Whether a warning can be fixed by reducing duration, filtering traffic, or changing snap length.
`Capture Size Curve`	How base capture size and required storage grow as duration changes.	Where the curve reaches the storage target before the planned duration ends.
`JSON`	The numeric assumptions and computed values behind the visible estimate.	Whether exported assumptions match the capture runbook or ticket notes.

A Fits storage result does not prove the capture host can keep up with bursts. A Tight margin or Storage shortfall result means the plan should change before the run: shorten the capture, reduce captured share, use a defensible smaller snap length, improve compression, or add storage.

Technical Details:

Packet capture size is governed by two rates at the same time: byte rate and packet rate. Byte rate determines how much packet data may be saved. Packet rate determines how many timestamps and packet records the file has to carry. Small packets raise packet rate for the same bit rate, so record overhead and write pressure become more visible.

Snapshot length caps the captured length of each packet. When the snap length is larger than the modeled packet size plus captured frame check sequence bytes, the packet is treated as fully saved. When it is smaller, the saved packet bytes are reduced, but the packet record still exists. That is why a small snap length can lower storage sharply without removing all per-packet overhead.

Classic pcap is modeled as a lean container with a 24-byte file header and 16 bytes per packet record. The pcapng enhanced-packet estimate uses a 48-byte starting structure, 32 bytes per packet record, and four-byte alignment padding for packet data. Packet-data-only mode removes container overhead and is best read as a comparison floor, not as a normal capture-file estimate.

Formula Core:

The calculation converts rate, utilization, capture share, duration, packet size, snap length, format overhead, compression, and reserve into one required-storage estimate.

\begin{array}{lll} R_{avg} & = & R_{link} \times U \\ R_{kept} & = & R_{avg} \times S \\ N & = & \frac{R_{avg}}{8 \times P_{avg}} \times S \times T \\ B_{packet} & = & \min (P_{avg} + F, Snap) \\ B_{base} & = & B_{file} + N \times (B_{packet} + B_{record} + Pad) \\ B_{required} & = & \frac{B_{base}}{Q} \times (1 + V) \end{array}

Packet capture formula symbols
Symbol	Meaning	Input or output
`R_link`	Link rate in bits per second.	`Link rate`
`U`	Average utilization as a fraction.	`Average utilization`
`S`	Captured traffic share as a fraction.	`Captured traffic share`
`T`	Capture duration in seconds.	`Capture duration`
`P_avg`	Average packet size in bytes before snap length truncation.	`Average packet size`
`F`	Captured frame check sequence bytes, when the capture source includes them.	`Captured FCS bytes`
`Q`	Compression ratio, where `1` means no compression.	`Compression ratio`
`V`	Reserve fraction added after compression.	`Storage reserve`

For the default-style case of a 1 Gbps link at 35% utilization for 2 hours with 750-byte packets, full-length classic pcap, no compression, and 20% reserve, the estimate saves about 420,000,000 packets. Packet data contributes about 315,000,000,000 bytes, pcap record overhead adds about 6.26 GiB, and required storage lands near 359.6 GiB.

Packet capture format overhead assumptions
Format choice	Modeled overhead	Best interpretation
`pcap`	`24` bytes per file plus `16` bytes per packet.	A compact estimate for traditional single-interface packet captures.
`pcapng`	`48` fixed bytes, `32` bytes per packet, and four-byte packet-data padding.	A richer capture-file estimate when metadata, comments, or multi-interface context matters.
`Packet data only`	No file header, record header, or alignment padding.	A lower-bound comparison that does not represent a normal capture container.

Rate units are treated as decimal bits per second, so 1 Gbps means 1,000,000,000 bits per second. Storage units are binary units, so 1 GiB means 1,073,741,824 bytes. The display rounds values for readability, but the stored JSON keeps the raw byte, bit-rate, packet-rate, and duration values.

Packet capture validation and warning boundaries
Boundary	Rule used	Why it matters
Storage fit	`Storage shortfall` below target, `Tight margin` below `15%` remaining, otherwise `Fits storage`.	Low margin leaves little room for bursts, rotation, indexes, and longer capture windows.
Snap length	Warns when snap length is smaller than average packet size plus captured FCS bytes.	Truncation reduces storage but may remove evidence needed later.
Observed packet rate	`High` begins at `50,000` packets per second and `Very high` begins at `250,000`.	Packet rate can cause drops even when average byte rate looks manageable.
Compression ratio	Must be at least `1:1`.	Encrypted or already-compressed payloads may not shrink much after capture.
Reserve	`20%` or more is treated as suitable for planning, `10%` to under `20%` as caution, and lower values as weak.	Reserve absorbs normal variance between planning assumptions and the actual run.

Capture Planning Limits:

The estimate depends on averages. Real captures see bursts, packet-size shifts, asymmetric directions, mirrored traffic gaps, capture-driver drops, timestamp overhead, filesystem allocation effects, compression variance, and rotation policies. Leave more margin when the capture point is remote, the incident window is uncertain, or the capture host shares disk with other workloads.

No packet file is read or uploaded. The calculator works from numeric assumptions only, so it cannot confirm whether a short snap length preserves the protocol headers, payload bytes, or frame check sequence data needed for a specific investigation.

Worked Examples:

Busy office uplink:

A 1 Gbps uplink at 35% average use for 2 hours with 750-byte packets produces a required-storage estimate near 359.6 GiB in classic pcap with 20% reserve. A 500 GiB target has enough room, but the packet-rate check still deserves attention because the observed rate is about 58.3 kpps.

Header-focused troubleshooting:

A capture with 1500-byte average packets and a 128-byte snap length saves far fewer bytes per packet. The storage result improves, but the snap length check warns that most of the modeled packet is not retained. That may be acceptable for handshake timing or address analysis and unsuitable for payload proof.

Many small packets:

At the same bit rate, 100-byte packets create ten times as many packet records as 1000-byte packets. The file-format overhead share rises, and pcapng padding and record costs become easier to see in the estimate.

Storage shortfall before a long run:

If required storage exceeds the available target, reduce duration first when the incident window is flexible. If the window is fixed, use a capture filter or lower captured share. Lower snap length only after confirming that the remaining bytes are enough for the protocol evidence you need.

FAQ:

Why can the estimate be larger than rate times duration?

Capture files add headers and per-packet records. When packet count is high, those records can add meaningful storage beyond the captured packet bytes.

Why does average packet size matter?

Average packet size converts bit rate into packets per second. Packet rate controls how many records are written and helps flag capture-host pressure.

Should I always use a smaller snap length?

No. A smaller snap length can save storage and reduce retained payload, but it can also remove bytes needed for reassembly, payload checks, or later forensic review.

When should I choose pcapng instead of pcap?

Use pcapng when richer capture metadata, comments, or multi-interface context matters. Use classic pcap when a compact traditional capture file is enough for the workflow.

Does the calculation measure live traffic?

No. It estimates capture storage from the numbers entered. Use monitoring data or a short sample capture when you need better traffic and packet-size assumptions.

Glossary:

Packet capture: A saved record of packets observed at a network interface, tap, mirror port, or capture appliance.
Snapshot length: The maximum number of bytes retained from each packet.
Packet rate: The number of packets observed or saved per second.
Captured share: The percentage of traffic expected to remain after filters, sampling, direction selection, or capture-point scope.
pcap: A traditional packet capture file format with a global header and per-packet records.
pcapng: An extensible packet capture format that can store richer metadata and multiple interface contexts.
FCS: Frame check sequence bytes from a link-layer frame, present only when the capture source records them.

References:

PCAP Capture File Format, IETF Datatracker.
PCAP Now Generic (pcapng) Capture File Format, IETF Datatracker.
SnapLen, Wireshark Wiki.
dumpcap manual page, Wireshark.
How to capture network traffic in Linux, Simplified Guide.

Packet Capture Size Calculator

Introduction:

How to Use This Tool:

Interpreting Results:

Technical Details:

Formula Core:

Capture Planning Limits:

Worked Examples:

Busy office uplink:

Header-focused troubleshooting:

Many small packets:

Storage shortfall before a long run:

FAQ:

Glossary:

References: