What Is MQTT? Ultimate Guide with 7 Real-World IoT Uses
What Is MQTT? Ultimate Guide with 7 Real-World IoT Uses
So, what is MQTT, and why does so much of the IoT world quietly depend on it? It is a messaging protocol built to move tiny messages between devices and servers over slow, costly or unreliable links. A sensor hands its reading to a middleman called a broker. The broker passes it on to anyone who asked for it.
This guide from IoT Insights Hub answers one question: what is MQTT? It then covers how the protocol works, what its three delivery levels mean, how it compares with HTTP and where it falls short. Where sources disagree, the text says so.
New to connected devices? Read our beginner guide to IoT first. Our guide on what is LoRaWAN covers the radio layer, while MQTT works higher up, at the messaging layer.
What is MQTT and why do IoT devices use it?
MQTT, short for Message Queuing Telemetry Transport, is a lightweight publish-subscribe protocol for sending small messages between devices and servers. Devices connect to a central broker over TCP, publish data to named topics and subscribe to the topics they care about. It suits low-bandwidth, unreliable networks, which is why IoT adopted it.
According to HiveMQ’s history of the protocol, Arlen Nipper of Arcom Control Systems and Andy Stanford-Clark of IBM drew up the first version at the start of 1999. Its original name was the Argo Lightweight On The Wire Protocol.
The goal was practical. HiveMQ says the pair wanted to escape a legacy of literally hundreds of proprietary poll/response protocols used for industrial devices.
Paessler’s history adds a vivid use case: managing oil pipeline components remotely via satellite. Paessler dates the first version to 1998, so sources differ by a year. ANSI’s report on the standard also says 1999.
From there, the protocol grew up fast. IBM and Eurotech published MQTT 3.1 in 2010, per HiveMQ. The OASIS specification for version 3.1.1 is dated 29 October 2014, and ISO/IEC JTC 1 later approved it as ISO/IEC 20922, according to ANSI. Version 5.0 became an OASIS Standard on 7 March 2019.
IoT adopted it for its small size. Wikipedia notes that a minimal MQTT control message can be as little as two bytes, and the protocol only needs a transport that delivers data in order without loss, typically TCP/IP. IoT Insights Hub treats it as the default choice when a device must send little data, often, over a poor connection.
How does MQTT work? Publishers, brokers and topics
MQTT works through three roles: publishers, a broker and subscribers. A publisher sends a message to a named topic on the broker. The broker checks who subscribed to that topic and forwards the message to them. Publishers and subscribers never talk directly, so either side can change without breaking the other.
The MQTT message path: one publish, any number of subscribers.
Topics are the addressing system. They are text paths split by forward slashes, such as sensors/temperature/livingroom, per HiveMQ’s topic guide. A subscriber can use a + to match one level or a # to match everything below a point. Wildcards work for subscribing only, not for publishing.
Three features matter when you pick a broker:
- Retained messages: The OASIS specification defines a RETAIN flag so the broker can hold the latest message on a topic. A new subscriber then gets a current value straight away.
- Last Will: If a client’s network connection closes abnormally, the server publishes its Will Message, per OASIS. Other clients learn that the device dropped off.
- Session expiry (MQTT 5): If the interval is absent, the session ends when the connection closes. The maximum value means the session never expires.
Topic design matters more than newcomers expect. HiveMQ advises short topics, no leading slash, no spaces and a unique client ID inside the path so you can control who publishes. Topics are case-sensitive, so myhome/temperature and MyHome/Temperature are different. For the layers above and below the broker, see our IoT architecture guide.
What are the 3 MQTT QoS levels?
MQTT has three Quality of Service levels. QoS 0 delivers a message at most once, with no guarantee. QoS 1 delivers at least once, so duplicates can occur. QoS 2 delivers exactly once through a two-level handshake, with more messages on the wire.
| Level | OASIS name | What it promises | Duplicates? | Good fit (our view) |
|---|---|---|---|---|
| QoS 0 | At most once | Best effort. Message loss can occur. | No | Frequent readings where one miss is fine |
| QoS 1 | At least once | Delivery is assured. | Yes | Alerts and status updates |
| QoS 2 | Exactly once | Delivery is assured, once only. | No | Commands where a repeat causes harm |
In practice, QoS works as a dial for delivery certainty. Wikipedia describes QoS 0 as “fire and forget”, QoS 1 as acknowledged delivery and QoS 2 as assured delivery. The extra certainty costs extra traffic. That matters on a battery, and our guide to energy-efficient IoT protocols covers the trade-offs.
Check your platform before you design around QoS 2. AWS IoT Core supports QoS 0 and 1 only. When a client requests QoS 2, the broker does not send a PUBACK or SUBACK, per AWS documentation. IoT Insights Hub’s rule of thumb: QoS 0 for chatty sensor readings, QoS 1 for alerts, QoS 2 only when a duplicate would hurt.
MQTT vs HTTP: which one suits IoT better?
MQTT keeps one connection open and pushes messages to subscribers as they happen, while HTTP opens a request, waits for a reply and closes. That makes MQTT lighter for frequent small updates and for sending commands to devices. HTTP stays simpler for occasional uploads and for anything a web browser must read directly.
| Feature | MQTT | HTTP |
|---|---|---|
| Model | Publish-subscribe through a broker | Request and response |
| Connection | Persistent session, resumes after a drop | A new request, and often a new handshake, each time |
| Sending to a device | Built in: the device subscribes | Needs polling or a workaround |
| Delivery guarantees | QoS 0, 1 or 2 | None at protocol level |
| Message size | A control message can be 2 bytes | Text headers on every request |
| Setup | Needs a broker and its ports open | Works through almost every firewall |
The connected-car case shows the gap. A HiveMQ article by Ian Skerrett (October 2020) says MQTT can keep a persistent session through a cellular dead zone, while HTTP needs a costly new handshake. It also says cloud-to-vehicle messaging is complicated over HTTP. HiveMQ reports that some customers saw a 30% drop in network traffic.
That said, HiveMQ sells MQTT infrastructure, and the 30% figure comes from unnamed customers. Treat it as a vendor claim. HTTP is not the villain. For a device that uploads one reading an hour, plain HTTPS is often enough.
So what is MQTT’s real edge over HTTP? It pushes data to devices without polling. IoT Insights Hub would pick it for any fleet that needs two-way messaging, and keep HTTPS for simple uploads.
What is MQTT used for? 7 real-world IoT uses
MQTT suits any job that needs small, frequent messages over unreliable links. Common uses include connected cars, messaging apps, smart homes, connected appliances, delivery drones, air quality monitors and cloud IoT platforms. IoT Insights Hub notes that most named examples below come from MQTT vendors and platform documentation, so read the figures as industry-reported.
- Connected cars: InfluxData reports that a BMW car-sharing service built on MQTT manages more than 14,000 vehicles in 18 cities. HiveMQ says eCarx, a Geely subsidiary, has over 2 million cars connected with MQTT.
- Messaging apps: Per InfluxData, Facebook Messenger chose MQTT over HTTP and maps group chats to MQTT topics. Instagram uses it for push notifications.
- Smart homes: Home Assistant and Node-RED both ship MQTT integrations, per InfluxData.
- Connected appliances: Winterhalter, a German maker of industrial dishwashers, uses HiveMQ to offer value-added services on connected machines.
- Medical delivery drones: Matternet uses MQTT for real-time drone tracking, which regulatory approval required, per HiveMQ.
- Air quality monitoring: Awair processes over 100 million MQTT messages a day, HiveMQ reports. It had first tried building its own broker and struggled to scale.
- Cloud IoT platforms: AWS IoT Core builds on the MQTT 3.1.1 and 5.0 specifications “with some differences”, per its documentation.
Across all seven, what is MQTT doing? Moving small messages between many parties over shaky links.
An alert nobody reads is worthless. IoT Mail Bridge explains how a middleware layer turns MQTT device messages into email triggers in its guide to setting up IoT email automation. For fleet alerts at scale, see its write-up on a reliable SMTP relay for IoT and M2M fleet alerts.
A note for founders: building an IoT product? The Business Perspective tracks the money side. Its Q3 2026 venture funding analysis flags that 64% of funding went to AI in its headline finding, and its Indian startup funding report for Q3 2026 covers 63 deals.
Is MQTT secure? Ports, TLS and common mistakes
MQTT is only as secure as the way you set it up. The protocol does not encrypt traffic by itself: IANA lists port 1883 for plain MQTT and 8883 for secure MQTT over TLS. Always use TLS, give every client its own credentials, and restrict which clients can publish to which topics.
Plain MQTT hides nothing. Wikipedia states that it sends connection credentials in plain text and has no security measures of its own, though TLS can protect against interception, modification and forgery. The OASIS specification says implementations should offer authentication, authorization and secure communication options. It strongly advises using them for sensitive data.
The exposure is real. Airbus Protect reported in June 2024 that Shodan had indexed 606,533 brokers on default port 1883. That counts reachable brokers, not confirmed open ones, and Airbus did not publish how many lacked authentication. Still, an internet-facing broker without a password is an open door.
- Use port 8883 with TLS instead of 1883 wherever you can.
- Give each client its own credentials or certificate.
- Put the client ID in the topic path and limit who may publish where, as HiveMQ advises.
- Avoid blanket # subscriptions in production. HiveMQ warns they can overload a client.
- Keep sensitive details out of topic names.
For wider device-security habits, read our guide to IoT security risks and how to fix them. IoT Mail Bridge covers the data-in-transit side in its piece on edge-to-cloud data security for IoT fleets.
What do critics say about MQTT?
Critics name four recurring weaknesses: no enforced payload format, a broker that can become a single point of failure, no built-in receiver acknowledgment and security that depends entirely on configuration. Supporters reply that MQTT was designed to be small and unopinionated, and that careful topic design, TLS and a resilient broker setup handle most of these problems.
- No standard payload: FlowFuse, a vendor with its own product, says MQTT lacks enforced data-format standardization. Consumers cannot predict message structure, so teams add transformation work.
- The broker: FlowFuse also says the central broker can disrupt the whole data flow if it fails, and proprietary features can make switching providers hard.
- Acknowledgment: FlowFuse argues there is no built-in receiver acknowledgment. QoS applies on each hop, so confirming that the final application processed a message needs extra design.
- Tiny devices: A persistent TCP connection needs processing power and memory that some low-powered devices lack, per FlowFuse. Wikipedia points to MQTT-SN, a variant for battery-powered devices on non-TCP/IP networks.
- Broker differences: Researchers at Sapienza University of Rome (Di Paolo, Bassetti and Spognardi) tested five open-source brokers in more than 60 experiments. They found no very critical flaws, but several brokers deviated from the standard. All except Mosquitto failed the unique packet identifier check in a QoS 2 test, and they rated Mosquitto the safest.
Platforms also trim the standard. AWS IoT Core drops QoS 2 and caps packet size at 128 KB, per its documentation.
Both camps agree on one point: test your broker against your real workload before you commit. If your fleet mixes protocols, our guide to multi-protocol IoT systems shows how to combine them.
MQTT FAQs
What is MQTT in simple words?
MQTT is a lightweight messaging system for connected devices. Think of a noticeboard: devices pin messages under a heading called a topic, and anyone who subscribed to that heading gets a copy. A central server called a broker handles the pinning and delivery. It was built to work on slow or unreliable links.
Is MQTT better than HTTP for IoT?
For frequent small updates and for sending commands to devices, usually yes. MQTT keeps one connection open and pushes messages as they happen. HTTP is simpler, works through almost every firewall and needs no broker. For a device that uploads one reading an hour, plain HTTPS is often enough.
Which port does MQTT use?
The IANA registry lists port 1883 for MQTT and port 8883 for secure MQTT. Port 1883 carries traffic and credentials unencrypted unless you add protection yourself. Use 8883 with TLS wherever possible, and avoid exposing port 1883 to the open internet without authentication.
Does MQTT need the internet to work?
No. The broker can run on your own local network, so devices exchange messages with no public internet at all. You need internet access only when the broker lives in the cloud or when remote users must reach your data. Plan your firewall rules before you open any port.
What changed in MQTT 5 compared with 3.1.1?
MQTT 5.0 became an OASIS Standard on 7 March 2019. Per the specification, its goals include better error reporting, user properties for extra metadata, and improvements for small clients. It also adds reason codes, shared subscriptions and session expiry control. Check that your broker supports it before you upgrade.
Is MQTT free to use?
The specification is an open OASIS standard, and several brokers are open source. A Sapienza University study of open-source brokers tested Mosquitto, EMQX, HiveMQ, Moquette and Aedes. Managed cloud brokers charge for hosting and scale, so budget for infrastructure and support, not for the protocol itself.
Sources behind this what is MQTT guide from IoT Insights Hub
- OASIS, MQTT Version 5.0 specification (OASIS Standard, 7 March 2019)
- HiveMQ, “The History of MQTT, Part 1: The Origin”
- Paessler, “From Oil Pipelines to the IoT: A Brief History of MQTT”
- ANSI, “ISO/IEC JTC 1 approves OASIS MQTT Internet of Things standard” (August 2016)
- IANA, Service Name and Transport Protocol Port Number Registry (mqtt 1883, secure-mqtt 8883)
- Wikipedia, “MQTT”
- HiveMQ, “MQTT Essentials Part 5: MQTT Topics and Best Practices”
- HiveMQ, “MQTT Standard for Connected Car” (Ian Skerrett, 29 October 2020)
- HiveMQ, “Real-World Examples of HiveMQ and MQTT”
- InfluxData, “8 Real-World MQTT Use Cases”
- AWS, IoT Core developer guide, “MQTT”
- Airbus Protect, “Exposing MQTT hidden talks” (28 June 2024)
- FlowFuse, “Common Pitfalls of Using MQTT in Industrial Data Operations”
- Di Paolo, Bassetti and Spognardi, “Security assessment of common open source MQTT brokers and clients” (arXiv 2309.03547)
Is MQTT the right protocol for your next IoT project?
Pick MQTT when devices send small messages often, links are unreliable and several systems need the same data. Pick plain HTTPS when uploads are rare and simple. Either way, secure the connection and test your broker under real load.
IoT Insights Hub will keep publishing practical guides on IoT protocols, networks and security. For the business side of building in this space, read The Business Perspective’s guide to raising seed funding. In plain terms, what is MQTT? A small messaging layer that has been in use for more than two decades.
About The Author
1 thought on “What Is MQTT? Ultimate Guide with 7 Real-World IoT Uses”
Comments are closed.