TCP Flags Explained: What PSH and URG Mean in Packet Captures

The quick download

Every TCP packet carries control flags that determine how data is handled, and understanding PSH and URG turns confusing captures into clear sequences.

PSH forces immediate delivery of data without waiting for a full segment and it commonly appears in HTTP requests and browser sessions.
URG marks specific bytes as high-priority so the receiving application processes them before anything else in the stream, though inconsistent implementations make it uncommon in typical captures.
The six TCP flags (SYN, ACK, FIN, RST, PSH, URG) each control a distinct phase of connection management, from setup to teardown to data prioritization (RFC 793).
Open Wireshark, filter for tcp.flags.push == 1, and trace how PSH aligns with small data bursts in your own network traffic.

TCP flags are control bits in the TCP header that tell both ends of a connection what to do with a packet: whether to send data immediately, prioritize it, establish a connection, or close one.

Two flags that often appear in packet captures but are rarely explained clearly are PSH and URG:

PSH sends data immediately without waiting for the buffer to fill.
URG prioritizes specific data above everything else in the stream.

Understanding what triggered either flag turns an ambiguous packet trace into a readable sequence of decisions. In this article, we’ll explain how each flag works, why it gets set, and what to look for when you see it in a capture.

Where PSH and URG Fit Among All TCP Flags

TCP defines six control flags, and each one handles a different part of how a connection is managed.

Flag	Full name	What it does
SYN	Synchronize	Initiates a TCP connection between two hosts
ACK	Acknowledgment	Confirms receipt of data or a connection request
FIN	Finish	Signals the sender has no more data to send; begins connection teardown
RST	Reset	Abruptly terminates a connection, usually due to an error
PSH	Push	Tells TCP to send data immediately without waiting for the buffer to fill
URG	Urgent	Marks specific data as high-priority for the receiving application to process first

PSH and URG are the two flags most likely to confuse a packet trace. Here’s how each one actually works.

What the PSH Flag Does

The PSH flag tells the sending TCP stack not to wait for the buffer to fill before sending data. Instead of holding smaller packets until there’s enough data to fill a full segment, PSH forces immediate dispatch to the receiving application.

A browser requesting HTML from a server sends a request too small to fill a full TCP segment. Rather than wait for the buffer to fill, the request is packaged and marked with a PSH flag, telling the operating system to send it immediately.

The PSH flag is determined by the operating system’s TCP implementation. Berkeley-derived systems, for example, set PSH to signal that the client’s send buffer is empty.

This shows up in the response to the request above, captured below.

It’s a small reply, marked with a PSH before the transaction is concluded with the FIN.

When you see PSH set in a capture, it typically means the sender had data too small to fill a segment and the OS decided not to wait. If PSH appears on nearly every packet in a trace, that’s normal; it just means the application is sending small, frequent bursts rather than large chunks.

What the Urg Flag Does

The URG flag lets the stream and receiving application know that certain data needs to be prioritized. URG is set when an application needs the receiver to act on specific data immediately, regardless of what else is already in the stream.

For example, you might have a file transfer that needs to be aborted because you accidentally sent the wrong file. In that case, the URG flag is set on the packet carrying the abort signal, with the urgent pointer marking exactly where the urgent data ends in the segment.

The receiving application reads that urgent data first, processing the abort, before handling anything else in the stream.

PSH is typically set alongside URG, since urgent data shouldn’t wait for the segment to fill before being sent.

Per Stevens (Section 20.8), implementations differ on URG, with some treating it as out-of-band signaling rather than strict in-band priority data. That inconsistency is why a fully RFC-compliant URG packet trace is hard to find in practice.

If you do see URG in a capture, check the Urgent Pointer field in the TCP header. When URG is set, the pointer identifies the position of the urgent-data boundary relative to the segment sequence number; it should not be interpreted as the number of urgent bytes in that packet.

Read TCP Flags in Your Own Captures

The best way to solidify this is to open Wireshark and pull a real capture.

Filter for tcp.flags.push == 1 to see PSH in action, or tcp.flags.urg == 1 if you want to hunt for URG; though don’t be surprised if that one comes up empty.

Every HTTP request, browser session, and file transfer you capture will have PSH set somewhere. Once you know what triggered it, the rest of the trace starts making sense a lot faster.

See exactly how your network handles TCP connections across every hop.

LogicMonitor delivers full visibility into network performance, from packet-level behavior to end-user experience. Stop guessing what your captures mean and start monitoring proactively.

Request a demo

FAQs

Why does the PSH flag appear on almost every packet in my capture?

PSH is set whenever the sender’s data is too small to fill a full TCP segment and the operating system decides to send it immediately rather than wait (RFC 793, Section 2.8). Interactive applications like browsers and APIs typically send frequent small bursts, so PSH commonly appears on many packets. This is normal behavior, not an error.

What is the difference between the PSH and URG flags?

PSH controls timing: it tells the TCP stack to send data immediately instead of buffering (RFC 793, Section 2.8). URG controls priority: it marks specific bytes in the segment as high-priority so the receiving application processes them first (RFC 793, Section 3.1). They often appear together because urgent data also needs immediate delivery.

How can I find URG-flagged packets in Wireshark?

Apply the display filter tcp.flags.urg == 1 in Wireshark. URG packets are uncommon in typical modern traffic, so the filter may return no results. When you do find one, check the urgent pointer field in the TCP header (RFC 793, Section 3.1) to see how many bytes of urgent data the segment contains.

14-day access to the full LogicMonitor platform

Culture