MQTT in one paragraph
MQTT (originally MQ Telemetry Transport) is an open, lightweight publish/subscribe messaging protocol that runs on top of TCP/IP. It was designed for devices with limited processing power and for networks with low bandwidth, high latency or unreliable connections. Its small packet overhead, simple client implementation and efficient use of battery and data make it the most widely used protocol for the Internet of Things (IoT) and machine-to-machine (M2M) communication.
MQTT is an official OASIS standard and is also published as the international standard ISO/IEC 20922.
How publish/subscribe works
In a classic client-server model, each client talks directly to the server it needs. MQTT uses a different model: clients never talk to each other directly. Instead, every client connects to a central server called the broker.
- A publisher sends a message to a named topic, for example
home/livingroom/temperature. - A subscriber tells the broker which topics it is interested in.
- The broker receives every message and forwards it to all clients subscribed to that topic.
Publishers and subscribers do not need to know about each other, do not need to be online at the same time in every case, and can be added or removed without changing the rest of the system. A single client can be both a publisher and a subscriber.
Topics and wildcards
A topic is a UTF-8 string made of levels separated by a forward slash /. Topics are created on the fly — there is no need to register them in advance. Good topics go from general to specific:
farm/greenhouse-1/soil/moisture
Subscribers can use two wildcards to receive messages from many topics at once:
| Wildcard | Meaning | Example | Matches |
|---|---|---|---|
+ | Exactly one level | home/+/temperature | home/kitchen/temperature, home/bedroom/temperature |
# | Any number of levels (must be last) | home/# | home/kitchen/temperature, home/door/front |
Best practices: do not start topics with /, avoid spaces and special characters, keep names short and meaningful, and include a device or location ID so that you can filter easily. Topics that start with $ (such as $SYS/) are reserved for broker information.
Quality of Service (QoS)
MQTT defines three delivery guarantees. The QoS level is chosen per message by the publisher and per subscription by the subscriber.
| Level | Guarantee | Best for |
|---|---|---|
| QoS 0 | At most once — the message is sent once with no acknowledgment. | Frequent sensor readings where losing a single value is acceptable. |
| QoS 1 | At least once — the message is resent until acknowledged; duplicates are possible. | Most applications: alerts, status updates, commands that can be repeated safely. |
| QoS 2 | Exactly once — a four-step handshake guarantees a single delivery. | Critical operations such as billing or commands that must never be duplicated. |
Higher QoS levels add more network traffic, so choose the lowest level that meets your needs. MQTT One supports all three levels.
Key features you should know
Retained messages
When a message is published with the retain flag, the broker stores the last message of that topic and sends it immediately to any new subscriber. This is ideal for states such as "the light is on" or the last known sensor value.
Last Will and Testament (LWT)
When connecting, a client can register a "last will" message. If the client disconnects unexpectedly — for example because of a power loss — the broker publishes this message on its behalf, so other clients know the device went offline.
Keep alive
Clients and the broker exchange small ping packets to detect broken connections, even when no data is sent. A typical keep-alive interval is 30 to 60 seconds.
Persistent sessions
A client that connects with a persistent session (clean session = false) and a fixed client ID can receive the QoS 1 and 2 messages it missed while it was offline.
Security
MQTT provides several layers of security:
- Authentication with a username and password sent in the CONNECT packet.
- Authorization through access rules (ACL) that define which topics a user may publish or subscribe to.
- Encryption with TLS — standard port
8883, or secure WebSocket for browsers.
Always use TLS when your data travels across public networks, give each device its own credentials and keep passwords out of public source code.
MQTT versions
| Version | Year | Highlights |
|---|---|---|
| MQTT 3.1 | 2010 | Openly published royalty-free specification. |
| MQTT 3.1.1 | 2014 | OASIS standard, later ISO/IEC 20922. The most widely supported version today. |
| MQTT 5.0 | 2019 | Reason codes, user properties, shared subscriptions, message expiry, topic aliases and request/response. |
MQTT One supports MQTT 3.1 and 3.1.1, which every common client library implements.
Standard ports
The IANA has registered port 1883 for MQTT and port 8883 for MQTT over TLS. Brokers commonly offer WebSocket access as well so that web browsers can connect. MQTT One provides:
| Port | Protocol |
|---|---|
1883 | MQTT over TCP |
8883 | MQTT over TLS |
8083 | MQTT over WebSocket (path /mqtt) |
8084 | MQTT over secure WebSocket (path /mqtt) |
A short history
MQTT was created in 1999 by Andy Stanford-Clark of IBM and Arlen Nipper of Arcom (now Eurotech) to monitor oil pipelines over expensive satellite links. The goal was a protocol that used very little bandwidth and battery power. IBM later released the specification royalty-free, the Eclipse Paho project provided open-source clients, and in 2014 MQTT 3.1.1 became an OASIS standard. Today MQTT is used in smart homes, connected cars, industrial automation, logistics, healthcare and countless other fields.
Ready to try it? Follow the quick start guide and send your first message to MQTT One in a few minutes.