Upload PCAPs

From the analyzer landing page choose Upload a PCAP (or press the upload action in the capture library). You can upload multiple .pcap, .pcapng, or .cap files at once. The uploader shows progress, size limits, and which captures will be private or published.

Choose what happens next

The upload dialog starts with the real workflow choice:

• Agent investigation uploads one PCAP into a focused Agent workspace. Choose what PacketSafari should answer and how quickly it should trade first-result speed for capture-wide context.
• Inspect manually uploads and processes the PCAP, then opens the packet and summary workflow for hands-on analysis.

The setup is progressive. Agent investigations move through focused Goal, Starting point, Plan, and Review steps, while manual uploads skip the Agent-only decisions. Each setup screen shows only its current decision; the Plan step shows all three speed-versus-verification choices directly, and the final Review confirms the complete selection. Optional Privacy, Email, Agent, Triage, Security, and Developer controls remain available from Advanced settings on Review without adding another required step or dialog.

For an Agent investigation, first choose the question. Is the network at fault? is a focused incident shortcut: describe the reported symptom and PacketSafari returns one ownership assessment—network primary cause, network contributing factor, no captured network fault, or inconclusive—with packet evidence, capture limitations, and the next evidence to collect. It recommends Fast + verification and remains a goal, not another analysis workflow.

The standard report goals are Executive summary, Root cause, Security review, or Custom prompt. For a Root cause capture of 5 MiB or more, also provide a known IP, hostname, Call-ID, stream, protocol/error, or time range—or explicitly ask PacketSafari to search the whole capture first. Then choose the analysis workflow:

Both Fast answer and Fast + verification require a concrete operator-entered problem/question or focused starting point. Selecting only a preset is not enough. You do not always need an exact connection selector: a specific symptom can qualify for bounded discovery. For a large root-cause capture without structured focus, PacketSafari recommends Triage then report instead of silently blocking an informed early-start choice. Triage then deep is the only broad preset-only path.

Selecting Security review automatically enables the complete Suricata-compatible IDS scan and keeps PacketSafari Triage running. The results persist in Security, independently of which Agent report milestones the selected workflow includes. Available MITRE ATT&CK mappings remain visible with those security findings.

• Fast + verification is the recommended early-start path when the question/goal/size policy makes it eligible. A focused Agent uses your concrete question to produce a clearly labelled Preliminary Report while PacketSafari Triage processes the wider capture. A fresh Verification starts from the durable Preliminary Markdown without waiting for full Triage and challenges its material conclusions. Triage continues, then capture-wide adjudication produces a Final Report that can visibly supersede an earlier outcome. Admins and on-prem operators can change the runtime profile without changing this workflow.
• Fast answer starts a bounded preliminary analysis for that concrete question or focus as soon as the capture is safely readable. It does not wait for Triage or full IDS. When full IDS is requested, the preliminary result is labelled IDS pending until that independent Security milestone completes or fails.
• Triage then report waits for capture-wide Core processing to complete. Agent then retrieves the bounded packet evidence it needs and produces one Final Report. This path has the slowest first response and the strongest capture-wide coverage boundary.

The recommendation is goal- and size-aware. Executive summary below 5 MiB and Security review up to 10 MiB recommends Triage then report. Security review always requests full IDS plus Triage. With a concrete question on a larger capture, Fast + verification can be recommended so early milestones arrive while Triage/IDS continue into its existing Final Report. The backend 10 MiB boundary is the Sharkd progressive preliminary-first/indexing gate, not a security-postprocessor cutoff.

When Security review or Run full IDS security scan is selected, the Security settings separate three decisions:

• Quick IDS screening checks the first 50,000 packets and is explicitly partial; Complete IDS verification checks every packet and runs as its own evidence milestone.
• High + Critical rules reduce lower-severity noise; All severities includes informational and minor hunting indicators. Rule severity does not change how much of the capture is scanned.
• Emerging Threats Open and Stamus Lateral Movement can be selected for the investigation. PacketSafari local rules and enabled Abuse.ch feeds remain active. Stamus must first be enabled and refreshed by an administrator under Settings → Intelligence Feeds.

PacketSafari shows approximate active-rule counts when inventory is available. The selected source and severity policy is retained with the scan so a result cannot be silently reused under a different rule policy.

Is the network at fault? always requires the operator to describe a symptom and recommends Fast + verification. Its Preliminary Report remains provisional; Verification must independently adopt, qualify, rebut, or mark every strong earlier claim inconclusive.

For a qualified deployment profile and suitable capture up to 1 GiB, roughly two minutes to the Preliminary Report and roughly five minutes to Verification are validation goals measured from the point where the uploaded capture is ready for analysis. They are not guarantees, exclude network upload, and do not bound full Triage or the Final Report.

Before upload, any Triage/Final Report range shown in the plan is a size-based planning estimate because packet count is not available yet. PacketSafari may refine it after safe-open using packet count; protocol mix and runtime load also affect the result. See Investigation Path Guide and Processing runtime.

