Wireshark is the world's most widely used network protocol analyzer. Network engineers use it to inspect packet captures at the byte level, diagnose application issues, validate encryption, and troubleshoot wireless connectivity problems. Wireshark has two types of filters — capture filters (BPF syntax, applied during capture to limit what is saved) and display filters (Wireshark's own syntax, applied after capture to filter what is shown). Use the builder below or browse the reference sections for the most common filters.
- Applied before packets are saved
- Uses tcpdump/BPF syntax
- Reduces file size — only saves matching packets
- Cannot be changed after capture starts
- Set in: Capture → Options → Filter
- Applied after packets are captured
- Uses Wireshark's own syntax
- Does not discard packets — just hides them
- Can be changed anytime during analysis
- Entered in the filter bar at the top
Wireshark gives you two completely different filter syntaxes, and mixing them up is the most common Wireshark mistake. Capture filters use BPF — the same syntax as tcpdump (host 10.0.0.1 and port 443) — and run in the kernel before packets are saved. Display filters use Wireshark's own protocol-aware syntax (ip.addr == 10.0.0.1 && tcp.port == 443) and run after capture. This builder targets display filters; for capture filters see the tcpdump page, since the syntax is identical.
Display filter operators: == equals, != not equals, && AND, || OR, ! NOT, with parentheses for grouping. Field names are protocol-prefixed: ip.src, tcp.port, http.request.method, wlan.bssid. Wireshark autocompletes these as you type — there are thousands of them, one for almost every parsed field of every supported protocol. The filter bar turns green when valid, red when not, yellow when ambiguous.
The right workflow is to capture broadly and filter narrowly. A capture filter that's too tight throws away packets you can't get back — if your bug turns out to be in some adjacent stream, you're starting over. Better: capture with a loose BPF filter (or none), then use display filters during analysis. The display filter is non-destructive — clear it and the full capture comes back instantly.
A few filters worth memorizing: tcp.flags.reset == 1 finds RST packets, which are often the first sign of a broken connection (firewall reset, app crash, timeout from the other side). tcp.analysis.flags shows everything Wireshark's expert analyzer flagged as anomalous — retransmissions, duplicate ACKs, zero window, out-of-order. http.response.code >= 400 isolates HTTP errors. dns.flags.response == 0 shows only DNS queries (not responses), useful for finding the lookups a misbehaving client is doing. For wireless captures, wlan.fc.type_subtype == 0x000c filters deauthentication frames — the smoking gun for both honest disconnects and deauth-flood attacks.