Free packet analyzer · Native for macOS 26
Cocoa Packet Analyzer captures network traffic, traces each packet back to the app that sent it, and shows HTTPS, HTTP/2 and HTTP/3 in plain text. It opens PCAP and PcapNG files from other tools, too. 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. Recording runs on pktap, a macOS pseudo-interface that tags each packet with its process, and a pktap trace opened from a file shows its apps the same way.
Decrypt HTTPS
Point Cocoa Packet Analyzer at a key log, open Chrome, Firefox or an Electron app with key logging switched on, 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 file. 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.2.0 · DocC walkthrough, an NTP sample and a TFTP sample with an Objective-C dissector. New: the Settings row icons for a plugin’s own settings, and produced bytes for an analyzer that decrypts its payload. Plugins built with SDK 4.0.3 or 4.1.0 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 file 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, RARP, IP (v4/v6), PPP, PPPoED/S, 802.1Q VLAN, MPLS, LLDP, Ethernet Loopback, and IEEE 802.3 frames with 802.2 LLC and SNAP
Link types: Loopback, PPP, LinuxSLL, Raw IP, Ethernet mPacket, IEEE 802.11 RadioTap, pktap (with the process behind each packet)
Link and framing: Ethernet, IEEE 802.2 LLC and SNAP, ARP and RARP, LLDP, Spanning Tree (STP, RSTP, MSTP, PVST+), Ethernet Loopback, 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
VPN and IPsec: IKE (v1 and v2), ESP, decrypted with your Mac’s own IPsec keys
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, LDP, 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.
Chrome, Firefox and Electron apps have a third way: File ▸ Open App with Key Logging… starts the app with key logging switched on, and its connections decrypt in a running capture.
Yes, for a VPN your own Mac is connected to. IKE, which sets the tunnel up, is read without keys: the proposals the two ends exchange and, when a setup is refused, the reason. The ESP packets inside the tunnel need the keys macOS holds for the connection.
While the VPN is up, save the output of sudo setkey -D to a file and choose it in Settings ▸ Analyzer ▸ ESP. ESP with AES-CBC then decrypts, and an L2TP/IPsec login shows its L2TP, LCP and CHAP in the packet list and in the Subscriber Session Inspector. A packet decrypts only when its integrity check verifies, and the keys stay in memory.
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.2.0 reads VPN connections: a new IKE analyzer, ESP decrypted with your Mac’s own IPsec keys, and IKE, ESP and L2TP on one ladder in the Subscriber Session Inspector. Chrome, Firefox and Electron apps decrypt without the proxy when you open them with key logging, Spotlight finds traces by host, protocol or app, Settings has a sidebar, and Spanning Tree, LDP and IEEE 802.3 frames with LLC join the analyzers. Release notes
