How every network protocol encodes headers, payloads, and control data in bits and bytes
Everything on a network boils down to sequences of bits traveling across a wire, through the air, or over fiber optic cables. In my early days as a network engineer, I spent countless hours staring at raw packet dumps in Wireshark, and the single most valuable skill I developed was the ability to read protocol headers at the binary level. Network protocols are nothing more than agreed-upon templates for how to arrange bits — the sender puts specific fields at specific bit positions, and the receiver knows exactly where to look to extract the information. Every protocol field, from a 1-bit flag to a 32-bit IP address, is carefully positioned within a well-defined binary structure.
The beauty of protocol design is that it is purely about bit layout. There is no ambiguity, no interpretation — just a rigid binary schema that both sides of the conversation have agreed to follow. When I design custom protocol parsers for network tools, I always start with a binary layout diagram before writing a single line of parsing code.
One of the first things you learn when working with network protocols is that all multi-byte fields are transmitted in big-endian order, also known as network byte order. This means the most significant byte (the one containing the highest-order bits) is sent first. For example, a 16-bit port number like 443 (0x01BB) is sent as 00000001 10111011 — the high byte 01 arrives before the low byte BB. I cannot count how many times I have debugged protocol implementations where the developer forgot to convert from host byte order to network byte order. The symptom is always the same: the values look correct in debug logs but the remote side interprets them as garbage. The htons() and htonl() functions exist for exactly this reason.
Every packet that travels across a local network starts inside an Ethernet frame. The Ethernet frame header is 14 bytes (112 bits) before the payload, and understanding its binary layout is the foundation for everything else. Here is the structure:
00001000 00000000 (0x0800) means IPv4, 10000110 11011101 (0x86DD) means IPv6, and 00001000 00000110 (0x0806) means ARP.After the 14-byte header comes the payload (46-1500 bytes), followed by a 4-byte Frame Check Sequence (FCS) used for error detection. I have parsed thousands of Ethernet frames manually during debugging sessions, and the binary layout never changes — it is one of the most stable protocol specifications in existence.
The IPv4 header is 20 bytes (160 bits) without options, and every single bit has a specific purpose. Here is the binary breakdown of the most important fields:
0100 (4) for IPv4. The first 4 bits of any IPv4 packet. For IPv6, it would be 0110.0101 (5 words = 20 bytes). If options are present, this value increases.010) and "More Fragments" bit (001).00000000, the packet is discarded. A typical starting value is 01000000 (64) or 10000000 (128).00000110 (6) = TCP, 00010001 (17) = UDP, 00000001 (1) = ICMP.I have manually reconstructed IPv4 headers from hex dumps during forensic analysis. Once you know the exact bit positions of each field, you can extract every piece of information from a raw packet without any tool — just a hex editor and a reference sheet.
Many protocol fields are single-bit flags. A flag is either set (1) or cleared (0). In TCP, for example, there are 9 control flags in the header, each occupying exactly 1 bit. They appear in this order in the TCP header: NS CWR ECE URG ACK PSH RST SYN FIN. If you see a byte value of 00010010 in the flags field, that breaks down as: NS=0, CWR=0, EWR=0, URG=0, ACK=1, PSH=0, RST=0, SYN=1, FIN=0. This means the packet has the ACK and SYN flags set — the second step of the TCP three-way handshake. I use this binary-to-flags mapping daily when reading packet captures.
Protocol multiplexing is what allows different protocols to coexist in the same network stack. At each layer, a type or protocol field tells the receiving stack which handler to pass the data to. At Layer 2, the EtherType field (16 bits) in the Ethernet header selects between IPv4 (0x0800), IPv6 (0x86DD), ARP (0x0806), and others. At Layer 3, the Protocol field (8 bits) in the IPv4 header selects between TCP (6), UDP (17), ICMP (1), and others. At Layer 4, TCP and UDP use port numbers (16 bits each) to demultiplex to the correct application. This cascading dispatch system, all driven by small binary fields in protocol headers, is what makes the entire internet work. Every byte you send is wrapped in multiple layers of binary headers, each layer providing the addressing and demultiplexing information needed to get the data to the right application on the right device.
Pro Tip: When analyzing a new protocol, always draw the bit layout on paper first. Mark every field with its bit offset and bit length. I still do this for every protocol I reverse-engineer or implement — a visual map is far more useful than reading raw RFC text.
UDP is the simplest transport protocol, and its binary header is only 8 bytes (64 bits). It contains just four 16-bit fields:
xxxxxxxx xxxxxxxx — The sender's port number.xxxxxxxx xxxxxxxx — The receiver's port number.That is it. No sequence numbers, no flags, no windowing. The entire header fits in 64 bits. I often use UDP for custom network tools because the header parsing logic is trivial — 4 fields of 16 bits each, no state tracking required.
Open the Binary Code Decoder in a new tab and enter some binary patterns to see the results instantly. All conversions happen in your browser — no data is sent to any server.