Wireshark Display Filters: 25 Essential Filters for Beginners

Wireshark display filters let you hide packet noise and show only the traffic that matches what you are investigating. Instead of scrolling through thousands of frames, you can isolate a protocol, IP address, subnet, port, DNS query, HTTP request, TLS handshake, or TCP problem with a short filter expression.

I think this is the point where Wireshark finally starts feeling useful instead of looking like a spreadsheet designed by a shark with insomnia. The capture itself is only the raw material. The real skill is knowing what to ask of it. These are the 25 powerful filters to know when you are learning packet analysis, and I use the same logic in my own isolated lab when I want to move from “there is traffic” to “this packet is the one I actually care about.”

If practical network analysis, lab notes, and security testing are your kind of rabbit hole, you can join my HackersGhost newsletter. I keep it focused on things I can explain, test, or reproduce myself, rather than sending you another inbox-shaped pile of noise.

What you want to isolate	Example filter	Why it helps
One protocol	dns	Removes unrelated packet noise
One host	ip.addr == 192.168.20.10	Shows traffic to or from one IP
One service	tcp.port == 443	Focuses on a TCP port
TCP trouble	tcp.analysis.retransmission	Surfaces suspected retransmissions
Web requests	http.request	Shows HTTP requests only

Key Takeaways

• Wireshark display filters do not delete packets from a capture; they control which captured packets you see.
• The most useful beginner filters start with protocols, IP addresses, ports, DNS, HTTP, TLS, and TCP analysis.
• A good Wireshark filter by IP can turn a noisy lab capture into one readable conversation within seconds.
• Subnet and range filters are especially useful when you are analyzing several VMs or devices at once.
• TCP analysis filters can point you toward retransmissions, duplicate ACKs, resets, and new connection attempts without manually inspecting every frame.
• This is a practical Wireshark display filters cheat sheet, but the goal is to understand why each filter is useful rather than memorize 25 lines of syntax like a particularly miserable school exam.

Capture Filter vs Display Filter: The Difference That Matters

Before getting into the 25 Wireshark display filters, there is one distinction worth learning properly. A display filter works on packets that have already been captured. It changes what Wireshark shows you, not what exists inside the capture file. Clear the filter and the hidden packets are still there.

A capture filter works earlier. It limits which packets Wireshark records in the first place. That can be useful on busy interfaces, but it also means a bad capture filter can throw away traffic you later discover you needed. For beginners, I usually prefer capturing a controlled lab session first and applying Wireshark filters afterward.

If the packet list itself still feels alien, my Wireshark for Beginners guide covers the broader packet-analysis basics before you go deeper into filter syntax.

The two systems also use different syntax. Wireshark explains its analyzer and filtering capabilities on the Wireshark homepage, while tcpdump is a useful reference point when you eventually start working with packet capture expressions outside the GUI. For this guide, everything below is a display filter.

Basic Wireshark Display Filters for Protocols

I start with protocol filters because they are the fastest way to make a capture less ridiculous. If you have ever opened Wireshark and watched ARP, DNS, TCP, UDP, TLS, ICMP, multicast traffic, background services, and assorted digital gossip arrive at once, you already know why.

1. TCP: tcp

tcp shows packets Wireshark has dissected as TCP. I use it to remove UDP and other chatter before looking at web sessions, SSH, file transfers, or connection problems. It is simple, but it is one of the Wireshark display filters I type most often.

2. UDP: udp

udp isolates UDP traffic. DNS often uses UDP, as do many discovery and real-time protocols. I use this as a clean starting point before narrowing by port or a more specific protocol.

3. DNS: dns

dns is one of my favorite beginner filters because DNS tells a story quickly. If a lab VM reaches for a domain, I want to know which name it asked for and what came back. That beats handing a beginner 8,000 packets and calling it a lesson.

4. ICMP: icmp

icmp is useful for ping traffic and network diagnostic messages. I often use it to confirm that two lab systems can reach each other before blaming Wireshark, VMware, the router, or the moon phase.