These are analysis-depth choices. They are separate from the question preset, model profile, who drives the investigation, anoncap anonymization, and report-email delivery. For a visual comparison, see Investigation workflows or the detailed Investigation Path Guide.

Hosted Agent Pro users choose the investigation workflow first. Where the deployment allows a model-profile choice, they can then select Standard model or Strongest model without changing what Fast answer, Fast + verification, or Triage then report means. A user-initiated full analysis counts as one analysis run only when its workflow completes, regardless of model or depth. Upload or service failures, interruptions, rejected submissions, and automatic retries do not consume a run.

If Anonymize before upload is enabled, the queued Agent prompt runs on the anonymized sibling capture. If report email delivery is enabled for the deployment and your entitlement allows it, PacketSafari can email selected Preliminary Report, Verification, and Final Report milestones separately. Email delivery is selected by default when delivery is available, and you can turn it off or change the selected milestones before starting. Fast answer selects only the Preliminary Report; Fast + verification selects all three significant milestones; and Triage then report selects its Final Report.

Choose an organization workspace

For an account with one active organization, PacketSafari selects that workspace automatically. If you belong to multiple active organizations, the metadata step shows a required Organization workspace selector. Choose the customer workspace that should own the capture before uploading.

The selected organization supplies the capture's shared-access default, pooled upload and storage quota, retention policy, AI-provider policy, and analysis capacity. That organization ID remains stored on the capture and its derived cases, tags, profiles, saved filters, chats, investigations, and reports. Changing the selector on a later upload does not move an existing capture.

When an Agent upload exactly matches a capture that is already visible, PacketSafari reuses the stored capture instead of importing another copy. The question, workflow, verification, and delivery choices still start a new investigation; deduplication does not cancel the requested analysis.

Only active organizations with an unexpired entitlement are available. If the workspace list cannot be loaded or the selected organization is unavailable, the upload stops instead of falling back to a different tenant. See Organizations for roles, sharing, quotas, and governance.

Starting AI work after upload

PacketSafari does not run a separate background AI summary after upload. Model-backed work begins through an explicit chat or investigation action:

Deterministic upload and Triage signals remain visible while processing continues. They do not create a second AI result or replace an explicit Copilot or Agent run. Follow-ups, retries, resumes, and report stages inside the same Agent investigation remain included in its Analysis run. Automatic retries and internal tool/model calls never consume another customer-visible allowance.

When Agent investigation is configured to email reports, PacketSafari durably stores the request with the investigation and tracks each selected Preliminary Report, Verification, and Final Report delivery separately from the Agent run. A delivery can still be waiting, queueing, queued, sending, sent, failed, or skipped after the relevant report milestone finishes. Triage and indexing progress do not generate an email sequence.

Create a protected copy during upload

In the Review step, enable Protect capture with Anoncap. PacketSafari stores the original upload first, then runs anoncap as a background follow-up and creates a protected sibling capture.

• When anonymization is enabled, the Privacy pane exposes the complete anoncap configuration directly without opening another dialog.
• Network evidence is the recommended sharing profile: it preserves supported tunnel and L2–L4 evidence while removing application payload. An optional stronger setting also hides topology and MAC-vendor detail.
• Application evidence · DeepAnon keeps application payload and rewrites supported HTTP, SIP, Diameter, and Kerberos identity fields. Unsupported or encrypted values can remain, so this profile carries more disclosure risk.
• Free SaaS users receive the public/basic policy. Active premium and Enterprise SaaS members, admins, and on-prem users can also configure PacketSafari's private privacy classes and identity groups.
• The upload dialog defaults to scrubbing pcapng metadata and comments from the anonymized sibling capture.
• Sanitize pcapng metadata removes capture-level metadata such as section comments, capture application / OS strings, interface names and descriptions, address info, name-resolution blocks, and embedded decryption-secret blocks.
• Sanitize comments removes pcapng capture comments and per-packet comments.
• PacketSafari stores anoncap run metadata on the capture.
• PacketSafari keeps the original upload by default and creates the anonymized result as a separate sibling capture. If you turn source retention off, the original is deleted only after the protected sibling succeeds.
• For the fuller workflow and current protocol coverage, see How to anonymize a PCAP.

What happens after upload

• The capture is stored in your library and processed in staged background work.
• PacketSafari runs a fast minimal capinfos metadata pass after storage. This records basic file facts and does not count as full processing.
• PacketSafari now distinguishes between a capture being open ready and being fully complete.
• Metadata, basic packet openability, and the first useful analyzer surfaces arrive first.
• Deeper dashboards, heavy post-index families, and optional large-capture work can continue refining after the packet view is already usable.
• When heavy follow-up work is deferred, PacketSafari records it as queued follow-up work instead of leaving it as an implicit placeholder.
• Captures tagged noAI keep normal packet access, but AI-assisted analysis and AI-derived packet insights are disabled. In shared views this means PacketSafari treats those AI insight requests as a terminal skipped state instead of continuing to poll.
• Visibility depends on deployment mode and entitlement. Organization uploads use the selected workspace's organization or private default; other hosted and on-premises uploads continue to follow their applicable account and deployment policy.
• Each capture gets a metadata card with owner, packet count, tags, histograms, and download controls.
• You can open the analyzer, launch PacketSafari Agent, start a Copilot chat, or stay in the Agent waiting room when the upload was started with Agent investigation.

