Cloud Parts

MQTT

The small publish/subscribe protocol most IoT devices use to talk to a broker, standardised by OASIS and ISO.

What it is
IoT device messaging
Used for
Pub/sub
Type
Open source
Made by
OASIS (open standard)
License
Open standard, free to implement: OASIS Non-Assertion IPR mode; 3.1.1 is also ISO/IEC 20922
Facts checked
6 October 2026
Website

What it is

MQTT is a wire protocol, not a product. A client opens one long-lived connection to a broker (TCP on port 1883, TLS on 8883, or WebSockets) and exchanges small binary packets: CONNECT, PUBLISH, SUBSCRIBE, PINGREQ and their acknowledgements, with a fixed header as small as two bytes. Messages are addressed to topics, slash-separated strings such as plant/pump-7/status, and subscriptions can use wildcards: + matches one level, # everything below. The broker keeps state for each client: its subscriptions, messages in flight at QoS 1 or 2, messages queued for it while it is offline if it has a persistent session, the retained (last) message on each topic, and the will it registered when it connected. The payload is opaque bytes; JSON, Protobuf or anything else is up to the application.

Two versions are in use. 3.1.1, an OASIS Standard since October 2014 and ISO/IEC 20922 since 2016, is supported by every broker in the table below, and Azure IoT Hub supports only that version. 5.0, an OASIS Standard since March 2019, keeps the same model and adds reason codes on every acknowledgement, session and message expiry, shared subscriptions, topic aliases, request/response properties, user properties and flow control. MQTT-SN is a separate variant for sensor networks without TCP/IP, such as Zigbee: it replaces topic names with short IDs, lets devices sleep, and reaches an ordinary broker through a gateway. The specifications are free to implement under the Non-Assertion mode of the OASIS IPR policy, and there is nothing to buy: you run an open-source broker, pay for a commercial one, or use a cloud service.

Why teams pick it

  • Tiny packets and one connection per device suit cellular, satellite and battery-powered hardware
  • Tools for unreliable networks are in the protocol: three QoS levels, persistent sessions, retained messages, last wills and keep-alives
  • Devices dial out to the broker, so the cloud can send commands to devices behind NAT and home firewalls
  • An open standard with many brokers and client libraries (Eclipse Paho and others), so devices aren’t tied to one vendor’s cloud

Watch out for

  • No history: the broker delivers to current subscribers and persistent-session queues and keeps only one retained message per topic; replay needs a stream such as Kafka
  • Cloud brokers implement subsets: AWS IoT Core, IoT Hub, Event Grid and RabbitMQ have no QoS 2, and IoT Hub doesn’t store retained messages, so code written against Mosquitto may not port
  • No payload format or topic naming rules; every project invents its own conventions
  • Security comes from outside the protocol: 3.1.1 only carries a username and password, so TLS, certificates and per-topic permissions depend on the broker

Alternatives

What all iot device messaging have in common →
AWS IoT CoreAWSAWS’s managed MQTT broker for devices, with per-device certificates, a SQL rules engine that routes messages into AWS services, and cloud-side device state.Azure IoT HubAzureAzure’s device gateway: a registry of device identities, telemetry into an Event Hubs-compatible stream, and device twins, direct methods and cloud-to-device messages, sold in fixed-price units with a daily message quota.Eclipse ZenohIncubatingOpen sourceA pub/sub, query and storage protocol that runs peer to peer or through routers, from microcontrollers to the cloud; also a ROS 2 middleware.EMQXCommercialAn Erlang MQTT broker built for very large device fleets, with a SQL rule engine, now under the Business Source License.HiveMQCommercialA Java MQTT broker built for clusters, sold as self-managed software or as HiveMQ Cloud, with an open-source single-node edition.

How it fits with other technologies

Retained messages and a last will with Mosquitto’s command-line clients · bash

# a local broker: the default config in the 2.1 image allows anonymous clients on 1883
docker run -d --name mqtt -p 1883:1883 eclipse-mosquitto:2.1-alpine

# a "device" stays connected, listening for commands, with a last will registered
mosquitto_sub -h localhost -V mqttv5 -i pump-7 -t plant/pump-7/cmd -q 1 \
  --will-topic plant/pump-7/status --will-payload offline --will-qos 1 --will-retain &
DEVICE=$!
mosquitto_pub -h localhost -V mqttv5 -t plant/pump-7/status -m online -q 1 -r

# a dashboard that subscribes later still gets the retained value at once
mosquitto_sub -h localhost -V mqttv5 -t 'plant/+/status' -v &
# plant/pump-7/status online

# the device dies without sending DISCONNECT, so the broker publishes its will
kill -9 $DEVICE
# plant/pump-7/status offline

Brokers and how much of MQTT they support#