5. ARP: arp

arp shows Address Resolution Protocol traffic on the local network. In an isolated lab, I use it to see which MAC address is being resolved for an IPv4 address before the actual IP conversation begins.

6. HTTP: http

http shows traffic Wireshark recognizes as HTTP. Much of the modern web uses TLS, so not every website visit appears as readable HTTP. In simple lab applications it is still useful, and later I use a more precise Wireshark display filter HTTP example.

7. TLS: tls

tls isolates Transport Layer Security traffic. You will often see encrypted application data rather than readable content. That still lets you study endpoints, timing, handshake behavior, and connection patterns without expecting encrypted payloads to introduce themselves.

Wireshark for Beginners: 7 Brutal Packet Truths Your Network Is Hiding

Wireshark for Beginners: 7 Brutal Packet Truths Your Network Is Hiding 🪼

Wireshark Filter by IP: Hosts, Subnets, and Ranges

Once I know the protocol, my next move is usually a Wireshark filter by IP. This is where a capture starts becoming personal: instead of watching the entire network, I can follow one machine, one direction, one subnet, or a small block of addresses.

8. Any Traffic to or From One IP: ip.addr == 192.168.20.10

This Wireshark filter by IP matches packets where the address appears as either source or destination. Replace 192.168.20.10 with the host you are authorized to inspect, and every other device gets told to wait outside.

9. Source IP Only: ip.src == 192.168.20.10

ip.src is useful when I only care about traffic leaving a host. If a vulnerable VM initiates several connections, a source-only view makes its outbound behavior much easier to follow.

10. Destination IP Only: ip.dst == 192.168.20.10

ip.dst shows packets headed toward one host. I use it to separate incoming attempts from the replies a target VM generates. It is a simple way to start thinking in packet direction rather than one big conversation.

11. Wireshark Filter by IP Range Using CIDR: ip.addr == 192.168.20.0/24

If you need a Wireshark filter by IP range for a subnet, CIDR notation is clean. This example matches IPv4 traffic to or from 192.168.20.0/24, which is handy for watching one lab zone at a time.

12. A Specific IP Range: ip.addr in {192.168.20.10 .. 192.168.20.20}

Wireshark also supports membership sets and ranges. This example covers 192.168.20.10 through 192.168.20.20. I use it when the relevant systems sit inside a small block and I do not want the entire subnet.

Wireshark Display Filters for Ports

Ports are where protocol filtering becomes service filtering. A protocol tells me broadly what kind of transport I am looking at; a port often tells me which service or application path deserves attention. Just remember that port numbers are clues, not sworn testimony. Applications can run on unusual ports, and Wireshark may identify traffic based on more than the number alone.

13. TCP Source or Destination Port: tcp.port == 443

tcp.port == 443 matches TCP packets where 443 is either the source or destination port. I use it to isolate common HTTPS-related TCP traffic before deciding whether direction matters.

14. TCP Source Port: tcp.srcport == 443

This shows packets whose TCP source port is 443. In a client-server exchange, it can help focus on traffic coming back from a service when I already understand the topology.

15. TCP Destination Port: tcp.dstport == 443

tcp.dstport == 443 shows TCP packets sent toward destination port 443. I often combine it with an IP address when I want to see one client talking to one service.

16. UDP Port 53: udp.port == 53

udp.port == 53 isolates UDP traffic using port 53, commonly associated with DNS. It differs from dns: one is port-based, while the other depends on protocol dissection. Comparing them is a useful beginner exercise.

DNS Wireshark Display Filters I Actually Use

DNS is one of the easiest places to learn how precise Wireshark display filters can become. Instead of merely asking for all DNS packets, you can ask for a certain queried name or show requests without mixing in responses.

17. Find a Queried Domain: dns.qry.name contains "example"

This filter looks for DNS query names containing the text you specify. Replace example with a domain fragment from your own test. I use this when I already suspect a hostname and want to avoid reading every lookup generated by the operating system, browser, updates, background apps, and whatever else decided it urgently needed the internet five seconds ago.

