PCAP to JSON Converter
Upload a PCAP/PCAPNG, optionally add a Wireshark display filter, and get rich JSON output.
The complete PCAP to JSON guide
A PCAP (Packet Capture) or PCAPNG (Packet Capture Next Generation) file is a binary recording of network traffic taken directly from a network interface. Every frame, every header, every byte the kernel saw is preserved exactly as it appeared on the wire. That raw fidelity is what makes pcap the gold standard for network forensics, debugging, and security analysis — but it is also what makes pcap painful to work with outside of a dedicated GUI like Wireshark.
This converter translates the binary capture into JSON, NDJSON, or compact JSON. Once your packets are structured text, you can query them with jq, stream them into Splunk or Elasticsearch, load them into a Python or R notebook, diff them with git, or store them alongside your application logs. The goal is to turn a file that only Wireshark understands into data that every tool in your stack already understands.
Under the hood, we run tshark (the command-line sibling of Wireshark) with the exact same dissectors that Wireshark uses. You get the full protocol tree — frame metadata, Ethernet, IPv4/IPv6, TCP, UDP, DNS, HTTP, TLS, ICMP, QUIC, and hundreds more — without installing anything locally. The conversion happens on a temporary worker, the capture is processed in memory or on scratch disk, and nothing is retained after the request completes.
PCAP, PCAPNG, CAP — what is the difference?
Classic PCAP (.pcap) is the original libpcap format from 1998. It is simple and ubiquitous: a global header, then a stream of packet headers and raw packet bytes. Almost every packet sniffer on earth can read it — tcpdump, Wireshark, Scapy, Zeek, Snort, Suricata — and its small overhead is one reason it is still the default in many tools.
PCAPNG (.pcapng) is the modern successor. It is a block-based format that adds per-packet comments, multiple interfaces in one file, per-interface statistics, high-resolution timestamps (nanoseconds instead of microseconds), and custom metadata blocks. Wireshark has defaulted to PCAPNG since version 1.8. If your capture came from a recent Wireshark, tshark, dumpcap, or tcpdump -w on a modern kernel, it is probably PCAPNG even if the file extension says .pcap.
The .cap extension is an alias, usually seen in legacy Windows tools and some enterprise sniffers. It can contain either PCAP or PCAPNG data. We detect the real format from the file's magic bytes (0xa1b2c3d4 and its little-endian twin for PCAP, 0x0a0d0d0a for PCAPNG), so renaming .pcapng → .cap or vice versa is fine — the converter will still open it correctly as long as the binary inside is valid.
How the conversion actually works
When you submit a file, it travels over HTTPS to our worker, is written to a scratch directory, and tshark is invoked with carefully chosen arguments: -r for the input file, -T json for structured output, -c for the packet cap, optional -Y for your Wireshark display filter, and optional -J to restrict the protocol layers on basic preset. tshark reads the capture, runs every applicable dissector against each packet, and emits a JSON document where each packet is a nested object keyed by protocol layer.
For the fast path (default format, all fields, timestamps on, no redaction) we stream tshark's stdout straight into the response body, so the only limit is disk throughput. When you enable redaction, pick headers-only, or choose NDJSON/compact output, we buffer the parsed JSON in memory, post-process it (strip fields, mask IP/MAC, re-serialize), and stream the result back. That post-processing path has a generous memory ceiling so normal captures with up to 20,000 packets comfortably complete.
The conversion is stateless. There is no queue, no persistent upload, no pre-processing. Every request gets its own scratch directory, which is deleted as soon as the response stream ends or the request aborts. We do not inspect payloads, we do not extract credentials or cookies, and we do not log packet contents — only request metadata like duration and byte size for operational monitoring.
Output formats: JSON vs NDJSON vs Compact
Wireshark JSON — The exact shape that tshark -T json produces: a top-level array of packet objects, pretty-printed and indented so it is easy to eyeball in a text editor. This is the most human-readable option and the one to pick when you want to sanity-check a capture by scrolling through it, paste a packet into a bug report, or run a small jq query. The downside is size: indentation and whitespace inflate the file 20-30% compared to compact form.
NDJSON (one packet per line) — Newline-Delimited JSON writes exactly one packet per line, each line a complete, valid JSON object. This is the format you want for streaming pipelines: Logstash, Filebeat, Splunk HEC, AWS Kinesis, Google Pub/Sub, and BigQuery all expect NDJSON. It is also ideal for grep, head, tail, wc -l, and line-based shell loops — you can see the packet count with a single `wc -l`, and sampling is as simple as `head -n 1000`. jq reads NDJSON transparently with --slurp or line-by-line.
Compact JSON — A top-level array with no whitespace between tokens — the smallest possible representation. Use it when you are shipping captures across a slow link, storing them in object storage where bytes equal money, or embedding a packet list inside another JSON document. Compact JSON is harder to read by eye, but gzip compresses it almost as well as the pretty version, so the savings matter mostly for uncompressed transport and storage quotas.
Field modes: controlling what ends up in the output
All — Every layer tshark's dissectors produce for the packet, nested by protocol name. For a single HTTPS packet you will typically see frame, eth, ip, tcp, and tls layers, each with dozens of sub-fields (sequence numbers, flags, cipher suites, SNI, cert fingerprints). This is the richest and largest output and the right default when you do not yet know which fields you will query later.
Headers only — Drops the bulky application-layer payloads and keeps transport-layer and below: frame, eth, ip/ipv6, tcp/udp/icmp. Typical size reduction is 5-15x on normal web traffic and much more on captures dominated by large file transfers. Pick this when you want traffic-pattern analysis (who talks to whom, how often, at what time) rather than content inspection.
Payload only (base64) — Keeps the raw per-layer bytes, base64-encoded, plus just enough metadata (packet number, timestamps) to correlate them. This is the format to pick for malware analysis, custom protocol reverse-engineering, or when you want to feed bytes into another parser that expects a base64 string rather than a structured dissection.
Display filters: shrink the capture before conversion
The display filter box accepts Wireshark's filter syntax — the same language you type into the Wireshark filter bar. Filters run inside tshark before JSON is produced, so filtering down first is the single most effective way to speed up conversion and shrink the output. A few useful starting points:
ip.addr == 10.0.0.5— only packets to or from a specific hosttcp.port == 443 and tls.handshake.type == 1— TLS ClientHello messages for SNI and cipher-suite auditingdns and dns.qry.name contains "example"— DNS lookups matching a namehttp.request.method == "POST"— HTTP POST requests (plaintext HTTP only — TLS traffic is opaque)tcp.analysis.retransmission— suspected TCP retransmissions for performance analysis!(arp or stp or cdp or lldp)— exclude common L2 chatter when you only care about L3+
Filters combine with `and`, `or`, `not`, and parentheses. If you are unsure of a field name, open the capture in Wireshark once, right-click a field, and pick "Apply as Filter → Selected" — Wireshark will show the exact filter expression you need. Every filter you test locally will work identically here.
Packet cap and sampling strategy
The Max packets field limits how many packets tshark will emit. The cap is necessary because a single 100 MB pcap can contain hundreds of thousands of packets, and the full JSON dissection of each packet can reach several kilobytes. Without a ceiling, converting a busy capture can produce gigabytes of JSON that no tool wants to read.
The right number depends on what you are investigating. For a single user session or a short incident window, 1,000-5,000 packets is usually enough. For protocol debugging where the problem occurs inside the first few packets, 200 is plenty. For statistical flow analysis across a longer window, push the cap to 20,000 and combine it with a display filter that keeps only the interesting traffic. When in doubt, start low with headers-only, look at what you got, then rerun with a tighter filter and a larger cap.
Timestamps: what they mean and how to parse them
Every packet has a capture timestamp. In the JSON output, tshark emits it as frame.time_epoch (seconds since 1970-01-01 UTC, with microsecond or nanosecond decimals), frame.time_relative (seconds since the first packet in the capture, useful for measuring RTT and delays), and frame.time (a formatted local string). Turn timestamps off if you are sharing captures where wall-clock time would leak sensitive information about business hours, time zones, or incident timelines.
Epoch timestamps are the easiest to work with programmatically. In Python: datetime.fromtimestamp(float(pkt['frame']['frame.time_epoch']), tz=timezone.utc). In jq: .frame["frame.time_epoch"] | tonumber | strftime("%Y-%m-%d %H:%M:%S"). In BigQuery: TIMESTAMP_SECONDS(CAST(time_epoch AS INT64)). Relative timestamps are handy for plotting packet sequences on a shared origin without worrying about time zones.
Redaction: sharing captures without leaking identities
The redact toggle masks the last octet of every IPv4 address, the last byte of every IPv6 address, and the last byte of every MAC address. 192.168.1.42 becomes 192.168.1.0, aa:bb:cc:dd:ee:ff becomes aa:bb:cc:dd:ee:00. This is enough to anonymize individual endpoints while preserving subnet structure, traffic patterns, and vendor OUIs — useful when you need to show a capture to a vendor, publish it in a blog post, or attach it to a public bug report.
Redaction is NOT a guarantee of anonymity. Application-layer payloads (HTTP bodies, DNS queries, TLS SNI, cookies, email addresses inside messages) are not touched — only network-layer identifiers. If you need to share a truly sanitized capture, combine redaction with a display filter that drops sensitive protocols (for example `not http.cookie and not http.authorization`) and consider running the capture through a dedicated anonymization tool like TraceWrangler afterward.
When people reach for this converter
- SIEM and log pipeline ingestion — Convert a capture to NDJSON and pipe each line into Splunk HEC, Elasticsearch, Grafana Loki, or a Kafka topic. One packet equals one event; dashboards and alerts that already understand JSON logs instantly understand your network data too.
- Incident response and threat hunting — Filter the capture to suspicious traffic (beaconing intervals, unusual DNS patterns, odd TLS cipher suites) and convert only what matters. Redact IPs before sharing with external responders.
- Dataset preparation for ML — Compact JSON loads cleanly into pandas, Arrow, or DuckDB. Use headers-only to keep the dataset small and the features focused on flow-level signals: packet sizes, inter-arrival times, TCP flags.
- Protocol debugging during development — When an API behaves differently in staging and production, a five-second capture on both sides converted to JSON lets you diff request/response structure line by line — far faster than eyeballing Wireshark.
- Automated QA and regression tests — Snapshot the expected JSON from a known-good capture, run your test, and assert the new capture converts to the same JSON (modulo timestamps). Any change in protocol behavior surfaces as a diff.
- Teaching networking — JSON output is far gentler than a packet-bytes view for students new to networking. They can explore the protocol tree with a text editor before ever opening Wireshark.
Post-processing recipes
Once you have the JSON, here are compact snippets for the most common follow-up tasks. All examples assume you downloaded the NDJSON output.
- jq — count unique destination IPs
jq -r '.layers.ip["ip.dst"]' capture.ndjson | sort -u | wc -l
- Python — top DNS queries
import json, collections names = collections.Counter() with open("capture.ndjson") as f: for line in f: pkt = json.loads(line) q = pkt.get("layers", {}).get("dns", {}).get("dns.qry.name") if q: names[q] += 1 print(names.most_common(20)) - Splunk HEC — stream NDJSON in
curl -X POST "$HEC_URL/services/collector/event" \ -H "Authorization: Splunk $HEC_TOKEN" \ --data-binary @capture.ndjson
Troubleshooting — common errors and fixes
- "File too large" — Your upload exceeded the 200 MB ceiling. Slice the capture in Wireshark (File → Export Specified Packets → select a time range) or run tcpdump/editcap with `-C` to split it into smaller files before uploading.
- "Output too large" — tshark's dissection produced more JSON than the response cap allows. Lower the packet count, apply a stricter display filter, switch to Headers-only field mode, or use Compact JSON output.
- "Parse error" — tshark could not read the file. Re-open the capture in Wireshark and save it again as PCAPNG; that usually heals truncated headers or incomplete blocks. Very old formats (Sun snoop, Network General NetMon) are not supported.
- Empty output — Your display filter matched zero packets. Remove the filter, confirm you are seeing any packets at all, then reintroduce the filter one clause at a time.
- Conversion hangs or times out — Captures dominated by heavy TLS re-assembly can be slow to dissect. Lower the packet cap to 1,000-2,000 first to confirm the file is good, then raise gradually.
- "invalid file type" — The file extension was accepted but the magic bytes did not match any known pcap format. This usually means the file was corrupted in transit or is actually a zip/rar archive with a misleading extension.
- Unexpected JSON structure — tshark nests fields under a `_source.layers` key in recent versions. Use `.layers` paths in your jq queries (not top-level protocol names) and consult `tshark -T json` documentation for the current schema.
Best practices that save you hours
- Capture with a filter, not after. Running `tcpdump -i eth0 'host 10.0.0.5 and port 443'` is orders of magnitude cheaper than capturing everything and filtering in the converter. Tight capture filters also mean smaller files and fewer privacy surprises.
- Split long captures before upload. `editcap -c 10000 in.pcap chunk` produces chunks of 10,000 packets each. Convert each chunk separately so you can parallelize downstream processing and recover quickly if one chunk is corrupt.
- When in doubt, start with Headers-only. The output is small, quick to eyeball, and almost always enough to answer 'what talked to what and when'. Drop to All fields only when you have identified a specific packet worth dissecting in detail.
- Keep a Wireshark profile with your custom columns and protocol preferences. When this tool produces JSON that looks different from what Wireshark shows, it is almost always a preference difference (e.g. 'Allow subdissector to reassemble TCP streams'), not a bug.
- Use the relative timestamp for latency and RTT measurements, not the epoch timestamp. Relative time is monotonic within a single capture and immune to clock skew; epoch timestamps can jump backwards when a machine's clock is corrected mid-capture.
Privacy and data handling
Your capture is processed transiently. It arrives over TLS, is written to a per-request scratch directory, passed to tshark, and the scratch directory is deleted as soon as the response stream ends or the client disconnects. We do not write your capture to any persistent store, do not ship it to third parties, and do not inspect its payload beyond the dissection tshark needs to produce JSON.
Operationally we log only metadata — request duration, response size, HTTP status — to monitor uptime and abuse. No packet contents, no addresses, and no payloads ever enter the log pipeline. If you still prefer extra caution, apply a display filter before upload, toggle redaction for IP/MAC masking, or run the capture through a dedicated scrubber first. For truly sensitive captures you can also self-host tshark; everything this tool does is a thin wrapper over `tshark -r in.pcap -T json`.
Frequently asked questions
- Can I convert PCAPNG? Yes. PCAP, PCAPNG, and .cap are all handled. The magic bytes inside the file determine the parser, so the extension you picked does not matter.
- Is my file uploaded to a server? It is uploaded for processing, but only transiently. Nothing is retained after the conversion finishes, and payloads never reach operational logs.
- Why is my output too large? tshark produces 3-10x more bytes in JSON than the original capture because every protocol field is spelled out verbatim. Lower the packet cap, use Headers-only, or combine with a display filter.
- How do I write a Wireshark display filter? Open the capture in Wireshark once, right-click a packet field, pick "Apply as Filter → Selected". The filter that appears in the toolbar is identical to what you type here.
- What is NDJSON and why would I pick it? Newline-Delimited JSON: one packet per line. It is the de-facto format for log pipelines (Splunk, Elastic, Loki) and the only format that lets you process 20,000 packets with standard shell tools without loading everything into memory.
- Does it preserve packet timestamps? Yes, both absolute (epoch) and relative timestamps, at microsecond precision for PCAP and nanosecond precision for PCAPNG. Toggle the switch off if you are sharing captures where wall-clock time would leak context.
- Can I decrypt TLS traffic? Only if your capture already contains the session keys (e.g. exported via SSLKEYLOGFILE before capture). This converter does not accept key files — it treats encrypted payloads as opaque bytes.
- How does this differ from `tshark -T json` on my laptop? Mechanically it is the same thing, just without installing Wireshark and without tying up your local disk or CPU. Most people use the web tool for quick one-offs and scripted batches; heavy recurring work is better scripted against local tshark.
- Will the JSON validate against tshark's schema? Yes — the default fast path emits byte-for-byte the same JSON tshark produces locally. When you change field mode, enable redaction, or pick NDJSON/compact, we re-serialize after dissection, but the field names and value types remain exactly what tshark produced.
- Is there an API? Yes. POST multipart/form-data to /api/tools/pcap-to-json with the same fields this form submits — `file`, `mode=download`, `outputFormat`, `fields`, `maxPackets`, `displayFilter`, `includeTimestamps`, `redact`. The response is the converted file with Content-Disposition set for direct download.
This tool uses a server-side service for processing; uploaded files or requests are not kept for long-term storage.
About
Turn raw packet captures into structured JSON for scripting, incident response, and automation. Upload a .pcap/.pcapng, optionally apply a Wireshark display filter, and export in a format that fits your pipeline (JSON array, NDJSON, or compact).
Filters are the key for practical exports: keep only what you need (e.g., specific hosts, ports or protocols), then cap the number of packets if you’re creating a lightweight sample for tickets, debugging or dashboards. You can also toggle timestamps and choose how much of each packet to include (headers vs payload).
If you’re sharing captures, redaction helps reduce sensitive data exposure. The result is downloadable JSON that you can feed into jq, Python, SIEM tooling, or custom parsers—without manually clicking around in Wireshark.
How it works
- 1Open PCAP to JSON Converter and choose your file or enter the required input.
- 2Check the settings and start the process.
- 3The tool creates the result with temporary server-side processing.
- 4Download the output or copy the result when it is ready.