Wireshark tutorial for beginners
Wireshark can look intimidating, like a dashboard straight out of The Matrix. But once you understand the basics, you can use it to see exactly what's happening on your network.
Everything your computer sends or receives over a network (loading a webpage, sending an email, streaming a video) gets broken into small chunks called packets. Each packet contains the data being sent plus addressing information: where it came from and where it's going. Wireshark captures these packets and lets you inspect every one of them.
Packets follow protocols, which are standardized rules that computers agree on for communication. You'll see a few of these constantly in Wireshark:
- TCP handles reliable delivery. It makes sure data arrives in order and retransmits anything that gets lost.
- HTTP carries web pages and API calls. The content is readable plain text.
- TLS encrypts connections. When you see
https://in your browser, TLS is what makes it secure. - DNS translates domain names like
example.cominto IP addresses like93.184.216.34.
You don't need to memorize these. They'll make more sense once you see them in a real capture.
Installation
Download Wireshark for free from wireshark.org. It's open source and available for Windows, macOS, and Linux.
Important for Windows users: During installation, you must agree to install Npcap (or WinPcap in older versions). This is the driver that allows your network card to capture live traffic. Without it, Wireshark can't do anything useful.
Choosing an interface
When you first open Wireshark, you'll see a list of your computer's network interfaces.
Look for the interface with a squiggly line (a small heartbeat graph) next to it. That indicates traffic is actively flowing through that connection. For most users, this will be either Wi-Fi (often shown as "Wi-Fi" or "en0" on macOS) or Ethernet (more stable, but less common on laptops).
Double-click your active interface to start capturing immediately.
Your first capture
The moment you start capturing, packets will flood the screen. This is normal. Your computer is constantly sending and receiving traffic in the background even when you're not doing anything.
The first thing to do is hit the red square (Stop) button in the toolbar. This freezes the packet list so you can actually read it. A few seconds of capture gives you plenty to work with.
| No. | Time | Source | Destination | Protocol | Length | Info |
|---|---|---|---|---|---|---|
| 1 | 0.000000 | 192.168.1.100 | 93.184.216.34 | TCP | 74 | 49234 → 443 [SYN] Seq=0 Win=65535 |
| 2 | 0.023451 | 93.184.216.34 | 192.168.1.100 | TCP | 74 | 443 → 49234 [SYN, ACK] Seq=0 Ack=1 Win=65535 |
| 3 | 0.023512 | 192.168.1.100 | 93.184.216.34 | TCP | 66 | 49234 → 443 [ACK] Seq=1 Ack=1 Win=65535 |
| 4 | 0.045123 | 192.168.1.100 | 93.184.216.34 | TLSv1.3 | 583 | Client Hello |
| 5 | 0.089234 | 93.184.216.34 | 192.168.1.100 | TLSv1.3 | 1514 | Server Hello, Certificate, ... |
| 6 | 0.156789 | 192.168.1.100 | 93.184.216.34 | HTTP | 412 | GET /index.html HTTP/1.1 |
| 7 | 0.189234 | 93.184.216.34 | 192.168.1.100 | HTTP | 1280 | HTTP/1.1 200 OK (text/html) |
| 8 | 0.250100 | 192.168.1.100 | 8.8.8.8 | DNS | 74 | Standard query A api.example.com |
| 9 | 0.278345 | 8.8.8.8 | 192.168.1.100 | DNS | 90 | Standard query response A api.example.com A 203.0.113.50 |
| 10 | 0.350200 | 192.168.1.100 | 198.51.100.77 | TCP | 1514 | 51234 → 8443 [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=1460 |
| 11 | 0.412567 | 198.51.100.77 | 192.168.1.100 | TCP | 66 | 8443 → 51234 [ACK] Seq=1 Ack=1461 Win=65535 |
The Wireshark interface
Now that you have a stopped capture with packets to look at, the interface has three main panes:
| No. | Time | Source | Destination | Protocol | Length | Info |
|---|---|---|---|---|---|---|
| 1 | 0.000000 | 192.168.1.100 | 93.184.216.34 | TCP | 74 | 49234 → 443 [SYN] Seq=0 Win=65535 |
| 2 | 0.023451 | 93.184.216.34 | 192.168.1.100 | TCP | 74 | 443 → 49234 [SYN, ACK] Seq=0 Ack=1 Win=65535 |
| 3 | 0.023512 | 192.168.1.100 | 93.184.216.34 | TCP | 66 | 49234 → 443 [ACK] Seq=1 Ack=1 Win=65535 |
| 4 | 0.045123 | 192.168.1.100 | 93.184.216.34 | TLSv1.3 | 583 | Client Hello |
| 5 | 0.089234 | 93.184.216.34 | 192.168.1.100 | TLSv1.3 | 1514 | Server Hello, Certificate, ... |
| 6 | 0.156789 | 192.168.1.100 | 93.184.216.34 | HTTP | 412 | GET /index.html HTTP/1.1 |
| 7 | 0.189234 | 93.184.216.34 | 192.168.1.100 | HTTP | 1280 | HTTP/1.1 200 OK (text/html) |
| 8 | 0.250100 | 192.168.1.100 | 8.8.8.8 | DNS | 74 | Standard query A api.example.com |
| 9 | 0.278345 | 8.8.8.8 | 192.168.1.100 | DNS | 90 | Standard query response A api.example.com A 203.0.113.50 |
| 10 | 0.350200 | 192.168.1.100 | 198.51.100.77 | TCP | 1514 | 51234 → 8443 [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=1460 |
| 11 | 0.412567 | 198.51.100.77 | 192.168.1.100 | TCP | 66 | 8443 → 51234 [ACK] Seq=1 Ack=1461 Win=65535 |
1. Packet list (top pane)
This scrolling list shows all captured packets. Each row is one packet with columns for its sequence number (No.), capture time (Time), the source and destination IP addresses, the protocol it uses (TCP, HTTP, DNS, etc.), the packet size in bytes (Length), and a human-readable summary (Info).
Look at the Source and Destination columns. You'll notice 192.168.1.100 appears frequently. Addresses starting with 192.168.x.x are private addresses, meaning that's the local machine (your computer). The other addresses like 93.184.216.34 are public addresses, remote servers out on the internet.
2. Packet details (middle pane)
When you click a packet, this pane shows its internal structure as a collapsible tree. Each section represents a layer of the network stack. Frame contains physical layer info like total packet size and capture time. Ethernet II shows MAC addresses for hardware-level addressing. Internet Protocol holds the IP addresses and TTL. TCP or UDP shows ports, sequence numbers, and flags. At the top, application data holds the actual content: HTTP requests, DNS queries, TLS handshakes, and so on.
Click on a packet above and expand the Transmission Control Protocol section. Wireshark resolves port numbers for you, so port 443 shows as 443 (https), port 80 as 80 (http), and port 53 as 53 (dns). Ports identify which service on a machine the packet is meant for. A server runs its web service on port 80 (HTTP) or 443 (HTTPS), its DNS service on port 53, and so on.
3. Packet bytes (bottom pane)
The raw hexadecimal dump of the packet. You can mostly ignore this unless you're doing deep forensic analysis.
The TCP handshake
Look at the first three packets in the demo above. They show the TCP three-way handshake. Before any data can be sent over TCP, the two machines must establish a connection:
- Your computer sends a SYN (synchronize) to the server. "I want to connect."
- The server responds with SYN, ACK (synchronize + acknowledge). "I acknowledge your request, and I'm ready too."
- Your computer sends an ACK (acknowledge). "Got it, let's go."
You can see this in the Info column: [SYN], then [SYN, ACK], then [ACK]. Click on each packet and look at the TCP flags in the details pane.
Only after this handshake completes can actual data flow. Packets 4-5 are a TLS handshake (setting up encryption), and packets 6-7 are an HTTP request and response. Every TCP connection you see in Wireshark started with this same three-step dance.
Color coding
The packets have different background colors. Wireshark automatically color-codes traffic to help you quickly scan what's happening:
| No. | Time | Source | Destination | Protocol | Length | Info |
|---|---|---|---|---|---|---|
| 1 | 0.000000 | 192.168.1.100 | 93.184.216.34 | TCP | 74 | 49234 → 443 [SYN] Seq=0 Win=65535 |
| 2 | 0.023451 | 93.184.216.34 | 192.168.1.100 | TCP | 74 | 443 → 49234 [SYN, ACK] Seq=0 Ack=1 Win=65535 |
| 3 | 0.023512 | 192.168.1.100 | 93.184.216.34 | TCP | 66 | 49234 → 443 [ACK] Seq=1 Ack=1 Win=65535 |
| 4 | 0.045123 | 192.168.1.100 | 93.184.216.34 | TLSv1.3 | 583 | Client Hello |
| 5 | 0.089234 | 93.184.216.34 | 192.168.1.100 | TLSv1.3 | 1514 | Server Hello, Certificate, ... |
| 6 | 0.156789 | 192.168.1.100 | 93.184.216.34 | HTTP | 412 | GET /index.html HTTP/1.1 |
| 7 | 0.189234 | 93.184.216.34 | 192.168.1.100 | HTTP | 1280 | HTTP/1.1 200 OK (text/html) |
| 8 | 0.250100 | 192.168.1.100 | 8.8.8.8 | DNS | 74 | Standard query A api.example.com |
| 9 | 0.278345 | 8.8.8.8 | 192.168.1.100 | DNS | 90 | Standard query response A api.example.com A 203.0.113.50 |
| 10 | 0.350200 | 192.168.1.100 | 198.51.100.77 | TCP | 1514 | 51234 → 8443 [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=1460 |
| 11 | 0.412567 | 198.51.100.77 | 192.168.1.100 | TCP | 66 | 8443 → 51234 [ACK] Seq=1 Ack=1461 Win=65535 |
Light purple rows are TCP packets (connection handshakes, acknowledgments). Light green rows are HTTP traffic (unencrypted web requests). Light blue rows are DNS queries and TLS traffic (encrypted connection setup).
In real Wireshark captures, you'll also see black or red rows. These indicate problems like TCP retransmissions, dropped packets, or errors. When troubleshooting, those are often where you'll find the issue.
Display filters
With 11 packets the demo is manageable, but a real capture can contain thousands. Filters let you narrow down to what matters. Type a filter in the bar below and click Apply (or press Enter):
| No. | Time | Source | Destination | Protocol | Length | Info |
|---|---|---|---|---|---|---|
| 1 | 0.000000 | 192.168.1.100 | 93.184.216.34 | TCP | 74 | 49234 → 443 [SYN] Seq=0 Win=65535 |
| 2 | 0.023451 | 93.184.216.34 | 192.168.1.100 | TCP | 74 | 443 → 49234 [SYN, ACK] Seq=0 Ack=1 Win=65535 |
| 3 | 0.023512 | 192.168.1.100 | 93.184.216.34 | TCP | 66 | 49234 → 443 [ACK] Seq=1 Ack=1 Win=65535 |
| 4 | 0.045123 | 192.168.1.100 | 93.184.216.34 | TLSv1.3 | 583 | Client Hello |
| 5 | 0.089234 | 93.184.216.34 | 192.168.1.100 | TLSv1.3 | 1514 | Server Hello, Certificate, ... |
| 6 | 0.156789 | 192.168.1.100 | 93.184.216.34 | HTTP | 412 | GET /index.html HTTP/1.1 |
| 7 | 0.189234 | 93.184.216.34 | 192.168.1.100 | HTTP | 1280 | HTTP/1.1 200 OK (text/html) |
| 8 | 0.250100 | 192.168.1.100 | 8.8.8.8 | DNS | 74 | Standard query A api.example.com |
| 9 | 0.278345 | 8.8.8.8 | 192.168.1.100 | DNS | 90 | Standard query response A api.example.com A 203.0.113.50 |
| 10 | 0.350200 | 192.168.1.100 | 198.51.100.77 | TCP | 1514 | 51234 → 8443 [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=1460 |
| 11 | 0.412567 | 198.51.100.77 | 192.168.1.100 | TCP | 66 | 8443 → 51234 [ACK] Seq=1 Ack=1461 Win=65535 |
Some filters to try:
tcpshows only TCP packets (handshakes, data transfer, acknowledgments)httpshows only HTTP traffic (unencrypted web requests and responses)dnsshows DNS queries and responses (domain name lookups)TLSv1.3shows TLS handshake packets (encrypted connection setup)8.8.8.8filters by IP address (Google's DNS server, in this case)198.51.100.77finds traffic to an unfamiliar IP
The filter bar turns green when your syntax is valid. In real Wireshark, you can also use expressions like ip.addr == 192.168.1.100 or tcp.port == 443.
Reading HTTP traffic
If a website uses unencrypted HTTP (not HTTPS), you can read everything in plain text. Filter for http in the demo above and click on packet 6 (the GET request). Expand the Hypertext Transfer Protocol section in the details pane. You'll see the request method, host, and path.
Now click packet 7, the server's response with status code 200. In a real capture with POST requests (form submissions), you'd see usernames and passwords in plain text. This is why HTTPS matters.
Follow TCP stream
Individual packets only show fragments of a conversation. Follow TCP Stream reconstructs the entire exchange between two machines in reading order.
| No. | Time | Source | Destination | Protocol | Length | Info |
|---|---|---|---|---|---|---|
| 1 | 0.000000 | 192.168.1.100 | 93.184.216.34 | TCP | 74 | 49234 → 443 [SYN] Seq=0 Win=65535 |
| 2 | 0.023451 | 93.184.216.34 | 192.168.1.100 | TCP | 74 | 443 → 49234 [SYN, ACK] Seq=0 Ack=1 Win=65535 |
| 3 | 0.023512 | 192.168.1.100 | 93.184.216.34 | TCP | 66 | 49234 → 443 [ACK] Seq=1 Ack=1 Win=65535 |
| 4 | 0.045123 | 192.168.1.100 | 93.184.216.34 | TLSv1.3 | 583 | Client Hello |
| 5 | 0.089234 | 93.184.216.34 | 192.168.1.100 | TLSv1.3 | 1514 | Server Hello, Certificate, ... |
| 6 | 0.156789 | 192.168.1.100 | 93.184.216.34 | HTTP | 412 | GET /index.html HTTP/1.1 |
| 7 | 0.189234 | 93.184.216.34 | 192.168.1.100 | HTTP | 1280 | HTTP/1.1 200 OK (text/html) |
| 8 | 0.250100 | 192.168.1.100 | 8.8.8.8 | DNS | 74 | Standard query A api.example.com |
| 9 | 0.278345 | 8.8.8.8 | 192.168.1.100 | DNS | 90 | Standard query response A api.example.com A 203.0.113.50 |
| 10 | 0.350200 | 192.168.1.100 | 198.51.100.77 | TCP | 1514 | 51234 → 8443 [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=1460 |
| 11 | 0.412567 | 198.51.100.77 | 192.168.1.100 | TCP | 66 | 8443 → 51234 [ACK] Seq=1 Ack=1461 Win=65535 |
Right-click on packet 6 (the HTTP GET request, in green) and select TCP Stream from the menu. You'll see the full HTTP conversation. Blue text is what your machine (the client) sent. Red text is what the server sent back.
You can read the complete HTML response the server returned. Instead of piecing together dozens of individual packets, you see the entire conversation as a continuous document.
Right-click packet 1 (the TCP SYN) to see the TLS stream. The handshake data is unreadable because TLS is doing its job.
Network scanning with statistics
Instead of scrolling through individual packets, you can get a bird's-eye view of all network activity. Go to Statistics in the menu bar and select Conversations. This shows every pair of IP addresses that communicated, how many packets they exchanged, and how many bytes were transferred.
| No. | Time | Source | Destination | Protocol | Length | Info |
|---|---|---|---|---|---|---|
| 1 | 0.000000 | 192.168.1.100 | 93.184.216.34 | TCP | 74 | 49234 → 443 [SYN] Seq=0 Win=65535 |
| 2 | 0.023451 | 93.184.216.34 | 192.168.1.100 | TCP | 74 | 443 → 49234 [SYN, ACK] Seq=0 Ack=1 Win=65535 |
| 3 | 0.023512 | 192.168.1.100 | 93.184.216.34 | TCP | 66 | 49234 → 443 [ACK] Seq=1 Ack=1 Win=65535 |
| 4 | 0.045123 | 192.168.1.100 | 93.184.216.34 | TLSv1.3 | 583 | Client Hello |
| 5 | 0.089234 | 93.184.216.34 | 192.168.1.100 | TLSv1.3 | 1514 | Server Hello, Certificate, ... |
| 6 | 0.156789 | 192.168.1.100 | 93.184.216.34 | HTTP | 412 | GET /index.html HTTP/1.1 |
| 7 | 0.189234 | 93.184.216.34 | 192.168.1.100 | HTTP | 1280 | HTTP/1.1 200 OK (text/html) |
| 8 | 0.250100 | 192.168.1.100 | 8.8.8.8 | DNS | 74 | Standard query A api.example.com |
| 9 | 0.278345 | 8.8.8.8 | 192.168.1.100 | DNS | 90 | Standard query response A api.example.com A 203.0.113.50 |
| 10 | 0.350200 | 192.168.1.100 | 198.51.100.77 | TCP | 1514 | 51234 → 8443 [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=1460 |
| 11 | 0.412567 | 198.51.100.77 | 192.168.1.100 | TCP | 66 | 8443 → 51234 [ACK] Seq=1 Ack=1461 Win=65535 |
Click Statistics in the menu bar above, then select Conversations. The IPv4 tab shows three conversations:
- 192.168.1.100 ↔ 93.184.216.34 is the most active connection, your machine talking to example.com (both the HTTPS handshake and the HTTP request).
- 192.168.1.100 ↔ 8.8.8.8 is a DNS lookup. Your machine asked Google's DNS server to resolve a domain name. Small and expected.
- 192.168.1.100 ↔ 198.51.100.77 is the one to look at. Do you recognize this IP? It's sending a 1,514-byte packet to an unknown server. In a real investigation, an unrecognized destination warrants a closer look. You'd look up the IP, check what port it's using, and determine whether it's legitimate traffic.
In real captures, look for connections to IP addresses you don't recognize, large data transfers you didn't initiate (especially outbound), and connections to IPs in unexpected countries or regions. This view is how network analysts catch malware phoning home, unauthorized data exfiltration, or misconfigured applications leaking traffic.
Saving and exporting
Saving captures
Go to File → Save As to save your capture. Files are saved in .pcap or .pcapng format, which can be reopened in Wireshark later or shared with colleagues for analysis.
Exporting objects
For HTTP traffic, you can extract actual files that were transferred:
- Go to File → Export Objects → HTTP
- You'll see a list of images, scripts, HTML files, etc.
- Select files to save them to your computer
Full interface
Here's the complete Wireshark interface with all features enabled. Select packets, apply filters, right-click for TCP streams, and open Statistics → Conversations:
| No. | Time | Source | Destination | Protocol | Length | Info |
|---|---|---|---|---|---|---|
| 1 | 0.000000 | 192.168.1.100 | 93.184.216.34 | TCP | 74 | 49234 → 443 [SYN] Seq=0 Win=65535 |
| 2 | 0.023451 | 93.184.216.34 | 192.168.1.100 | TCP | 74 | 443 → 49234 [SYN, ACK] Seq=0 Ack=1 Win=65535 |
| 3 | 0.023512 | 192.168.1.100 | 93.184.216.34 | TCP | 66 | 49234 → 443 [ACK] Seq=1 Ack=1 Win=65535 |
| 4 | 0.045123 | 192.168.1.100 | 93.184.216.34 | TLSv1.3 | 583 | Client Hello |
| 5 | 0.089234 | 93.184.216.34 | 192.168.1.100 | TLSv1.3 | 1514 | Server Hello, Certificate, ... |
| 6 | 0.156789 | 192.168.1.100 | 93.184.216.34 | HTTP | 412 | GET /index.html HTTP/1.1 |
| 7 | 0.189234 | 93.184.216.34 | 192.168.1.100 | HTTP | 1280 | HTTP/1.1 200 OK (text/html) |
| 8 | 0.250100 | 192.168.1.100 | 8.8.8.8 | DNS | 74 | Standard query A api.example.com |
| 9 | 0.278345 | 8.8.8.8 | 192.168.1.100 | DNS | 90 | Standard query response A api.example.com A 203.0.113.50 |
| 10 | 0.350200 | 192.168.1.100 | 198.51.100.77 | TCP | 1514 | 51234 → 8443 [PSH, ACK] Seq=1 Ack=1 Win=65535 Len=1460 |
| 11 | 0.412567 | 198.51.100.77 | 192.168.1.100 | TCP | 66 | 8443 → 51234 [ACK] Seq=1 Ack=1461 Win=65535 |
What to look for
When analyzing captures, keep an eye out for these. Retransmissions indicate network congestion or packet loss. RST flags mean connections are being forcibly closed. Unknown destination IPs could signal unauthorized access or malware. Unencrypted credentials reveal security vulnerabilities in HTTP traffic. Unusually large transfers might point to data exfiltration.
Next steps
Want to practice with real traffic? Download Wireshark and try capturing on your own network. Start with simple filters like http or dns and gradually explore Statistics → Conversations and Follow TCP Stream.
The best way to learn Wireshark is to capture real traffic and explore. Now you know what you're looking at.