SYN Packet (Hex):
00501f90000000000000000050020000a6320000
HTTP Request (Hex, first 40 bytes):
c0260050d8fe00000000000050020000e1c70000474554202f20485454502f312e310d0a
Packet with Options (Hex):
00501f900000000000000000b0020000e1b70000020405b40103030801010402
Parses TCP packets and extracts fields from the header including ports, sequence numbers, flags, window size, and options. Supports both Hex and Raw input formats.
Transmission Control Protocol (TCP) is the foundational connection-oriented protocol of the internet. When debugging complex network issues, analyzing raw socket programming, or competing in cybersecurity Capture The Flag (CTF) challenges, engineers frequently need to inspect raw packet dumps represented as hexadecimal (Hex) strings.
While packet sniffers like Wireshark do this automatically, you often find yourself with just a raw hex snippet extracted from a log file or a firewall alert. Manually decoding sequence numbers, calculating window sizes, and identifying active control flags from a hex string is mathematically tedious.
Our online TCP Header Parser (compliant with RFC 793 and RFC 9293) instantly decodes your raw hexadecimal payload. It performs the complex bitwise operations required to extract Source/Destination Ports, Sequence and Acknowledgment numbers, and critical TCP Flags, presenting the 20+ byte header in a structured, human-readable dashboard.
As security analysts and network engineers, we understand the critical importance of Operations Security (OPSEC). Your packet captures often contain sensitive infrastructure footprints.
Zero Server Logs: We never transmit, save, or log your hexadecimal payloads or the resulting port data.
Absolute Local Execution: The parsing engine runs completely offline within your web browser's local sandbox memory.
Instant Decoding: Because no data is sent to a remote API, the hex-to-field translation happens instantaneously.
Translating your raw TCP packet dump into actionable structured data is simple:
Input Your Hex Payload: Paste your continuous hexadecimal string into the input box. A standard TCP header without options requires a minimum of 40 hex characters (20 bytes).
Instant Parsing: Our local JavaScript engine immediately processes the bytes according to RFC specifications.
Analyze the Structured Output: The tool will automatically separate and display the fields:
Source & Destination Ports: Identifies the application endpoints (e.g., Port 80 for HTTP, 443 for HTTPS).
Sequence (Seq) & Acknowledgment (Ack) Numbers: Crucial for understanding stream reassembly and packet loss.
Data Offset (Header Length): Calculates if TCP Options (like MSS or Window Scaling) are appended to the header.
TCP Flags (Control Bits): Visually highlights the active flags (URG, ACK, PSH, RST, SYN, FIN) to help you identify the state of the three-way handshake or connection teardown.
Window Size: Displays the receive window size used for flow control.
Q: What is the minimum length of a TCP header?
A: A standard TCP header without any optional fields is exactly 20 bytes long. Since each byte is represented by two hexadecimal characters, your input string must contain at least 40 hex characters to be parsed successfully. If TCP Options are present, the header can be up to 60 bytes long (120 hex chars).
Q: How does the parser know if there are TCP Options attached?
A: The tool looks at the "Data Offset" field (a 4-bit value located at the 12th byte). This value specifies the size of the TCP header in 32-bit words. If the value is greater than 5 (which equals the minimum 20 bytes), the parser knows that the remaining bytes contain TCP Options (such as Maximum Segment Size or Timers).
Q: Why are the TCP Flags (SYN, ACK, FIN) so important?
A: TCP Flags are the control mechanisms of a connection. For example, a packet with only the SYN flag set indicates an attempt to initiate a new connection (Step 1 of the 3-way handshake). A packet with RST indicates a forced connection reset. Our parser decodes these specific bits so you instantly know the packet's intent.
Q: Can this tool parse the payload (application data) inside the TCP packet?
A: No, this specific tool is designed exclusively to parse the TCP Header infrastructure. It focuses on routing, state, and flow control fields. Any hexadecimal data following the Data Offset limit is considered the application payload and is not decoded here.