What Is MQTT? A Practical Introduction

MQTT (originally MQ Telemetry Transport) is a lightweight messaging protocol built on the publish/subscribe pattern. Clients never talk to each other directly — they send messages to a central broker, labelled with a topic, and the broker forwards each message to every client that subscribed to a matching topic. That simple model is why MQTT runs everything from sensor networks and smart homes to vehicle telemetry and live dashboards.

This introduction explains how MQTT works, what the important features are and when it is (and isn't) the right tool. If you want to follow along, open the online MQTT client in another tab.

A short history

MQTT was designed in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper to monitor oil pipelines over expensive, unreliable satellite links. The design goals — tiny packets, minimal client code, tolerance for flaky networks — turned out to fit the Internet of Things perfectly. MQTT 3.1.1 became an OASIS standard in 2014 (and later ISO/IEC 20922), and MQTT 5.0 followed in 2019 with reason codes, user properties, message expiry and more. Both versions are widely deployed today; see MQTT 5 vs 3.1.1 for the differences.

How MQTT works: publish/subscribe

There are only two roles in MQTT:

• Clients — any program or device that connects to the broker. A client can publish, subscribe, or both. A temperature sensor, a mobile app and a backend service are all just clients.
• The broker — the server that accepts connections, authenticates clients, matches topics and delivers messages. Popular brokers include Mosquitto, EMQX and HiveMQ.

Publishers and subscribers are decoupled: a publisher does not know who (if anyone) receives its message, and subscribers do not know who sent it. They only share a topic name. This makes it easy to add a new consumer — a dashboard, a database writer, an alerting service — without touching the devices that produce the data.

sensor-17  --PUBLISH home/kitchen/temperature "21.5"-->  broker
broker     --PUBLISH home/kitchen/temperature "21.5"-->  dashboard   (subscribed to home/+/temperature)
broker     --PUBLISH home/kitchen/temperature "21.5"-->  logger      (subscribed to home/#)

Topics: the address of a message

A topic is a UTF-8 string with levels separated by slashes, such as factory/line-2/press-4/pressure. Topics are not created in advance — they exist as soon as someone publishes to them. Subscribers can use two wildcards: + matches exactly one level and # matches any number of levels at the end. Good topic design matters a lot for permissions and scaling; our guide to MQTT topics and wildcards covers it in depth.

The connection and its packets

MQTT runs over a long-lived connection — usually TCP, optionally wrapped in TLS, or WebSockets for browsers. The session starts with a CONNECT packet (client ID, optional username and password, keep-alive, Last Will) and the broker answers with CONNACK. After that, the most common packets are:

The fixed header of an MQTT packet is just two bytes, and the payload is opaque binary — JSON, plain text, Protobuf or raw bytes all work. That small overhead is what makes MQTT attractive on constrained devices and metered networks.

Key MQTT features

Quality of Service

Every publish and subscription has a QoS level: 0 (at most once), 1 (at least once) or 2 (exactly once). Higher levels add acknowledgement packets in exchange for stronger delivery guarantees. Details and packet flows are in MQTT QoS levels explained.

Retained messages

A message published with the retain flag is stored by the broker as the last known value of that topic and is delivered immediately to every new subscriber. It is ideal for state like online/offline or the current setpoint. See retained messages.

Last Will and Testament

A client can register a message that the broker publishes on its behalf if the client disappears without a clean disconnect — the standard way to detect offline devices. See Last Will and Testament.

Persistent sessions

With a persistent session (cleanSession=false in 3.1.1, cleanStart=false plus a session expiry interval in MQTT 5), the broker remembers a client's subscriptions and queues QoS 1 and 2 messages while it is offline, delivering them when it reconnects.

Try MQTT in two minutes

The quickest way to understand MQTT is to watch a message go round trip. Connect to a public broker, subscribe to a unique topic and publish to it:

1. Open the online client and connect to a broker from the public broker list.
2. Subscribe to testmqtt/your-name/#.
3. Publish hello to testmqtt/your-name/greeting and watch it arrive.

Try it in the online MQTT client

Or, from a terminal with the Mosquitto clients installed:

# terminal 1
mosquitto_sub -h test.mosquitto.org -t 'testmqtt/intro/#' -v

# terminal 2
mosquitto_pub -h test.mosquitto.org -t 'testmqtt/intro/greeting' -m 'hello'

When to use MQTT (and when not to)

MQTT is a strong fit when:

• Many devices send small, frequent messages (telemetry, sensor readings, status).
• Networks are unreliable or bandwidth is limited, and you need automatic reconnects and offline queuing.
• Data must be pushed to clients in real time instead of polled.
• You want one-to-many fan-out without wiring producers to consumers.

It is a weaker fit when:

• You need request/response with rich semantics — plain HTTP APIs are simpler (MQTT 5 adds response topics, but it is still messaging).
• You need long-term storage or replay of a full event history — that is the job of a log like Kafka or a database fed by MQTT.
• You transfer large files; MQTT can carry them, but it is not designed for it.

For a side-by-side comparison, read MQTT vs HTTP.

Next steps

Now that you know what MQTT is, learn how to choose QoS levels, design a topic hierarchy and test an MQTT broker end to end. All guides live in the MQTT learning center.

Frequently asked questions