When I first opened Wireshark, I was 20 years old, in a computer lab at the university, and I didn’t know what I was looking at. My networking professor had instructed us to take a 5 minute capture and “Describe what you see. I hit the green shark fin icon, chose my Ethernet interface and saw hundreds of lines flash by faster than I could read. Every line was a packet, a small bit of information coming or going from my machine, with a source address, a destination address, a protocol, and a length. More than 12 thousand packets were generated in 5 minutes. I opened Chrome once and checked my email. That was it. 12,000 packets per browser tab and an inbox that has 3 unread messages. I sat there and thought, my computer was talking to people I didn’t know about, DNS lookups, TCP handshakes, TLS negotiations, ARP broadcasts, a thing called NBNS that I had to look up later, SSDP discovery. It was akin to opening the hood of a car for the first time and finding the engine much more complicated than the steering wheel indicated.
That was 2013. I’ve been using Wireshark on and off ever since, and I still don’t feel totally comfortable with it, the idea that my machine is talking to all sorts of other machines without my permission, but I’m also fascinated by it, how it all works at the wire level.
Wireshark was originally called Ethereal, and was developed in 1998 by Gerald Combs, who was employed by an internet service provider and required a program to help him solve network issues. In 2006, he changed its name to Wireshark because of trademark problems with his previous employer. It’s open-source, totally free, available for Windows, macOS, Linux and more, and has been the de facto standard network protocol analyzer for more than 20 years. Whether you are in IT, network engineering, cybersecurity, or software development, you either use Wireshark or know someone who does. It is not a knowledge that can be omitted in those fields. It is foundational.
It is easy to install without pain. The installer contains Npcap, the packet capture driver that enables Wireshark to capture raw network traffic on Windows, and you’re up and running in less than three minutes. On Linux, it is typically a single package manager command. On Mac, a DMG drag and drop. There is no account creation, no license key, no telemetry opt-in, no trial period. You install it and it works. Wireshark’s setup is so silent and efficient that it seems disrespectful to the norm after years of software that uses the installation process as a marketing opportunity.
The interface, though. The interface is the place new users either persevere or quit. Wireshark’s main window consists of three panes. The top pane is the packet list, with each captured packet on a line, color coded by protocol. The middle pane is the packet detail, a tree view that dissects the selected packet, layer by layer, from the Ethernet frame to the IP header to the TCP segment to the application payload. The bottom pane is the raw hex dump — the actual bytes, in hex on the left, and ASCII on the right. This layout is efficient and information dense if you know what you’re looking for. If you don’t know what you’re searching for, it appears like the Matrix. No onboarding wizard is available. The application does not have a “start here” guide. Wireshark expects you to understand what a protocol is, what a packet is, and why you might want to view a packet. Otherwise, the learning curve is not steep, it’s vertical for the first few hours.
However, there is a Wireshark secret that makes it worth the effort: When you master the display filters, the whole application becomes unlocked. Display filters are the way to tell Wireshark that you want to see only the packets you are interested in. `http` will display only HTTP traffic. `ip.addr == 192.168.1.1` will display only traffic to or from a specific device. `tcp.port == 443` will display only HTTPS connections. `dns && ip.src == 10.0.0.5` will display only DNS requests from a specific machine. The filter language is very deep and very precise: you can filter on the length of the packet, on the TCP flags, on the presence of a domain name in a TLS certificate, on the content of a particular byte at a particular offset, etc. I once found a rogue IoT camera that was communicating with a server in a country it wasn’t supposed to be communicating with. The filter was `ip.src == 192.168.1.47 && !(ip.dst == 192.168.1.0/24)` — show me everything leaving the camera that is not going to my local network. Fourteen packets in two minutes, all to the same IP address in Shenzhen. I removed the camera and never plugged it in again.
That’s the story Wireshark is for. Not for light use. Not for those who wish to have green checkmarks on their dashboard, indicating that their network is healthy. Wireshark is for when something is going wrong and you need to see what is going on the wire. A website is not loading — is the DNS resolving? Does the TCP connection complete? Does the server return an error? An application is slow — is there packet loss? Are retransmissions happening? Is TCP window scaling working properly? A device is behaving suspiciously — where is it sending data? How often? How much? No monitoring dashboard can answer these questions as accurately as by looking at the actual packets. Wireshark does not interpret. It does not guess. It reveals to you what occurred, in the order that it occurred, right down to the microsecond.
The protocol support is astounding. Wireshark supports the dissection of more than 3000 protocols. Not only the common ones (TCP, UDP, HTTP, DNS, DHCP) but also industrial protocols (Modbus, DNP3), VoIP protocols (SIP, RTP), database protocols (MySQL, PostgreSQL), IoT protocols (MQTT, CoAP), automotive protocols (CAN bus). If data is being transmitted over a network, and someone has written a dissector for it, Wireshark can read it. I have used it once to troubleshoot a Modbus TCP communication between a PLC and a SCADA system in a small factory. The control engineer had been working on the problem for two days. I recorded traffic for 10 minutes, filtered for Modbus, and saw that the PLC was returning exception code 0x02 (illegal data address) for every third request. There was a mistake in the register map in the SCADA configuration. One incorrect number in one field. Two days of downtime due to a digit. Wireshark was able to find it in 10 minutes because it could tell me exactly what Modbus response codes the PLC was sending.
The “Follow TCP Stream” is one of the most useful features in any software I have ever used. Right click on any packet in a TCP connection, choose “Follow TCP Stream” and Wireshark will recreate the entire conversation between the client and server in a readable window. In the case of unencrypted protocols, this means that you can see the entire HTTP request and response, the entire SMTP email exchange, the complete FTP command sequence. I used this in a university project to find out what my browser was sending to a web server: user agent, cookies, referrer, accepted encoding, etc., and it was the first time that I really understood how HTTP works. Not from a book. From observing the actual bytes sent by my machine and the actual bytes returned by the server. Nothing beats that kind of knowledge.
In 2026, of course, most traffic of interest is encrypted. HTTPS is everywhere. Passive decryption is almost impossible with TLS 1.3. The problem with an encrypted connection is that you can’t just capture packets and read the contents: you see the TLS handshake, you see the certificate exchange, and then you see encrypted application data, which could be random noise. If you have the session keys, you can use Wireshark to decrypt TLS traffic; browsers can export the keys to a log file by setting an environment variable called SSLKEYLOGFILE. I use this all the time to debug web applications: I set the variable, start Firefox, capture traffic and Wireshark automatically decrypts the HTTPS sessions with the key log. It’s working great and it shows the complete exchange of HTTP/2 or HTTP/3 under the encryption. However, this only applies to traffic from your own machine where you have control of the browser. Encryption for traffic from other devices on the network means that Wireshark will display the envelope, but not the letter inside.
Large captures have been a problem with performance. Wireshark stores the whole capture file into memory, so a 500 MB pcap file will take up a lot of RAM and take a few seconds to open. A 2 GB capture, which can be easily created in a few minutes on a busy network, can cause the application to become sluggish, and complex display filters on a large capture can cause the display to freeze for 10 to 15 seconds. The command-line companion tool, tshark, is better with large files because it doesn’t need to display a GUI, and for serious analysis on multi-gigabyte captures, most of the people I know use tshark to pre-filter the data and then open the smaller result in Wireshark. This is a limitation in the workflow that has been around for years and the development team has been working on it for years, but never got it right. Wireshark’s large file handling is slower than commercial products such as Omnipeek or Savvius. Those tools are thousands of dollars and Wireshark is free, so I can deal with a ten second filter delay.
The statistics menu is under-used by most people, including me for the first few years. Protocol hierarchy gives you a breakdown of all traffic by protocol, instantly answering the question “what is using my bandwidth. Conversations displays all pairs of communicating endpoints sorted by the amount of data. IO Graphs can display traffic over time, and can be overlaid with multiple filters for pattern comparisons. Expert Information highlights potential issues, such as retransmissions, out-of-order packets, duplicate ACKs, zero window events, and displays them in a table that can be sorted. I have used Expert Information to solve more performance problems than any other way. A seemingly normal network will be filled with hundreds of TCP retransmissions underneath, which will add up to the “it just feels slow” complaint that no ping test will ever show.
I should add the ethical aspect because it’s easy to get traffic that isn’t yours with Wireshark. If you are on a shared network (a coffee shop, a university, a poorly segmented corporate LAN), then you can put your interface into promiscuous mode and Wireshark will see the traffic from other devices. That is the way that passwords were stolen prior to the use of encryption. That’s why in some circles Wireshark is referred to as a “hacking tool,” and that’s like saying a kitchen knife is a weapon — it’s true, but it’s not really. Wireshark is a diagnostic application. It captures packets. It is up to you what you do with those packets. In most jurisdictions, it is illegal to capture traffic on a network that you don’t own or have explicit permission to monitor. Wireshark will not prevent you from doing this. It also won’t prevent you from slicing yourself with a kitchen knife. It’s up to you.
I still use Wireshark at least once a month. In some cases to troubleshoot a connection problem. Occasionally to ensure that a firewall rule is functioning properly. Sometimes just for the heck of it — I’ll just grab five minutes of idle traffic from my home network to see what my smart devices are up to when they think no one is watching. The answer is always, more than you think. The smart TV phones home to three different analytics services. The thermostat communicates with its cloud server every 90 seconds. I’ve never been able to fully decode the telemetry from the robot vacuum. None of this is addressed by Wireshark. It simply displays it to you. Sometimes, it’s all about knowing.
It is ugly. It is intimidating. It will take you a few weeks to get the hang of the learning curve. However, Wireshark is the one most educational software I have ever used. There is no better way to learn about networks than to see your own packets moving around on the wire. All the networking books I read in university were clearer after seeing the concepts in action. All the “it just works” technologies, Wi-Fi, DNS, HTTPS, streaming video, were demystified and became mechanical when I could see the individual parts. Networking is not easy with Wireshark. It puts networking into perspective. Once you have it, visibility is something you don’t want to lose.
