MQTT glossary: the core terms, in plain English

MQTT is the protocol most IoT, home-automation, and industrial messaging runs on. The vocabulary is small but precise, and getting a term slightly wrong can send you debugging in the wrong direction. Here are the terms that matter, defined the way they actually behave. Where it helps, there's a short note on how the concept shows up in MQTT Viewer.

What is MQTT?

MQTT (Message Queuing Telemetry Transport) is a lightweight publish/subscribe messaging protocol designed for connecting devices and services over a network. Clients don't talk to each other directly — they exchange small messages through a central broker. Its low overhead makes it a good fit for constrained devices and unreliable or low-bandwidth links, which is why it's common in IoT and sensor networks.

What is an MQTT broker?

An MQTT broker is the server at the centre of every MQTT system. It accepts connections from clients, receives every published message, matches each one against the active subscriptions, and forwards it to the clients that subscribed to the matching topic. Popular brokers include Mosquitto, EMQX, and HiveMQ. The broker also handles authentication, retained messages, and Last Will delivery.

What is an MQTT client?

An MQTT client is any device or application that connects to a broker to publish messages, subscribe to topics, or both. A temperature sensor, a mobile app, a backend service, and a debugging tool are all clients. They never connect to one another — every message passes through the broker.

In MQTT Viewer: the app is itself an MQTT client, and it can hold up to 10 broker connections open at once so you can watch several environments side by side.

What is an MQTT topic?

A topic is the hierarchical string that addresses a message, with levels separated by forward slashes — for example home/livingroom/temperature. Publishers send messages to a topic and subscribers register interest in a topic (or pattern of topics). Topics are created implicitly on first use; there's no separate step to declare them.

What are MQTT topic wildcards (+ and #)?

Wildcards let a single subscription match many topics. The single-level wildcard + matches exactly one level, so home/+/temperature matches every room's temperature but not deeper paths. The multi-level wildcard # matches that level and everything beneath it, and must be the last character — so home/# matches every topic under home. Wildcards are only valid in subscriptions, never when publishing.

In MQTT Viewer: subscribe to # to populate the live topic tree with every topic on the broker at once.

What is publish/subscribe (pub/sub)?

Publish/subscribe is the messaging pattern MQTT is built on. Senders (publishers) and receivers (subscribers) are decoupled: a publisher sends a message to a topic without knowing who, if anyone, is listening, and a subscriber receives messages for a topic without knowing who sent them. The broker routes between them. This decoupling is what lets devices come and go without reconfiguring the rest of the system.

What is QoS 0 in MQTT?

QoS 0 — "at most once" — is the lowest delivery guarantee. The message is sent once with no acknowledgement and no retry. If the network drops it, it's gone. It's the fastest, lightest option and fine for frequent, non-critical data like a stream of sensor readings.

What is QoS 1 in MQTT?

QoS 1 — "at least once" — guarantees the message arrives, but it can arrive more than once. The sender keeps the message until it receives an acknowledgement (PUBACK); if none comes, it resends. Receivers must therefore tolerate occasional duplicates.

What is QoS 2 in MQTT?

QoS 2 — "exactly once" — is the strongest and slowest guarantee. A four-step handshake ensures the message is delivered once and only once, with no duplicates. Use it when duplicate processing would cause real problems, and accept the extra round-trips it costs.

What is a retained message?

A retained message is the last message published to a topic with the retain flag set. The broker stores that single message and delivers it immediately to any client that subscribes to the topic afterwards. This means a new subscriber sees the current value of a topic right away instead of waiting for the next publish — useful for state like a device's last-known status.

In MQTT Viewer: retained values populate the topic tree the moment you subscribe, so the broker's current state is visible instantly.

What is the Last Will and Testament (LWT)?

The Last Will and Testament is a message a client registers with the broker when it connects. If that client disconnects unexpectedly — a crash or dropped connection rather than a clean disconnect — the broker publishes the will message to its designated topic on the client's behalf. It's the standard way to signal that a device has gone offline, often combined with a retained message so the offline state persists.

MQTT 5 vs MQTT 3.1.1

MQTT 3.1.1 is the long-established version that most existing deployments use. MQTT 5 is the current major version and is backward-compatible in spirit while adding capabilities: user-defined properties on messages, reason codes that explain why an operation failed, shared subscriptions, message expiry, topic aliases, and more. Both are widely supported; the right choice usually depends on what your broker and devices already speak.

In MQTT Viewer: both MQTT v3.1.1 and v5 are supported, including publishing messages with MQTT v5 properties and headers.

What is Sparkplug B?

Sparkplug B is an open specification that defines a standard topic structure and a protobuf-based payload format on top of MQTT, aimed at industrial (IIoT) use. Because the payloads are encoded protocol buffers rather than plain text, they need to be decoded to be human-readable.

In MQTT Viewer: Sparkplug B (protobuf) payloads are decoded automatically, alongside Base64 and Hex.

What is keep-alive in MQTT?

Keep-alive is an interval, agreed at connection time, within which the client must send some packet to the broker. If nothing else is being sent, the client sends a small PINGREQ to prove it's still there. If the broker hears nothing for roughly 1.5 times the keep-alive interval, it treats the client as disconnected and triggers its Last Will. It's how MQTT detects half-open connections that would otherwise look alive.

What are clean and persistent sessions?

A session is the broker's memory of a client: its subscriptions and any queued messages. With a clean session, the broker discards all of that when the client disconnects, so the client starts fresh every time it reconnects. With a persistent session, the broker keeps the subscriptions and queues QoS 1 and 2 messages while the client is away, then delivers them on reconnect. MQTT 5 expresses this with a session-expiry interval rather than a single clean/persistent flag, giving finer control over how long state survives.

Frequently asked questions

Put the concepts to work

These terms come alive once you watch real traffic. Connect MQTT Viewer to a broker and subscribe to # to see topics, retained values, and QoS in action. For hands-on walkthroughs, see debugging an ESP32 over MQTT or working with Home Assistant and MQTT. To pick a client, compare the best MQTT clients or read the full MQTT client comparison, then download MQTT Viewer — it's free, open-source, and runs on macOS, Windows, and Linux.