Articles · October 18, 2026
MQTT 5 vs MQTT 3.1.1: what changed and should you care?
MQTT 3.1.1 has powered IoT for over a decade, and most hobby libraries still default to it. MQTT 5, standardized by OASIS in 2019, keeps the same publish/subscribe model but fixes many of 3.1.1's blind spots. Here is what changed, and when it is worth switching.
Reason codes: finally knowing what went wrong
In 3.1.1, a failed connection returns one of five codes, and a rejected publish or subscription often looks like silence. MQTT 5 adds reason codes to almost every acknowledgment: bad credentials, not authorized, quota exceeded, topic name invalid, payload too large. When your device misbehaves, MQTT 5 tells you why.
Session and message expiry
3.1.1 sessions are either clean or kept forever, so a device that never comes back leaves a session queuing messages on the broker. MQTT 5 lets the client set a session expiry interval. Message expiry lets a publisher say that a reading is worthless after, say, 60 seconds, so a device that reconnects tomorrow doesn't receive yesterday's commands.
Shared subscriptions
With $share/group/topic, several subscribers split the messages between them instead of each getting a copy. That is how you load-balance a worker pool. It was a vendor extension in 3.1.1 and is standard in MQTT 5.
Topic aliases
Long topic names cost bytes on every publish. MQTT 5 lets the client map a topic to a small integer once and then send just the number. On slow or metered links, that adds up.
User properties
MQTT 5 messages can carry user properties, key/value pairs much like HTTP headers. Use them for a schema version, a trace ID or units, without wrapping every payload in an envelope.
Request/response
MQTT 5 standardizes the pattern with a response topic and correlation data on the request. A dashboard can ask a device for its status and match the reply to the question. You can do this in 3.1.1 with conventions; MQTT 5 makes it explicit.
Other improvements
- Flow control: clients and servers announce how many unacknowledged QoS 1 and 2 messages they can handle.
- Maximum packet size: both sides can refuse messages that are too big, cleanly.
- Subscription options: No Local (don't echo my own messages), Retain As Published and Retain Handling.
- Enhanced authentication: challenge/response flows beyond username and password.
- Server disconnect: the broker can tell a client why it is being disconnected.
Should you switch?
If your library supports MQTT 5, as MQTT.js, Eclipse Paho, Node-RED and Home Assistant all do, there is little reason not to. Better error messages alone save debugging time. If you are on a small microcontroller library like PubSubClient that only speaks 3.1.1, that's fine too: the core publish/subscribe model is identical, and a good broker serves both.
mqtty supports MQTT 3.1, 3.1.1 and 5 on the same endpoint, broker.mqtty.com:8883 over TLS, so you can mix old and new clients in one account. On MQTT 5, a device that is over its quota gets a proper reason code instead of a silent failure. Create a free account and try both versions side by side in the live dashboard.
mqtty gives every account 6 devices, 30 messages per minute and 60 days of history, with TLS and a live dashboard.
Start free with mqtty →