What is the MQTT Protocol? How IoT Devices Communicate

Picture this: it's 11 PM, your smart plug notices the living room light has been left on, and within half a second, your phone buzzes with a notification asking if you want to turn it off. 

No app was being refreshed every few seconds. No constant back-and-forth handshake between your phone and the plug. Somehow, the message just... arrived.

That "just arrived" feeling is powered by a quiet little protocol called MQTT (Message Queuing Telemetry Transport), and once you understand how it works, you'll start noticing it behind almost every smart device you own.

MQTT allows devices to send and receive information instantly while consuming very little bandwidth and power. That is why it has become one of the most widely used communication protocols in IoT.

In this beginner-friendly guide, you'll learn what MQTT is, why it was created, how it works, and why companies around the world rely on it to power smart devices.

What is MQTT?

MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol that lets devices send and receive data over a network using a publish-subscribe model instead of direct one-to-one requests.

Think of MQTT less like a phone call and more like a magazine subscription service.

• A magazine publisher doesn't call each subscriber individually to deliver an issue.
• Instead, the publisher sends the magazine to a distribution centre.
• The distribution centre delivers it to everyone who has subscribed to that particular magazine category.
• The publisher never needs to know who the subscribers are, and the subscribers never need to contact the publisher directly.

In MQTT terms:

• The publisher is a device sending data (like a temperature sensor).
• The distribution centre is called the broker.
• The subscribers are apps or devices that want that data (like your phone's dashboard).

This single design decision, never connecting devices directly, is what makes MQTT so efficient, and it's the foundation everything else builds on.

The Three Main Characters of MQTT

1. The Publisher

Any device or sensor that has data to share. Example: a smart thermostat measuring room temperature.

2. The Broker

The middleman that receives every message and decides where it should go. It's less like a person and more like a post office sorting room, messages come in, get sorted by "address" (called a topic), and go out to the right recipients.

Popular brokers you'll encounter in the real world: Mosquitto, HiveMQ, EMQX, and AWS IoT Core.

3. The Subscriber

Any app, dashboard, or device that wants to receive certain data. Example: a mobile app showing you your home's current temperature.

Here's the twist beginners often miss: A single device can be both a publisher and a subscriber at the same time. Your smart thermostat might publish the current temperature and subscribe to a topic that tells it when to turn the heater on.

What is an MQTT Client and Broker?

Two words you'll see everywhere in MQTT: client and broker. Here's the simplest way to think about them.

Client = any device or app that connects to send or receive messages. A sensor, a mobile app, and a server are all just "clients." The same client can both send messages and receive messages; it's not locked into one role.

Broker = the middleman server that every client connects to. It receives messages, checks who wants them, and forwards them to the right clients.

That's really it. One simple rule ties them together:

Clients never talk to each other directly. Everything passes through the broker.

A quick analogy: think of the broker as a group chat admin, and clients as the people in the chat. Nobody messages each other one-on-one; everyone sends their message to the group, and the admin (broker) makes sure it reaches everyone who's supposed to see it.

Popular brokers used in real projects: Mosquitto (simple, great for learning), HiveMQ and EMQX (built for large-scale use), and AWS IoT Core (managed, cloud-based).        

Important MQTT Terms You Should Know

To understand MQTT communication, you need to know a few basic terms:

• Topic: A unique address where messages are sent, such as home/livingroom/temperature.
• Publisher: The device that sends data (for example, a temperature sensor).
• Subscriber: The device or app that receives data by subscribing to a topic.
• Wildcard (+): Matches one level in a topic (e.g., home/+/temperature).
• Wildcard (#): Matches all topics under a specific path (e.g., home/#).

These terms help MQTT send the right data to the right devices while keeping communication fast and efficient.

How MQTT Knows Who Gets What?

If the broker is the post office, topics are the addresses written on every envelope.

A topic is just a string that describes what the message is about, structured like a folder path:

home/livingroom/temperature
home/kitchen/humidity
factory/line1/machine3/status

A subscriber says, "I want everything about home/livingroom/temperature," and the broker only sends them messages published to that exact topic.

Wildcards: Subscribing to Groups of Topics

MQTT also lets you subscribe to groups of topics using two special characters:

• (+) matches exactly one level. Example: subscribing to home/+/temperature gets you temperature updates from the living room, kitchen, and bedroom all at once, but not humidity data.
• (#)matches everything below that point. Example: subscribing to home/# gets you every single message from every room and every sensor type in the house.

Think of (+) as "any single folder here" and # as "this folder and everything inside it, no matter how deep."

Quality of Service (QoS): How Sure Do You Need to Be?

Not every message is equally important. A routine temperature reading every 10 seconds isn't a big deal if one gets lost. But a "fire alarm triggered" message absolutely cannot go missing.

MQTT solves this with three Quality of Service (QoS) levels, think of them as different levels of certainty you'd want when sending a text message:

Higher QoS means stronger guarantees, but also more network overhead, so IoT engineers pick the lowest QoS that still gets the job done.

Why is MQTT the Best Communication Protocol for IoT?

Put all of the above together, and you get a protocol tailor-made for the constraints real IoT devices face:

• Tiny footprint: the message header can be as small as 2 bytes, ideal for microcontrollers with very little memory.
• Battery-friendly: devices maintain one lightweight, persistent connection instead of repeatedly opening and closing connections as HTTP does.
• Works on flaky networks: built-in reconnection, message queuing, and QoS levels handle unreliable rural, industrial, or cellular connections gracefully.
• Scales to thousands of devices: because publishers and subscribers never talk directly, adding a new subscriber doesn't require touching the publisher's code at all.
• Bi-directional by design: the same device can send sensor readings out and receive commands in, over the same connection.

How MQTT Works: Smart Doorbell Example?

Let's tie it all together with one relatable walkthrough.

1. Someone presses your smart doorbell. It publishes a message to the topic home/frontdoor/doorbell with the payload "pressed".
2. Your broker (say, running on a small home hub) receives this message and checks who's subscribed to that topic.
3. Your phone app and a wall-mounted smart display are both subscribed to home/frontdoor/doorbell, so the broker instantly forwards the message to both.
4. Your phone buzzes, and the display lights up, practically simultaneously, even though the doorbell never talked to either device directly.

If your phone happened to be offline at that exact moment (say, in a dead zone), and the doorbell had QoS 1 or 2 configured, the broker would hold onto the message and deliver it the moment your phone reconnects.

Code

Here's a simplified example of what publishing and subscribing looks like in JavaScript using the popular mqtt library, broken down piece by piece so it's not intimidating.  

const mqtt = require('mqtt');

// 1. Connect to a broker
const client = mqtt.connect('mqtt://broker.example.com');

// 2. Once connected, subscribe to a topic
client.on('connect', () => {
  client.subscribe('home/frontdoor/doorbell');
});

// 3. Whenever a message arrives on a subscribed topic, this fires
client.on('message', (topic, message) => {
  console.log(`Someone rang the bell! Topic: ${topic}, Message: ${message.toString()}`);
});

// 4. Publish a message (simulating the doorbell being pressed)
client.publish('home/frontdoor/doorbell', 'pressed');

Walking through it:

• Line 1-2: The device connects to a broker, just like dialling into a shared phone line.
• Line 5-7: It subscribes to a topic, telling the broker, "let me know whenever something happens here."
• Line 10-12: The message event is the "phone ringing" moment, it fires automatically whenever a relevant message arrives.
• Line 15: Publishing is a single line, the device doesn't need to know or care who's listening.

That simplicity, one line to publish, one listener to receive, is exactly why MQTT is so popular among IoT developers.

Frequently Asked Questions (FAQs)