18. DNS Queries Only: dns.flags.response == 0

The DNS response flag is Boolean, so filtering for zero shows DNS messages that are not responses. In practice, that gives me the query side of the exchange. It is useful when I care more about what a device asked than the full back-and-forth. Pair it with a host filter and the packet list becomes wonderfully boring, which in Wireshark is a compliment.

Nmap Port Scan Types Explained for Ethical Hacking Labs

Nmap Port Scan Types Explained for Ethical Hacking Labs 🧬

Wireshark Display Filter HTTP and TLS Examples

HTTP and TLS are good examples of why packet analysis is about context. Plain HTTP can expose request details directly. TLS protects application data, so you often work with handshake metadata and traffic patterns instead. Both are useful, but they answer different questions.

19. HTTP Requests Only: http.request

If you searched for a practical Wireshark display filter HTTP example, start here. http.request shows packets that contain an HTTP request field, which is much cleaner than displaying every HTTP packet. In my vulnerable lab applications, this lets me concentrate on what the client requested without mixing in every response and continuation packet.

20. HTTP GET Requests: http.request.method == "GET"

This takes the previous filter one step further by matching HTTP requests whose method is GET. It is excellent for a beginner lab because the result is immediately understandable: you can connect the request shown in Wireshark with the action you performed in a browser or test client.

Use it only on traffic you own or have permission to inspect. Packet analysis is much more educational when nobody has to explain it to a lawyer afterward.

21. TLS Client Hello: tls.handshake.type == 1

The TLS handshake type field lets you isolate specific handshake messages; type 1 represents a Client Hello. I use this when I want to find the start of TLS negotiations without displaying every encrypted application packet that follows.

It is also a good reminder that encryption does not make network analysis blind. It simply means you should stop expecting the payload to read like an open postcard.

TCP Troubleshooting Wireshark Filters

These are the Wireshark display filters that made the tool click for me. Protocol and port filters organize traffic; TCP analysis filters help explain behavior. They are not automatic proof that the network is broken, because captures can be incomplete and hardware or software offloading can create odd-looking results, but they give you strong places to investigate.

22. Suspected Retransmissions: tcp.analysis.retransmission

This shows packets Wireshark marks as suspected TCP retransmissions. I treat it as a lead rather than a verdict because packet loss, latency, congestion, and capture conditions can all matter. It is still one of the first Wireshark filters I check on a slow or unstable connection.

23. Duplicate ACKs: tcp.analysis.duplicate_ack

tcp.analysis.duplicate_ack surfaces duplicate TCP acknowledgments identified by Wireshark’s analysis. I compare them with retransmissions and timing in the same stream instead of treating one highlighted packet as a confession.

24. TCP Reset Packets: tcp.flags.reset == 1

This shows TCP packets with the RST flag set. When a service drops a connection immediately, I use it to see whether resets are part of the story. The filter finds the flag; you still have to explain why it happened.

25. Initial TCP SYNs: tcp.flags.syn == 1 && tcp.flags.ack == 0

This combination isolates SYN packets where ACK is not set, which focuses on initial TCP connection attempts. In my lab I use it to see which systems are trying to open new sessions and where those attempts are going.

How to Combine Wireshark Display Filters Without Making a Mess

The 25 filters above become much more useful when you combine them. Wireshark supports logical operators such as && for AND, || for OR, and ! for NOT. I recommend writing the filter around a question instead of trying to build the cleverest expression in the room.

For example, if I want TCP port 443 traffic involving one lab host, I can use:

ip.addr == 192.168.20.10 && tcp.port == 443

If I want either DNS or ICMP traffic, I can use:

dns || icmp

And if I want to exclude one host from the view, I can use:

!(ip.addr == 192.168.20.10)

This is why I see a Wireshark display filters cheat sheet as a starting point, not the finish line. The useful part is learning that filters are building blocks. Once you can translate “show me traffic from this VM to that service” into a filter, Wireshark stops being a packet viewer and becomes an investigation tool.

