Paste a Modbus RTU or TCP hex frame and instantly decode every byte. Validates CRC-16, parses function codes, and extracts register values.
Monitor and decode Modbus frames in real-time from your serial port or TCP connection. Built-in request builder, auto-CRC, and frame history.
Download Free TrialModbus is one of the most widely deployed industrial communication protocols, connecting PLCs, sensors, VFDs, energy meters, and thousands of other devices across factory floors, power plants, and building automation systems worldwide. At the heart of every Modbus exchange is a structured frame, a sequence of bytes that carries a request from a master (client) to a slave (server) and brings back a response. Understanding how these frames are constructed is essential for anyone commissioning, troubleshooting, or reverse-engineering Modbus networks.
In Modbus RTU mode, data is transmitted over a serial line (RS-232 or RS-485) as a compact binary frame. Every RTU frame begins with the Slave Address, a single byte identifying which device on the bus should respond (1 to 247 for unicast, 0 for broadcast). Next comes the Function Code byte, which tells the slave what operation to perform: read coils (FC01), read discrete inputs (FC02), read holding registers (FC03), read input registers (FC04), write a single coil (FC05), write a single register (FC06), write multiple coils (FC15), or write multiple registers (FC16). The data field that follows is variable-length and depends entirely on the function code.
The final two bytes of every RTU frame are the CRC-16 checksum, calculated over all preceding bytes using the polynomial 0xA001. The CRC is transmitted in little-endian order (low byte first, high byte second). If even a single bit is corrupted during transmission, the CRC will fail, and the slave discards the frame silently. This is one of the most common sources of communication errors in noisy industrial environments.
Modbus TCP wraps the same PDU inside a TCP/IP packet with a 7-byte MBAP header. The header begins with a 2-byte Transaction Identifier for matching responses to requests. Next comes the 2-byte Protocol Identifier (always 0x0000 for standard Modbus). The Length field (2 bytes) specifies how many bytes follow. The Unit Identifier (1 byte) serves the same role as the RTU Slave Address. Modbus TCP does not use a CRC since TCP provides its own error checking.
The data field interpretation depends on whether the frame is a request or response and which function code is used. For FC01-FC04 requests, the data is always 4 bytes: a 2-byte starting address and a 2-byte quantity. For FC01/FC02 responses, the data begins with a byte count followed by packed coil bits. For FC03/FC04 responses, the byte count is followed by 16-bit register values in big-endian order. FC05 uses 0xFF00 for ON and 0x0000 for OFF. FC06 carries address and value. FC15 and FC16 carry starting address, quantity, byte count, and values.
This parser accepts raw hex bytes in any common format (space-separated, comma-separated, continuous hex string, or 0x-prefixed), auto-detects whether the frame is RTU or TCP, and decodes every field with color-coded byte visualization. For RTU frames it calculates and validates the CRC-16. For TCP frames it extracts the full MBAP header. Paste a logic analyzer capture or Wireshark hex dump here and get an instant readable decode.