Ask a Modbus device to read 200 registers in one request and it will refuse, because a single read tops out at 125 holding or input registers. This is not an arbitrary setting; it falls directly out of a hard size limit baked into the Modbus protocol itself. This guide explains where the 125-register ceiling comes from, why coils cap out at 2000 in the same way, why polling drivers automatically split a large register map into several requests, and how the layout of a register map affects how efficiently it can be polled.
125-Register Read Limit in one line: A single Modbus read is capped at 125 holding or input registers because the protocol limits a message's data unit to 253 bytes, and 125 sixteen-bit registers is the most that fits inside that ceiling along with the required header bytes. The same limit caps a single coil read at 2000 coils, since coils are one bit each. To read more than that, a polling driver has to split the request into multiple reads, each within the limit.
The root cause is a size limit built into Modbus from its origins. The protocol defines a maximum size for its message data unit - the protocol data unit, or PDU - of 253 bytes. This ceiling comes from the original serial Modbus frame, whose overall message was limited to 256 bytes; after accounting for the address and error-check fields that wrap the PDU on the serial line, 253 bytes remain for the PDU itself. Modbus TCP inherited the same 253-byte PDU limit for compatibility, even though its transport could technically carry more, so the constraint applies whether you are on RS-485 or Ethernet.
Within that 253-byte PDU, a read response has to fit its own overhead plus the actual register data. For a read holding registers response, the PDU carries the function code and a byte-count field before the data, which leaves 250 bytes for register values. Each holding register is 16 bits, so it takes two bytes, and 250 divided by 2 is exactly 125. That is where the number comes from - it is simply the largest number of two-byte registers whose data fits in the space the 253-byte PDU leaves after its header. There is nothing magic about 125; it is arithmetic dictated by the protocol's byte budget.
The same PDU ceiling produces a different number for coils and discrete inputs, and understanding why reinforces where 125 came from. Coils and discrete inputs are single bits, not 16-bit registers, so a read packs eight of them into every byte of the response. The response still has to fit within the 253-byte PDU after its function code and byte-count overhead, but because eight bits ride in each data byte, far more of them fit. Working through the same byte budget with eight coils per byte lands at a maximum of 2000 coils or discrete inputs in a single read.
So the two familiar Modbus read limits - 125 registers and 2000 bits - are two expressions of the same underlying rule applied to two different data widths. Registers are two bytes each, so relatively few fit; coils are an eighth of a byte each, so many more fit; but in both cases the total is whatever the 253-byte PDU can hold after its header. Seeing them as consequences of one constraint rather than two separate arbitrary numbers makes the whole limit easier to reason about, and explains why writes have their own related caps for the same reason: every Modbus message has to live inside that same byte budget.
Real devices routinely expose far more than 125 registers, so a polling driver cannot read a whole map in one request. It automatically splits the map into multiple reads, each staying within the 125-register limit, and assembles the results. A well-built driver is smart about this: rather than reading each point individually, it groups contiguous registers into the largest legal blocks and issues one request per block, because reading a run of registers together is dramatically more efficient than reading them one at a time. Each request carries protocol overhead and, on serial links especially, a round-trip delay, so fewer, larger reads beat many small ones.
This is why the physical layout of a register map affects poll efficiency, and why it matters when integrating a device with a cloud SCADA platform such as Merobix. If the points you care about are packed into a contiguous span of registers, the poller can gather them in one or a few large block reads. If the same points are scattered across a sparse address space with big unused gaps between them, the poller either wastes bandwidth reading useless registers in the gaps to keep blocks contiguous, or breaks the read into many small requests to skip the gaps - and both hurt throughput. When a cloud poller is reaching many field devices over cellular or shared links where each round trip costs latency and data, contiguous, densely packed register maps translate directly into faster, cheaper polling. You cannot change the 125-register limit, but you can lay out or select register ranges so the driver spends its request budget on data you actually need.
Because the Modbus protocol caps its message data unit at 253 bytes, and a read-registers response uses some of that for its function code and byte-count header, leaving 250 bytes for data. Each register is two bytes, so 250 divided by 2 gives exactly 125 registers as the most that fit in a single response. The number is pure arithmetic from the protocol's byte budget, not a configurable setting, and it applies to both holding and input registers.
Both limits come from the same 253-byte data-unit ceiling, but coils and registers pack differently. A coil is a single bit, so eight of them fit in each data byte, while a register is two full bytes. Because far more single bits fit into the same space than two-byte registers do, the coil read tops out at 2000 while the register read tops out at 125. They are two expressions of one underlying size constraint applied to different data widths.
It automatically splits the request into multiple reads, each staying within the 125-register limit, and reassembles the results. A good driver groups contiguous registers into the largest legal blocks and issues one request per block, because reading a run of registers together is far more efficient than reading them one by one. This is why contiguous, densely packed register maps poll faster - the driver can gather the needed points in fewer, larger reads instead of many small ones.
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.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.