How I Practice Wireshark Filters in My Own Lab

I do most of this on a second-hand HP EliteBook that I upgraded with another 16GB of RAM, bringing it to 32GB. It turned an already capable business laptop into a surprisingly powerful little lab machine without requiring me to sell a kidney for something covered in RGB lighting.

On my main system I chose VMware rather than VirtualBox. I have both Kali Linux and Parrot OS available, although Parrot OS is the environment I mainly use. The additional memory means I can comfortably run vulnerable virtual machines while keeping Wireshark open and capturing traffic at the same time.

That matters because the best way I have found to learn Wireshark display filters is not by staring at somebody else’s screenshot. I generate traffic myself and already know approximately what should happen. Then I see whether I can isolate it.

My network is also separated by purpose. I use a TP-Link Archer C6 on the vulnerable side of my setup for controlled sniffing and lab experiments. That environment is where I want ARP, DNS, TCP, HTTP, and other traffic to remain observable. I can run deliberately vulnerable systems there without pretending that my normal home network should join the experiment.

Vulnerable machines are excellent teachers. They are much less charming as roommates.

For normal internet use, my approach is completely different. I use a Cudy WR3000 with ProtonVPN running over WireGuard and Secure Core at the router level. That creates an interesting packet-analysis comparison too. Depending on where I capture, I may see individual connections before they enter the VPN tunnel or mostly encrypted tunnel traffic after they have been wrapped.

This distinction matters because Wireshark only sees what is observable at the capture point. A display filter can organize packets brilliantly, but it cannot magically reveal data that was already encrypted before the interface saw it. Where you capture matters just as much as which Wireshark filters you use.

I also like keeping VPN routing at the router because it avoids configuring every individual lab-adjacent device separately. Secure Core adds another routing layer through privacy-focused infrastructure, which fits the way I separate everyday internet use from deliberately exposed testing environments.

Proton Unlimited bundles ProtonVPN, Proton Mail, Proton Drive, and Proton Pass under one subscription. If you already use several Proton services for privacy and lab work, the bundle can be the more practical option.

The Cudy WR3000 is not required for Wireshark, obviously. Wireshark will not throw a tantrum if you use another router. I mention it because network-level VPN routing and separate lab segments make it much easier for me to understand exactly where traffic is flowing before I start analyzing a capture.

Hacking of WiFi Password: How Ethical Hackers Test Wireless Security

Hacking of WiFi Password: How Ethical Hackers Test Wireless Security

A Better Workflow Than Memorizing a Wireshark Filters Cheat Sheet

I would not try to memorize all 25 Wireshark display filters at once. I learned faster by repeating the same sequence: identify the host, narrow the protocol, add direction or a port, then ask one specific question about the remaining traffic.

• Start with the host: use ip.addr, ip.src, or ip.dst.
• Add the protocol: TCP, UDP, DNS, HTTP, TLS, ICMP, or ARP.
• Narrow the service: add a port when it actually helps.
• Ask one question: requests, Client Hello messages, resets, retransmissions, or new SYNs.

For example, imagine I open a vulnerable web application in one of my VMs. I could start with its IP address:

ip.addr == 192.168.20.10

If that is still noisy, I add TCP:

ip.addr == 192.168.20.10 && tcp

If I am testing plain HTTP in the lab, I might instead ask for requests:

ip.addr == 192.168.20.10 && http.request

That sequence teaches far more than memorizing a list because every extra condition answers a reasoned question.

I also clear the filter occasionally and inspect the frames around a match. One interesting packet is not a complete explanation. The surrounding conversation, sequence, and timestamps usually matter just as much.

Common Wireshark Display Filter Mistakes

The filter bar is forgiving enough that experimenting is safe, but there are a few mistakes I see beginners make repeatedly. Most come from trying to make the capture too precise before understanding what is actually happening.

Using Capture Syntax in the Display Filter Bar

