MQTT Data Usage & Overhead Calculator

How the MQTT data estimate is calculated

The calculator starts with the bytes in one MQTT PUBLISH packet. MQTT stores the PUBLISH variable header and payload length in the Remaining Length field, which uses a variable byte integer. Let L(x) be 1 byte when x <= 127, 2 bytes when x <= 16,383, 3 bytes when x <= 2,097,151, and 4 bytes up to the MQTT maximum of 268,435,455.

For a payload P, topic byte length T, QoS packet identifier length I, and MQTT 5 property section G, the PUBLISH Remaining Length is:

M = 2 + T + I + G + P

The two bytes before the topic hold the topic length. QoS 0 uses I = 0; QoS 1 and QoS 2 use I = 2. MQTT 3.1.1 uses G = 0. MQTT 5 uses G = L(X) + X, where X is the encoded property data. Even with no MQTT 5 properties, the property length field is still one byte.

The full PUBLISH packet is then U = 1 + L(M) + M. QoS 0 has no MQTT acknowledgment bytes. QoS 1 adds a four-byte PUBACK. QoS 2 adds PUBREC, PUBREL, and PUBCOMP, modeled as three four-byte packets. The MQTT exchange is E_mqtt = U + A.

To estimate network bytes, the calculator adds one IP header, one 20-byte TCP header, and the selected TLS record overhead for each MQTT control packet in the exchange. IPv4 uses a 20-byte IP header and IPv6 uses a 40-byte header. With K MQTT control packets, the network exchange is:

E = E_mqtt + K * (IP + TCP + TLS)

Daily data per device is E * messages per hour * 24 / 1,000,000. Monthly fleet data multiplies that value by devices and billing days. Average fleet bandwidth is E * messages per hour * devices * 8 / 3,600,000 kbit/s. Maximum devices is the floor of the monthly allowance bytes divided by one device's monthly bytes.

What moves the result most

Payload size, message rate, and device count usually dominate monthly data. Small sensor messages are different: a short payload can be smaller than the topic, headers, TLS tag, and QoS exchange. QoS 2 is useful when an application needs exactly-once delivery, but it turns one PUBLISH into a four-packet MQTT exchange before transport headers are counted.

Topic length also matters because it is carried in each PUBLISH unless the application uses MQTT 5 topic aliases, which this calculator does not model. Count UTF-8 bytes, not visible characters, when a topic contains non-ASCII text.

What this calculator leaves out

The transport estimate assumes each MQTT control packet fits in one TCP segment and one TLS record. A large PUBLISH can be segmented, which adds more IP and TCP headers than the one-segment estimate. The tool warns when the PUBLISH side of the exchange is larger than a typical 1,500-byte path MTU.

The estimate also excludes TCP-only acknowledgments, retransmissions, fragmentation, Ethernet or cellular framing, broker keep-alives, DNS, TCP connection setup, TLS handshakes, carrier billing increments, topic aliases, WebSocket framing, MQTT-SN, compression, subscriber fanout, and broker-to-client deliveries. Use packet captures or carrier records to calibrate the number before buying a large deployment plan.

Worked example

Suppose each device sends a 100-byte payload on a 20-byte topic once per minute, using MQTT 5.0, QoS 0, IPv4, and 22 bytes of TLS overhead per MQTT packet. MQTT 5 adds a one-byte property length field even with no properties, so the PUBLISH Remaining Length is 2 + 20 + 0 + 1 + 100 = 123 bytes. The fixed header is 1 byte and the Remaining Length field is 1 byte, so the PUBLISH packet is 125 bytes.

QoS 0 adds no MQTT acknowledgments, and one IPv4/TCP/TLS wrapper adds 20 + 20 + 22 = 62 bytes. Each exchange is therefore 187 network bytes. At 60 messages per hour, one device uses 0.26928 MB per day. A 100-device fleet over 30 days uses 807.84 MB per month, averages 2.49 kbit/s, and a 100 MB plan supports 12 devices at the same rate.