What Is MQTT Maximum Packet Size?
Maximum packet size is the MQTT 5 property that lets a memory-constrained client tell the broker not to send it anything larger than it can handle. For an embedded RTU or gateway with a small receive buffer, it is a safety valve against an oversized payload that would otherwise overflow memory. This page explains how each side declares its limit, what happens when a message exceeds it, and why constrained field devices care.
MQTT Maximum Packet Size in one line: The MQTT maximum packet size is an MQTT 5 property that a client sets in its CONNECT to tell the broker the largest packet, in bytes, it is willing to accept. The broker will not send that client any packet exceeding the limit, dropping or refusing to forward oversized messages instead. The broker can also advertise its own maximum, which caps what the client is allowed to publish.
How Each Side Declares Its Limit
The negotiation runs in both directions and is asymmetric. The client sets a maximum packet size property in its CONNECT packet, and that value binds the broker: the broker must not send that client any packet larger than the stated limit. Separately, the broker advertises its own maximum packet size in the CONNACK, and that value binds the client: the client must not send the broker anything larger. If either side omits the property, no limit is imposed by that side beyond the protocol's own absolute ceiling.
The limit is measured on the whole MQTT packet, not just the application payload. That means the fixed header, the variable header, all the MQTT 5 properties, and the payload together must fit. A design that pushes a payload right up against a limit can be tripped by the header and property overhead, so the safe practice is to size the payload well inside the declared maximum. This whole-packet accounting is the same reason header metadata like user properties is not free on a constrained link.
For SCADA the client-imposed limit is the more interesting direction, because the field device is usually the constrained one. An embedded gateway with a fixed receive buffer can declare a maximum packet size matching that buffer, and the broker will then never hand it a message it cannot hold. Without the property, a large retained message or a big command payload could arrive and overrun the device, which on an unattended remote site is exactly the kind of failure you cannot afford.
What Happens When a Message Is Too Big
When a publisher sends a message that exceeds a subscriber's declared maximum packet size, the broker does not deliver it to that subscriber; it is dropped for that recipient. The message may still be delivered to other subscribers whose limits it fits under, so the constraint is per-client, not global. This means a poorly sized limit can cause a subtle failure where one consumer silently misses messages that others receive, which is maddening to diagnose if you are not looking at packet sizes.
In the other direction, if a client tries to publish a packet larger than the broker's advertised maximum, the broker rejects it, and in MQTT 5 it can tell the client why with a reason code indicating the packet was too large, either on the publish acknowledgement or on a disconnect. That feedback is far better than the silent connection drop a 3.1.1 broker might give when it dislikes an oversized message, and it points you straight at the payload size rather than the network.
The practical guidance is to set the client maximum to match real receive-buffer capacity with margin, and to keep publish payloads comfortably under the broker's advertised limit. If you find yourself needing very large packets, that is usually a signal to batch differently or to compress, rather than to raise the ceiling, because a huge MQTT message is fragile on a lossy link where the entire packet must arrive intact. The batching trade lives in gateway payload batching.
Frequently Asked Questions
Does maximum packet size limit only the payload?
No. The maximum packet size applies to the entire MQTT packet: the fixed header, the variable header, all MQTT 5 properties, and the payload combined. Because header and property bytes count toward the total, a payload sized right at the limit can still push the packet over once the overhead is added. The safe practice is to keep the payload well inside the declared maximum so the surrounding protocol bytes always fit without tripping the limit.
Why would a field gateway set a small maximum packet size?
To protect a small, fixed receive buffer. An embedded RTU or gateway often allocates a modest buffer for incoming MQTT packets, and a message larger than that buffer would overrun it or force an awkward failure. By declaring a maximum packet size that matches its real capacity, the device tells the broker never to send it anything it cannot hold, so an oversized retained message or command is simply not delivered to it rather than crashing it on an unattended site.
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.
- MQTT Version 5.0 (OASIS Standard) - OASIS (v5.0, 2019)
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.