Capture filter vs display filter is not just terminology. They use different filtering languages. If an expression copied from a capture tutorial fails in the display filter bar, check which filtering system it was written for before assuming you typed something wrong.

Assuming a Port Proves the Protocol

Ports are useful clues, not proof. Port 443 strongly suggests common HTTPS traffic, for example, but applications are not legally required to behave nicely for your packet capture. Services can run on unusual ports, so I combine port information with Wireshark’s protocol dissection and the surrounding conversation.

Filtering Away the Context

I have stacked conditions until a capture looked beautifully clean and almost useless. That is surprisingly easy to do. Good Wireshark display filters reduce noise without hiding the frames you need to explain the event.

If I find something interesting with a very narrow filter, I often remove one condition afterward and inspect what happened immediately before and after it.

Treating TCP Analysis Flags as a Verdict

tcp.analysis.retransmission and tcp.analysis.duplicate_ack are excellent leads, but capture gaps, packet reordering, and network-interface offloading can influence what Wireshark reports.

I use those filters to choose where to investigate next. I do not look at three retransmissions and announce that the router has entered its final hours.

Expecting Encrypted Traffic to Become Readable

A tls filter can show you TLS packets, but it does not automatically decrypt the application data inside them. You can still analyze endpoints, timing, packet sizes, handshakes, and connection behavior, which is already useful information.

This is another reason I like practicing inside a controlled lab. I can deliberately create both plain and encrypted traffic and immediately see how differently the same basic activity looks in Wireshark.

Which Wireshark Display Filters Should a Beginner Learn First?

If you only remember five filters from this guide, I would start with ip.addr, dns, tcp.port, http.request, and tcp.analysis.retransmission.

Together, they cover five very different but useful questions:

• Which packets involve this device?
• Which domain names are being resolved?
• Which traffic uses this TCP port?
• Which HTTP requests are visible?
• Is Wireshark identifying possible TCP retransmissions?

Then add ip.src and ip.dst, learn the Wireshark filter by IP range examples, and practice combining conditions.

The real milestone is not being able to recite 25 Wireshark filters from memory. It is looking at a capture, deciding what you need to know, and writing a filter that moves you toward the answer.

Why Display Filters Make Wireshark Easier to Learn

One reason Wireshark intimidates beginners is that the application shows too much information very efficiently. That is not a flaw. A packet analyzer is supposed to capture detail. The problem starts when you believe you need to understand all of that detail simultaneously.

You do not.

When I teach myself a new protocol or troubleshoot a lab connection, I shrink the problem until it becomes understandable. First one host. Then one protocol. Then one direction or service. Only after that do I start inspecting individual packet fields.

That makes Wireshark display filters more than a convenience feature. They are part of the learning process itself.

A beginner who sees 5,000 packets may think, “I have no idea what any of this means.” The same beginner looking at six DNS queries from a machine they just triggered manually has a problem they can actually reason about.

That is how I would use this Wireshark filters cheat sheet: not as a command encyclopedia, but as a set of lenses. Change the lens depending on the question.

My Take on Wireshark Display Filters

Wireshark display filters are the part of Wireshark I wish beginners learned earlier. Capturing packets is easy. Understanding which packets matter is where the actual work starts.

Protocol filters give you broad control, IP and port filters give you focus, and the DNS, HTTP, TLS, and TCP analysis fields let you ask increasingly specific questions. Once you start combining those filters, a capture that initially looked like digital confetti becomes much easier to reason about.

Keep this Wireshark display filters cheat sheet nearby, but use it inside a lab instead of reading it like documentation before bed. Generate a ping. Make a DNS lookup. Open a test web page. Start a connection. Then watch how each filter changes the view.

The packet list will teach you faster when you already know what action created the traffic.

And always capture responsibly. I use intentionally vulnerable systems because they belong to me and sit in an isolated environment. Wireshark is a network analyzer, not a permission slip. If the traffic is not yours and you are not authorized to inspect it, leave the shark unfed.

Frequently Asked Questions