The deterministic first-open evidence surface is documented in Upload Insights.

If you want to see a completed investigation before uploading production traffic, read the sample Agent report, or review the scenario list in Demo Captures.

Fast answer and deferred processing

Use Fast answer in the Agent investigation path when you want PacketSafari Agent to begin from bounded packet access as soon as the file is safely readable. It returns one clearly labelled preliminary report. PacketSafari Triage can continue in the background, but Fast answer does not automatically create an independent Verification or Final Report.

Fast answer needs a concrete question or focused starting point entered by the operator. A preset-only generic request is not sufficient. This does not mean you must know the exact 5-tuple: a concrete symptom such as “SSH logins stall after authentication” can be enough for bounded discovery.

For Root cause captures of 5 MiB or more, the upload flow shows how PacketSafari will start. When the question contains an IP address, port, stream, Call-ID, phone number, hostname, BSSID, protocol/error, or time range, the UI labels it a Focused start. If those details are not known, the same concrete question starts Automatic discovery: PacketSafari finds and ranks relevant traffic, then performs focused packet checks. A selector can reduce discovery time, but it is optional and never blocks either early-start workflow.

With a concrete problem on a larger capture, PacketSafari recommends Fast + verification so the Preliminary Report and independent Verification can progress while capture-wide Triage continues. A blank preset-only request still recommends Triage then report.

In advanced upload metadata, Skip full processing after upload stores the PCAP and makes raw packets available without queuing the full indexing pipeline.

This option is off by default. When it is on, PacketSafari still runs the minimal capinfos metadata pass, then opens the capture in raw packet mode. Summaries, enriched dashboards, and PacketSafari Triage context become available only after an owner or admin chooses Process now.

See Raw-First Captures for the full workflow and limitations.

Readiness states

During upload and indexing you may see these lifecycle states:

• Accepted: the file was accepted and PacketSafari is preparing metadata and the first analyzer view.
• Open ready: the real packet view can open. Some dashboards may still be refining.
• Refining: the capture is usable, but optional or heavy analysis is still running in the background.
• Complete: all required analysis for this capture generation is finished.
• Failed: a required stage failed and the capture needs recovery or reprocessing.

For large captures this is intentional. PacketSafari favors a fast, trustworthy first open instead of blocking the entire analyzer on the most expensive post-processing steps.

Adaptive analysis on large captures

Not every expensive artifact has to be built during the first ingest pass.

• Small captures often get more analysis eagerly.
• Larger captures can defer heavier artifacts such as file-object inventory or deeper infrastructure summaries.
• When a dashboard, API, or AI workflow requests a deferred artifact, PacketSafari can reuse the persisted result, materialize it on demand, or queue it in the background depending on cost.
• PacketSafari Triage uses the upload policy for PacketStats rule coverage: complete rule stats below 50 MiB, otherwise the first 1,000,000 frames. A full scan can still be started later when an owner or admin asks for every packet to be checked. Very large full scans are guarded by daily quota and can be cancelled at safe checkpoints.

You do not need to manage those decisions manually in normal use. The analyzer surfaces label provisional or refining results when they are not yet authoritative.

Busy queue behavior

If PacketSafari is already processing other captures, uploads should still behave predictably:

• Queue pressure can downgrade the first pass instead of rejecting the upload outright.
• The capture should still be stored in the library and listed immediately.
• Basic metadata and openability work can still run first while deeper analysis waits.
• Heavy follow-up work can remain queued until capacity is available.
• Eligible queued heavy follow-up tasks can expose a cancel action in upload insights so operators can stop work that is no longer worth finishing.

PacketSafari also reaps obviously stale queued or running task records automatically. Old zombie tasks should not keep new uploads blocked forever just because a worker died or a deferred follow-up never finished cleanly.

See also:

• Analysis Readiness and Refinement
• Processing Runtime and Adaptive Analysis
• Raw-First Captures
• Sample Agent report
• Demo Captures

Tagging while uploading ⚡️

Create tags in Settings → Tags, enable upload tagging in your profile, then select the tag before dropping files. The selected tags are added automatically as the files are stored.

Limits and privacy

• Current hosted SaaS upload ceilings are 1 MB retained for Analyzer Free, 200 MB for Copilot Pro and individual Agent Pro, and 1 GB for qualified Enterprise Shared or Dedicated organization workspaces. On-prem accepts up to the configured deployment ceiling; higher limits must be validated against the customer's storage, memory, queue, and AI profile.
• Some deployments can also disable uploads entirely or restrict related AI workflows with runtime policy flags.
• Anonymous upload flows require both authenticated uploads and anonymous uploads to be enabled at the deployment level.
• Plan entitlements, active subscription dates, download access, and other exceptions are documented in User Types and Entitlements.
• Respect data ownership—only upload captures you are allowed to store and analyze.