Reading your first Wireshark capture
Wireshark shows you every packet crossing your network interface. That sounds overwhelming until you know which three panes to look at and two or three filters to type.
Part of How computers talk to each other
Wireshark is a packet sniffer: it grabs the raw data moving across a network interface and shows it to you, packet by packet, decoded into something readable. Security folks use it to debug connections, hunt for suspicious traffic, and understand protocols by watching them happen instead of just reading about them.
The learning curve looks steep because the window is dense. It isn’t, really — you only need to understand three panes and a handful of filters to get real value out of your first capture.
Before you capture anything
Only capture traffic on a network you own or have permission to monitor — your home network or a lab environment you’ve set up for this. Capturing someone else’s traffic without permission is not okay, even out of curiosity.
The easiest safe target is your own machine generating its own traffic: open Wireshark, start a capture on your active interface (Wi-Fi or Ethernet), then visit a plain http:// site (not https://) in another window. HTTP is unencrypted, so you’ll actually be able to read what’s inside the packets, which makes this a good first exercise.
The three panes
Once a capture is running, the window splits into three stacked panes. Learn what each one is for and the rest starts to make sense.
1. Packet list
The top pane is a table, one row per packet, in the order it arrived. Each row shows a number, a timestamp, source and destination address, the protocol, and a short info summary. Wireshark colors rows by protocol — light purple for TCP, light blue for HTTP, and so on — so patterns become visible just by scrolling.
2. Packet details
Click a row and the middle pane shows that packet broken into layers, like nested folders: Frame, then Ethernet, then IP, then TCP, then whatever protocol sits on top (HTTP, DNS, etc). Each layer can be expanded to see its individual fields — source port, flags, sequence numbers, headers.
3. Bytes pane
The bottom pane shows the same packet as raw hex and ASCII, side by side. Click a field in the details pane above and Wireshark highlights the exact bytes it came from. This is where “the packet” stops being an abstraction and becomes the literal bytes that traveled the wire.
No. Time Source Destination Protocol Info
142 3.011021 192.168.1.14 93.184.216.34 TCP 54812 → 80 [SYN]
143 3.041887 93.184.216.34 192.168.1.14 TCP 80 → 54812 [SYN, ACK]
144 3.042010 192.168.1.14 93.184.216.34 TCP 54812 → 80 [ACK]
145 3.042655 192.168.1.14 93.184.216.34 HTTP GET / HTTP/1.1
146 3.098410 93.184.216.34 192.168.1.14 HTTP HTTP/1.1 200 OKA simplified packet list. Rows 142–144 are the TCP handshake; row 145 is the actual HTTP request going out.
What you’re seeing: before any data moves, TCP does a three-way handshake — SYN, SYN-ACK, ACK — to open a connection. Only after that does the HTTP request in row 145 actually get sent. This pattern (handshake, then payload) repeats for almost every TCP-based protocol, including HTTPS.
Filtering the noise
A real capture, even a short one, can have thousands of packets: background chatter from your OS, other apps phoning home, broadcast traffic from other devices on the network. The filter bar at the top of the window is how you cut through that.
Type a filter and press Enter; Wireshark hides everything that doesn’t match. These four cover most of what you’ll need starting out:
| Filter | Shows |
|---|---|
http | Only HTTP requests and responses |
ip.addr == 93.184.216.34 | Only packets to or from that address |
tcp.port == 443 | Only traffic on port 443 (usually HTTPS) |
dns | Only DNS lookups, showing which domains were resolved |
Filters can be combined with && (and) and || (or) — for example, http && ip.addr == 93.184.216.34 narrows to HTTP traffic with just that one host.
Following a stream
Right-click any TCP or HTTP packet and choose Follow → TCP Stream. Wireshark reassembles every packet belonging to that one conversation and shows it as readable text, with your side and the server’s side in different colors. For an HTTP request, this is the fastest way to see the full request headers and the full response — no manual reassembly needed.
This is also the feature that makes clear why HTTPS matters: try the same thing on an HTTPS connection and the stream is unreadable ciphertext instead of plain headers and HTML.
What to try
- Start a capture, visit an
http://site, stop the capture, and filter withhttp. - Find the
GETrequest, follow its TCP stream, and read the full request and response headers. - Filter with
dnsand watch which domains your machine looked up just from loading one page. - Compare an HTTP stream to an HTTPS stream on the same site, if it offers both.
None of this requires memorizing anything. The goal for a first capture is just to stop finding the window intimidating — once the three panes and a couple of filters feel familiar, reading real traffic gets a lot faster.
Want to practice on a real capture?
The practice section has a short lab with a pre-made capture file to explore, plus a few questions to check what you found.
Cipherora is a free place to learn security. Only try these techniques on systems you own or have written permission to test.