Modbus Register Data Types and Packing
A Modbus register is nothing but a raw sixteen-bit word; the protocol has no concept of a signed integer, a float, or a string. Every richer data type is a convention layered on top by packing raw words together, and the master must know that convention to decode a value correctly. This reference explains how the common data types are packed into registers and why the layout is device-specific.
Modbus Register Data Types and Packing in one line: Modbus register data types are conventions, not protocol features. Each register is a raw sixteen-bit word, so a signed or unsigned 16-bit integer fits in one register, a 32-bit integer or float spans two, and a string packs two characters per register. Modbus does not tag the type, so the master must be told the layout, including byte and word order, to decode any value beyond a bare 16-bit word.
How the Common Types Pack Into Registers
A single register holds sixteen bits, which is exactly one signed or unsigned integer in the range of a 16-bit value, so those types occupy one register each and are the simplest case. A 32-bit integer or a 32-bit IEEE float does not fit in one register and is packed across two consecutive registers, which the master reads together and reassembles. The way those two registers combine, and the resulting decoding pitfalls, are the subject of the 32-bit float across two registers reference.
Strings are packed two characters per register, since each register holds two bytes, so a sixteen-character name occupies eight registers. Some devices pack the two characters high byte first and others low byte first, which is the string equivalent of the byte-order problem that affects numbers. Wider integers such as 64-bit values simply extend the pattern across four registers. In every case the register table itself is just words, as the Modbus register types reference describes.
Why the Master Must Be Told the Layout
The crucial fact is that Modbus carries no type information. A register read returns sixteen bits with no label saying whether it is half of a float, a standalone integer, or two characters of a string. The device's documentation, or its register map, is the only source of truth for how to interpret the words, which is why a correct read of the wrong data type produces a plausible but meaningless number. Building that authoritative map is what the Modbus register map reference is about.
Two conventions in particular must be known: which register comes first in a multi-register value, called word order, and which byte comes first within a register, called byte order. Different devices choose differently, and getting either wrong yields a garbled value even though the raw read succeeded. Because these choices are per-device, they belong in the register map, and confirming them against a known value is the reliable way to lock down the layout before trusting any packed type.
Frequently Asked Questions
How many registers does a 32-bit float use in Modbus?
Two consecutive registers, because a single register holds only sixteen bits. The master reads both and reassembles the 32-bit value. The order in which the two registers combine, the word order, and the byte order within each register are device-specific, so the same two registers can decode to very different numbers if the layout is wrong.
Does Modbus tell you the data type of a register?
No. Modbus registers are raw sixteen-bit words with no type tag. A read returns bits, not a labeled integer or float. You must know from the device's documentation or register map how to interpret each register, which is why reading a value as the wrong type produces a plausible but wrong number rather than an error.
How are strings stored in Modbus registers?
Two characters per register, since each register holds two bytes. A sixteen-character string occupies eight registers. Devices differ on whether the first character is the high or low byte of a register, so the string can appear byte-swapped if the order is assumed wrongly. As with numbers, the device's map defines the correct layout.
Sources and verification
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
- Modbus Application Protocol Specification - Modbus Organization
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.