MQTT Packet Size Calculator
Estimate MQTT PUBLISH packet bytes, variable header growth, QoS acknowledgment traffic, TCP/IP and TLS record overhead, publish rate, and broker fan-out bandwidth.
📡IoT traffic presets
⚙MQTT message inputs
UTF-8 bytes in the PUBLISH topic name, before payload.
Use the encoded JSON, CBOR, binary, or text payload size.
Included in connect-session estimate, not every publish packet.
Retain changes the fixed header flag, not the packet length.
Connect estimate includes client ID and clean-session behavior.
📊MQTT packet component grid
📦MQTT PUBLISH byte breakdown table
| Component | Bytes | Applies when | Notes |
|---|---|---|---|
| Control packet type and flags | 1 | Every PUBLISH | Includes DUP, QoS bits, and retain flag. |
| Remaining length field | 1 to 4 | Every MQTT packet | Grows at 128, 16,384, and 2,097,152 bytes. |
| Topic name length prefix | 2 | Every PUBLISH | Two-byte integer before the UTF-8 topic. |
| Topic name bytes | Input | Every PUBLISH | Long hierarchy names can dominate tiny payloads. |
| Packet identifier | 2 | QoS 1 or QoS 2 | Needed so acknowledgments match the message. |
| Property length and properties | Input | MQTT 5 only | User properties, topic alias, expiry, and metadata. |
| Application payload | Input | Every PUBLISH | JSON, binary telemetry, state, command, or event data. |
🖧MQTT control packet grid
| Control packet | Typical base size | Traffic direction | Bandwidth impact |
|---|---|---|---|
| CONNECT | 16 B plus client ID | Client to broker | Session setup only, not per publish. |
| CONNACK | 4 B | Broker to client | Small one-time reply per connection. |
| PUBLISH QoS 0 | Payload plus topic | Either direction | Lowest packet count, no MQTT ack. |
| PUBLISH QoS 1 | QoS 0 plus 2 B id | Either direction | Adds PUBACK packet for each publish. |
| PUBLISH QoS 2 | QoS 1 size | Either direction | Adds PUBREC, PUBREL, and PUBCOMP flow. |
| SUBSCRIBE | 7 B plus topic | Client to broker | Setup traffic; can include many filters. |
| PINGREQ / PINGRESP | 2 B each | Both directions | Keepalive bytes, often negligible. |
| DISCONNECT | 2 B or more | Either direction | MQTT 5 reason and properties can add bytes. |
🌐Transport overhead reference
| Transport model | Added bytes | What is included | Use for |
|---|---|---|---|
| TCP over IPv4 | 40 B | 20 B IPv4 plus 20 B TCP | Plain MQTT on port 1883 across IPv4. |
| TLS over TCP/IPv4 | 69 B | IPv4, TCP, TLS header, tag, padding estimate | Common MQTTS on port 8883. |
| TCP over IPv6 | 60 B | 40 B IPv6 plus 20 B TCP | Plain MQTT on IPv6 networks. |
| TLS over TCP/IPv6 | 89 B | IPv6, TCP, and TLS record estimate | Encrypted IPv6 home lab or WAN path. |
| Ethernet plus TLS/IPv4 | 83 B | Ethernet header plus TLS/IPv4 model | Approximate LAN wire capture sizing. |
| VPN plus TLS/IPv4 | 129 B | TLS/IPv4 plus overlay tunnel estimate | Remote brokers behind WireGuard or IPsec. |
🏠Common MQTT project sizes
| Project | Typical payload | Publish pattern | Bandwidth note |
|---|---|---|---|
| Temperature sensors | 20 to 80 B | Every 30 to 300 seconds | Topic length can exceed payload size. |
| Energy monitor | 120 to 600 B | Every 1 to 10 seconds | QoS 1 ack traffic is usually acceptable. |
| Camera motion events | 200 B to 2 KB | Burst traffic | Broker fan-out matters more than ingest. |
| Home Assistant discovery | 600 B to 4 KB | Retained setup messages | Retained packets affect broker storage. |
| GPS fleet tracking | 80 to 250 B | Every 1 to 30 seconds | Cellular billing rewards compact payloads. |
| Industrial telemetry | 64 B to 1 KB | Steady and frequent | QoS, TLS, and subscribers set capacity. |
When you design a system using the MQTT protocol, you have to consider the amount of traffic that each device will generates. The amount of traffic that each device generates will determine the data plan cost, the gateway capacity, and the capacity left for an MQTT broker. The size of the packets that is sent from each device is one of the major factor that will contribute to these calculations, but it is possible that you may underestimate the size of the packets due to the fact that only the payload size of the packet is considered.
The total size of the MQTT publish packet include the fixed header, the topic string that is published, the packet identifier that is required according to the Quality of Service of the publish, and the optional MQTT 5 properties. Additionally, the total size of the publish packet includes the transport overhead, such as 40 byte of overhead for TCP and IPv4 protocols, and even more overhead if the MQTT communication over TCP is protected with TLS. Such transport overhead does not change with the size of the payload that is sent.
Calculate MQTT message size and data use
The calculator consider each of these factors as inputs. For example, the length of the MQTT topic can have a major impact on the size of the publish packet, as it is possible for a topic to be larger than the payload. Additionally, the size of the payload that is sent can change based on the encoding scheme for that payload.
JSON is one method of making the payload easily readable to humans, but CBOR may be a better choice for applications that seek to minimize the size of the payload. Additionally, the Quality of Service can impact the size of the MQTT communication, as higher Quality of Service levels will require that MQTT acknowledge the messages to ensure they are delivered. As such, higher Quality of Service settings will result in more messages transmitted over the link.
Additionally, the settings for transport protocols allow for plain TCP or TLS protocols, as well as IPv4 or IPv6 protocols, so that the MQTT system can be configured according to the network that will be used. Beyond the size of the packets that each device publishes, additional factor must be considered in order to calculate the total bandwidth that will be utilized by the system. Factors such as the message rate, the number of devices, and the subscriber count will help to calculate the total bandwidth that will be used by the system.
For instance, if the size of a retained message is 2 KB but there are 20 dashboards that are subscribed to the same topic, the size of the message will be 40 KB of egress data. Additionally, it is also important to use a buffer percentage in the calculations in order to account for network jitter and packet retransmissions. Using a buffer of 10 or 15 percent will ensure that you account for these types of network issue.
It is likely that many people will not consider the size of the packets until after they have deployed the MQTT devices. For instance, while a temperature sensor may appear to emit very little data, the size of it’s data plans may turn out to be costly once the size of the TLS and topic string overhead are added to the data it publishes. Additionally, a fleet of GPS trackers that appears to work well at a certain publish rate may become an issue for the uplink if the number of GPS trackers increases.
However, by using the calculator to determine the impact of each of these factor, the issues can be avoided prior to purchasing the hardware that will be used to deploy the MQTT system. It may be possible to reduce the size of the packets that devices publish through the use of shorter MQTT topics or by using a Quality of Service of 0. However, reducing the size of the topics may make it more difficult to manage the system as it expands.
Additionally, using a Quality of Service of 0 means that any messages that are not delivered will not be recovered. MQTT 5 allows for topics to be aliased such that the repeated transmission of the same topic is avoided, but only if both the clients and the MQTT broker support MQTT 5. Additionally, the size of the messages that are published can include messages that the MQTT broker retains.
These messages will remain in the memory of the broker until the device that published the message clears them. Additionally, if those messages continue to grow in size due to the addition of fields for new information, the storage cost of the MQTT broker will increase. While the MQTT packet size calculator does not account for storage cost of the MQTT broker, the retained flag is one of the inputs to the calculator so that the MQTT system designer remembers to account for this type of cost for the system outside of the MQTT bandwidth calculations.
Finally, the use of cellular networks introduces additional factors into the considerations for the MQTT system. For instance, each of the cellular network carriers will bill for data in small increments of data, and many will throttle the data rate of a device after a daily data cap. Thus, a device that sends 200 bytes every 10 seconds may seem small, but if that data is multiplied by the TLS, TCP, and the number of devices that are using the system, it may become an issue.
Additionally, the publish rate at which the devices are set up will impact how many devices can remain within a specific data tier. Additionally, security settings will have an impact on the data rates. For instance, using mutual TLS with certificate pinning will add to the initial handshake data, but subsequent handshakes will be smaller.
Additionally, if the MQTT messages are transmitted through a VPN, the additional headers will impact the size of the data that is transmitted. It is important to calculate the number of data units that will be transmitted each worst-case hour instead of the average minute for each device. For instance, each device may be utilizing very little data for most of the hour, but it is possible that it will emit a burst of data during the same time period as other devices are active on the network.
If the MQTT broker is calculated to reach the uplink limit during the worst-case scenario, it may be necessary to introduce buffering for the devices or to reduce the size of any retained message that are published by the devices. By calculating the size of the messages that the devices are to be published, it is certain that the cost and reliability of the system will remain the same when the devices are online and publishing messages.
