MQTT is a lightweight messaging protocol designed to let IoT devices send and receive data efficiently, even on low-power hardware or unreliable networks. It stands for Message Queuing Telemetry Transport and is an official OASIS standard, with the current version (5.0) approved in May 2018. If you have sensors, smart home gadgets, or industrial equipment that need to communicate over the internet, MQTT is likely the protocol making that happen.
How the Publish-Subscribe Model Works
MQTT uses a pattern called publish-subscribe, which is fundamentally different from the request-response model you’re used to with web browsing. Instead of one device asking another for data directly, all communication flows through a central middleman called a broker.
Here’s the flow: a device that has data to share (a temperature sensor, for example) publishes a message to the broker under a specific topic, like “warehouse/floor2/temperature.” Any device that cares about that data subscribes to that topic. The broker then routes the message to every subscriber. The publisher and subscriber never need to know each other exist. They only need to know the broker’s address.
This decoupling is what makes MQTT so practical for IoT. A sensor doesn’t need to track which dashboards, apps, or databases want its data. It just publishes, and the broker handles distribution. Devices can go offline and reconnect without breaking the system. New subscribers can be added at any time without reconfiguring the publisher.
Topics and Wildcards
Topics are simple text strings organized in a hierarchy using forward slashes, similar to file paths on a computer. A smart home setup might use topics like “home/kitchen/lights” or “home/garage/door.” Topics are case-sensitive, so “Home/Kitchen” and “home/kitchen” are entirely different channels.
Wildcards let subscribers listen to multiple topics at once. The plus sign (+) matches a single level, so subscribing to “home/+/temperature” would capture messages from “home/kitchen/temperature” and “home/bedroom/temperature” alike. The hash sign (#) matches everything below a certain level. Subscribing to “home/#” captures every message published under “home,” regardless of how many levels deep it goes. These two characters are reserved for wildcards and can’t be used in topic names.
Quality of Service Levels
Not every message matters equally. A temperature reading sent every five seconds doesn’t need the same delivery guarantee as a fire alarm. MQTT handles this with three Quality of Service (QoS) levels that let you choose the right tradeoff between reliability and speed.
- QoS 0 (at most once): The message is sent once with no confirmation. If it gets lost, nobody retries. This is the fastest and lightest option, sometimes called “fire and forget.”
- QoS 1 (at least once): The broker acknowledges receipt. If no acknowledgment arrives, the message is resent. This guarantees delivery but may produce duplicates.
- QoS 2 (exactly once): A four-step handshake ensures the message arrives once and only once. This is the most reliable but slowest option, useful when duplicates would cause problems.
Why MQTT Beats HTTP for IoT
Most web communication uses HTTP, which works beautifully for loading web pages but carries significant overhead per message. Every HTTP request includes headers that can dwarf the actual data being sent. When you’re transmitting thousands of tiny sensor readings, that overhead adds up fast. MQTT strips communication down to a minimal packet structure, making it far more efficient for the small, frequent messages typical in IoT.
The power savings are measurable. A 2023 study published in the journal Sensors tested both protocols during long-duration cold chain monitoring (tracking temperatures during cargo transport). MQTT with QoS 1 consumed 614 milliwatts on average compared to HTTP’s 670 milliwatts, a savings of about 8.3%. In practical terms, a battery that lasted 107 hours on HTTP lasted 117 hours on MQTT. Those extra 10 hours matter when you’re monitoring a refrigerated shipment across a continent.
Last Will and Testament
IoT devices operate in unpredictable environments. A sensor might lose its network connection, run out of battery, or simply crash. MQTT has a built-in mechanism called Last Will and Testament (LWT) to handle this gracefully. When a device first connects to the broker, it can register a “last will” message. If the broker later detects that the device has disconnected unexpectedly (through a network failure, a missed keepalive signal, or a connection closed without a proper disconnect packet), it automatically publishes that stored message to a designated topic.
This means other devices or monitoring systems instantly learn that something went offline. If the device disconnects normally using the proper disconnect command, the broker simply discards the last will message. It’s an elegant solution to one of IoT’s most persistent headaches: knowing when a remote device has gone silent.
Security in MQTT
MQTT supports encrypted connections using TLS (the same encryption that protects HTTPS websites). Port 8883 is the standardized port for secure MQTT connections, officially registered with IANA as “secure-mqtt.” On top of transport encryption, brokers typically support username and password authentication to control which devices can connect.
For devices too constrained to handle full TLS encryption (some very low-power microcontrollers fall into this category), an alternative approach is encrypting just the message payload before sending it. This doesn’t protect the connection metadata but keeps the actual sensor data private. In production systems, layering TLS with payload-level encryption and access control provides the strongest protection.
What Changed in MQTT 5.0
Version 3.1.1 served as the IoT workhorse for years, but MQTT 5.0 introduced several features that address real-world pain points at scale.
Shared subscriptions let multiple instances of the same application split the incoming message load from a topic, which is essential for cloud-based systems that need to scale horizontally. Previously, every subscriber received every message, which created bottlenecks when millions of devices were publishing simultaneously.
Session and message expiry settings let developers define how long undelivered messages and inactive sessions should persist. If a message isn’t delivered within a set time window, the broker automatically deletes it rather than letting stale data pile up.
Topic aliases replace long topic strings with short integer values after the first exchange, reducing the bytes sent with every subsequent message. For devices sending data every few seconds over metered cellular connections, this trimming adds up. Negative acknowledgments let brokers explicitly reject messages that violate size limits or use unsupported features, replacing the silent failures of earlier versions with clear error reporting. User properties allow developers to attach custom key-value metadata to message headers, making it easier to route and process messages without parsing the payload itself.
Common IoT Applications
MQTT shows up anywhere devices need to report data frequently over constrained connections. Smart home platforms use it to coordinate lights, thermostats, door sensors, and security cameras through a central hub. Industrial monitoring systems rely on it to collect readings from hundreds of sensors on a factory floor, tracking vibration, temperature, and pressure in real time. Cold chain logistics use MQTT to transmit temperature and humidity data from refrigerated trucks and shipping containers, where cellular connectivity may be intermittent and battery life is critical.
Home automation systems built on MQTT can handle real-time monitoring for fire, smoke, and gas leaks alongside routine tasks like tracking appliance usage and backing up data to the cloud. The protocol’s ability to function on unstable internet connections makes it particularly valuable in transportation and remote environments where standard cloud-based approaches would fail.