Free · Native for macOS 26
Capture network traffic, trace each packet back to the app that sent it, and read HTTPS, HTTP/2 and HTTP/3 in plain text. No account, no subscription — your traces stay on your Mac.
Also on Homebrew: brew install --cask cocoapacketanalyzer
Notarized by Apple
English, Deutsch, 日本語
Light and Dark
No trial, no tiers, no account. Everything below is in the download.
Five questions people bring to a packet analyzer, and the screen that answers each one.
Capture
Pick an interface, or all of them at once, and packets appear in the list as they arrive, already dissected. The toolbar shows the activity, the packet count and the running time. Start the capture from the menu bar instead and it keeps running while you work in other apps; several captures run side by side.
Traffic by app
Switch on Record processes and every packet carries the app that sent or received it — Safari, not the WebKit process behind it. The Applications window adds up packets and bytes per app while the capture runs; double-click one to filter the packet list on it.
Decrypt HTTPS
Point Cocoa Packet Analyzer at a key log, or let the built-in proxy handle it. Encrypted rows become HTTPS, HTTP/2 and HTTP/3 with headers, bodies and request–response pairs, and gRPC calls show each message field by field.
Debug your API
The proxy monitor lists every request live, with the app it came from. Export the session as HAR, or copy any request as cURL and replay it from Terminal.
Open a capture
Double-click any pcap or pcapng. Quick Look previews it in Finder, any field in the packet details becomes a filter with one click, and Follow Stream turns a conversation back into readable text — on traces with hundreds of thousands of flows too.
Write its analyzer in Swift with the Plugin SDK. Your plugin gets the same detail tree, filters, columns and Follow windows as the built-in ones, and its settings appear under Settings ▸ Analyzer beside theirs.
CPAPluginSDK 4.1.0 · DocC walkthrough, an NTP sample and a TFTP sample with an Objective-C dissector. Plugins built with SDK 4.0.3 keep working; the README lists six signatures deprecated for SDK 5.0.0.
The download on this page does everything on it. Choose it if you want to capture traffic.
The Mac App Store version has everything except capturing: it opens, analyzes and filters pcap and pcapng files, follows streams, decrypts HTTPS from a key log or from a pcapng that carries its keys, and includes the MITM Proxy with its live monitor. The App Store’s rules exclude capturing, so it has no capture window, no menu bar capture and no Record processes. It also cannot change your Mac’s network settings, so you point your Mac at the proxy yourself, following the instructions in the app.
Both are free.
The Ethernet and Wi-Fi interfaces that come with your Mac work out of the box.
Ethertypes: ARP, IP (v4/v6), PPP, PPPoED/S, 802.1Q VLAN, MPLS, LLDP
Link types: Loopback, PPP, LinuxSLL, IEEE 802.11 RadioTap, pktap (with the process behind each packet)
Link and framing: Ethernet, ARP, LLDP, 802.1Q VLAN, MPLS, PPP, PPPoE (Discovery and Session), LinuxSLL, IEEE 802.11 RadioTap, Loopback
Network: IP (v4/v6), ICMP (v4/v6), IGMP, OSPF, Mobility, ESP
Transport and tunneling: TCP, UDP, QUIC, L2TP, MPLS-in-IP, HTTP CONNECT proxy tunnels
Encryption: TLS, decrypted with TLS keys (also inside QUIC)
PPP control: LCP, IPCP (v4/v6), CCP, PAP, CHAP
Application: HTTP (1.1 and 2), HTTP/3, WebSocket, DNS, DHCP (v4/v6), FTP, SMTP, POP3, IMAP, NNTP, SSH, Telnet, SIP, IAX, SNMP, LDAP, BGP, RADIUS, SMB, SOAP, Hotline
Yes. Turn it on when you start a capture. Most interfaces in a Mac support it.
Monitor mode captures wireless packets without joining an access point or ad hoc network first. It applies to Wi-Fi only, and not every Wi-Fi interface supports it. Turn it on when you start a capture.
Monitor and promiscuous mode do not work together; choose one.
Captured HTTPS is encrypted. From the packets alone you can see that your Mac talked to a host, when, and how much — but not a word of what was said. That is HTTPS working as intended, and no amount of analysis undoes it after the fact.
The proxy solves it by standing in the middle, with your permission. It runs locally, mints its own certificate authority, and asks macOS to route your web traffic through it. To your browser it looks like the far end; to the far end it looks like your browser. Because it terminates each connection itself, it holds the keys — so it can show you every request and response as plain text, and hand those keys to the analyzer so your captured packets decrypt too.
“MITM” is man-in-the-middle, normally the name of an attack. This is the same technique aimed at your own machine, and only while you switch it on: you have to trust its certificate, your previous proxy settings are restored when you stop, and nothing leaves your Mac. (In the Mac App Store version you set the proxy up yourself, following the instructions in the app.) While it is running it can read the HTTPS of every app that uses the system proxy — so turn it off when you are done, and only inspect traffic you are entitled to.
A key log is a small text file that writes down the secret each encrypted connection used, so a capture can be read afterwards.
When a browser opens an HTTPS connection it negotiates a fresh secret with the server. Nobody watching the wire can work it out — that is the whole design. But both ends know it, and either end is free to write it down. A key log is exactly that: one line per session, linking a connection to its secret. Most browsers will produce one if you set the SSLKEYLOGFILE environment variable before launching them.
Point Cocoa Packet Analyzer at that file and the matching sessions decrypt — a capture you recorded weeks ago suddenly reads as ordinary requests and replies. The packets never change; you have simply supplied the missing piece.
Keys reach CPA three ways: the proxy records them automatically while it runs, you can add a key log yourself in the TLS Keys window, under Sources, and a pcapng file can carry its keys inside the trace — so a keyed capture stays readable when you archive it or send it to a colleague.
Keys are as sensitive as the traffic they open. CPA keeps them in a key store tied to the trace they belong to, and the TLS Keys window lists every session in a capture, which ones decrypt, and for the rest, plainly why not.
No. The proxy is the convenient route — switch it on, capture, and decryption just happens — but it is not the only one.
If you already have a key log, or a pcapng trace that carries its own keys, CPA decrypts from those alone. That matters for traffic the proxy could never sit in front of: a capture from another machine, a trace a colleague sent you, or an app that ignores the system proxy setting.
Your traces and keys do not. The only thing Cocoa Packet Analyzer sends on its own is the update check, and that is opt-in, as is the anonymous system profile that can go with it.
Download the Plugin SDK. Its SamplePlugIn/CPAPluginSDK.docc/ catalog walks you through it (WritingYourFirstPlugin, ProtocolContract, ThreadingModel, DistributingYourPlugin), and the included NTPAnalyzer-XCF Xcode project is a complete analyzer you can build and ship as a .cpaplugin bundle; TFTPAnalyzer-ObjC shows the same with the dissector in Objective-C (UsingObjectiveC). Questions welcome — get in touch.
macOS 26 or later; every version since 2.5.0 requires it. Macs on macOS 10.14.6 – 15.7.4 can stay on 2.1.4, below.
4.1.0 shows which app sent or received each packet — record it in a live capture, or open a pktap trace — with an Applications window that counts along. Capture windows now run side by side, any field in the packet details can be a filter condition, decrypted HTTP/2 reads as HTTPS with gRPC calls decoded, LLDP joins the analyzers, and pinned traces stay at the top of the sidebar. Release notes