Every broker below speaks MQTT, but managed services leave parts out. QoS 2 and retained messages are the usual gaps.

BrokerMQTT versionsQoS 2Retained messagesLicence or model
Eclipse Mosquitto5.0, 3.1.1, 3.1YesYesOpen source, EPL/EDL
EMQX5.0 and 3.xYesYesBusiness Source License 1.1 from 5.9; one production node free
HiveMQ5 and 3.xYesYesCommunity Edition Apache 2.0; Enterprise platform commercial
RabbitMQ (MQTT plugin)5.0, 3.1.1, 3.1No: downgraded to 1 for 3.x clients, refused for 5.0Yes, kept per node; not sent to wildcard subscriptionsOpen source, MPL 2.0
AWS IoT Core5 and 3.1.1, with documented differencesNoYes; only exact-topic subscriptions receive themManaged AWS service
Azure IoT Hub3.1.1 only, with fixed topicsNo: publishing at QoS 2 closes the connectionNot stored; passed to the backend with a flagManaged Azure service
Azure Event Grid MQTT broker5 and 3.1.1NoYes, generally available since April 2026Managed Azure service
  • From each broker’s own documentation, checked 2026-10-06. Mosquitto supports QoS 2 by default (max_qos defaults to 2); EMQX and HiveMQ describe themselves as fully compliant with MQTT 5 and 3.x.

What MQTT 5.0 added#

MQTT 5.0 kept the packets, topics and QoS levels of 3.1.1. These are the additions large deployments use most.

Session and message expiry

The old Clean Session flag became Clean Start plus a Session Expiry Interval, so a client says how long the broker should keep its session after it disconnects. Each message can also carry its own expiry.

Reason codes

Every acknowledgement carries a reason code, and the broker can send DISCONNECT with a reason, so a client finds out why something failed instead of just being cut off.

Shared subscriptions

Several clients can share one subscription and split its messages between them, which turns a topic into a load-balanced work queue for backend consumers.

Topic aliases

A long topic name can be replaced by a small integer after the first message, saving bytes on every publish over a slow link.

Request/response and user properties

Response Topic and Correlation Data properties formalise request/response, and user properties add key/value headers to messages, much like HTTP headers.

Flow control and limits

Client and broker each say how many unacknowledged QoS 1 and 2 messages they accept and the largest packet they take, so a small device isn’t overwhelmed.

See it in a real stack

No architecture uses MQTT yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from1999–2019

In 1999 Andy Stanford-Clark of IBM and Arlen Nipper of Arcom needed to connect oil pipeline equipment over satellite, where bandwidth was expensive and devices ran on batteries. They designed a protocol that kept packets and battery drain to a minimum and named it after IBM’s MQSeries products: MQ Telemetry Transport. Today the name is no longer treated as an acronym, and despite it, MQTT isn’t a message queue.

For about ten years IBM used MQTT mostly inside its own products. In 2010 it published MQTT 3.1 royalty-free, and in 2011 it contributed client code to the Eclipse Foundation’s new Paho project, which gave developers open-source clients in several languages. OASIS took over the specification and approved 3.1.1 as a standard on 29 October 2014, with 65 votes in favour and none against. In 2016 ISO and IEC adopted it as ISO/IEC 20922.

MQTT 5.0 became an OASIS Standard in March 2019, adding what large deployments had been working around: reason codes, expiry, shared subscriptions and user properties. By then MQTT was the device protocol of AWS IoT, Azure IoT Hub and Google’s Cloud IoT Core. Work continues in the OASIS committee on MQTT-SN 2.0, led by HiveMQ engineers.

Why it’s built this way

A broker in the middle
Devices only need to know one address and never each other. Publishers and subscribers are decoupled, so a new backend service can subscribe without touching the devices.
Tiny binary headers
Its first users paid for satellite bandwidth, so the fixed header can be as small as two bytes and protocol exchanges are kept to a minimum.
Three delivery levels, chosen per message
A sensor reading that will be replaced in a second doesn’t need acknowledging, while a billing event must not be lost or doubled. The spec offers at most once, at least once and exactly once, and the sender picks.
A last will for silent failures
Remote devices fail without warning. Keep-alives let the broker notice a dead connection, and the will message tells everyone else about the abnormal disconnection.

Timeline

  1. 1999

    Stanford-Clark and Nipper design MQTT for pipelines over satellite

  2. 2010

    IBM publishes MQTT 3.1 royalty-free

  3. 2011

    IBM contributes MQTT client code to Eclipse Paho

  4. 2014

    OASIS approves MQTT 3.1.1 as a standard on 29 October

  5. 2016

    ISO and IEC publish 3.1.1 as ISO/IEC 20922

  6. 2019

    MQTT 5.0 becomes an OASIS Standard on 7 March

Sources27 · facts checked 6 October 2026

Improve this page on GitHub