Will splitting a capture break its sessions?

Splitting by packet count or by seconds can cut a TCP session in two, and each part then misses the other half. Keeping one host or one conversation keeps every session of it whole.

Should I zip a capture that is over the limit?

No. A-Packets reads .pcap and .pcapng files, not archives, so a zipped capture is refused. Cut the capture down to the traffic you need instead.

Which part of a long capture should I upload first?

The part that holds the moment of the complaint. Find its time with capinfos or in the traffic chart of a first report, then cut a window around it with editcap.

Before you upload

Split a large PCAP file into the part that answers your question

Updated 2026-11-06 · Every command run or checked against its tool's documentation

Upload PCAP All capture guides

Free uploads create public reports. Use only sanitized captures; choose private analysis for sensitive traffic.

An hour of capture on a busy link runs to hundreds of megabytes, and most of it is traffic nobody asked about. Before you split a large PCAP into blind slices, decide what the question needs: one host, one conversation, or a few minutes around the complaint. Wireshark's command-line tools do each of these in one line, and tcpdump can cut by size. The examples run on a public 11 MB capture from malware-traffic-analysis.net (2026-01-30-PhantomStealer-infection.pcap); the commands work the same on a file a hundred times larger.

A-Packets Connections view ranking host pairs by bytes, the top pair at 11.38 MB — The Connections view of the SHub Stealer sample ranks host pairs by bytes. One pair carries 11.38 MB of the 16 MB file, so keeping or dropping that conversation decides most of the size.

Measure the file before you cut it

capinfos -c -s -d -u 2026-01-30-PhantomStealer-infection.pcap
tshark -r 2026-01-30-PhantomStealer-infection.pcap -q -z conv,ip

capinfos answers the first questions: 8,689 packets, 11 MB, 50.96 seconds. The conversation table from tshark answers the next one, where the bytes are. In this capture the infected host 10.1.30.101 exchanged 9.6 MB with 185.27.134.154 and 2 MB with 104.16.78.6; everything else is a few kilobytes. That split is typical. A handful of transfers make up the size, and the evidence you need is often in the small conversations around them, so measure before you throw anything away.

Keep one host or one conversation

tshark -r big.pcap -Y "ip.addr == 104.16.78.6" -w host.pcap
tcpdump -r big.pcap -w host.pcap 'host 104.16.78.6'

Both commands kept the same 1,609 packets, a 2.1 MB file. tshark -Y takes a Wireshark display filter, so it understands protocols and fields: dns or tls.handshake, or tcp.stream == 7 for one connection. tcpdump -r takes a BPF filter, which knows only addresses, ports and protocol numbers but reads a multi-gigabyte file faster. Cutting by host is the safest reduction there is: every session of that host stays complete, from the handshake to the last byte, so A-Packets can still carve its files and read its logins.

Cut a time window around the complaint

TZ=UTC capinfos -a -e big.pcap
editcap -A 2026-01-30T20:21:20Z -B 2026-01-30T20:21:30Z big.pcap window.pcap

The ten-second window kept 2,433 packets. Mind the clock: capinfos prints packet times in your local time zone unless TZ=UTC is set, while a time ending in Z is UTC to editcap. Copying a local time into a UTC window shifts it by your offset, and our first try returned an empty file. A window also cuts sessions that started before it, so a TLS session that began earlier keeps its data but loses the handshake with its server name and certificate. Start the window a little before the event.

Split into parts of equal size, time or count

tcpdump -r big.pcap -w part.pcap -C 20
editcap -i 20 big.pcap part.pcap
editcap -c 3000 big.pcap part.pcap

When every packet matters, split without filtering. tcpdump -C 20 starts a new file after 20 million bytes, which keeps each part under the 25 MB public limit; on our sample -C 5 wrote part.pcap, part.pcap1 and part.pcap2. editcap -i starts a new file every N seconds and -c every N packets, naming the parts with a number and the time of their first packet, such as part_00000_20260130212106.pcap. Each part becomes its own report, and a TCP session that crosses a boundary is split between two of them. mergecap -F pcap -w joined.pcap part.pcap part.pcap1 part.pcap2 puts the parts back together: our three parts joined into all 8,689 packets.

Shrink without losing the evidence

Duplicates are free to remove. editcap -D 100 big.pcap dedup.pcap drops any packet identical to one of the previous 100, which helps with mirror ports that copy a packet twice and with pktmon captures recorded at several components; on our clean sample it found none. Truncation is the opposite case: editcap -s 96 took the sample from 11.9 MB to 1.1 MB by keeping only the first 96 bytes of each packet, and with the payloads goes everything A-Packets reads from them, carved files, logins and HTTP bodies among them. Use it only when the question is who talked to whom. If the capture must stay whole, Professional and Advanced plans take 50 and 100 MB, as the pricing page lists, and the self-hosted PCAP analyzer runs on your own servers.

Questions about cutting captures down

Will splitting a capture break its sessions?: Splitting by packet count or by seconds can cut a TCP session in two, and each part then misses the other half. Keeping one host or one conversation keeps every session of it whole.
Should I zip a capture that is over the limit?: No. A-Packets reads .pcap and .pcapng files, not archives, so a zipped capture is refused. Cut the capture down to the traffic you need instead.
Which part of a long capture should I upload first?: The part that holds the moment of the complaint. Find its time with capinfos or in the traffic chart of a first report, then cut a window around it with editcap.