How to Test an MQTT Broker (Online, CLI and Code)

Testing an MQTT broker boils down to one question: can a client connect, publish a message and receive it back? Everything else — QoS, retained messages, authentication, latency — builds on that loop. This guide walks through the loop three ways: in the browser, from the command line and in code.

What to check when testing a broker

1. Reachability — the host resolves and the port is open (TCP 1883, TLS 8883, or a WebSocket port). See MQTT ports explained.
2. Handshake — the broker answers CONNECT with a successful CONNACK. Wrong credentials or client IDs fail here.
3. Round trip — a message published to a topic is delivered to a subscriber on the same topic.
4. Features you depend on — QoS 1/2 acknowledgements, retained messages, Last Will, MQTT 5 properties.
5. Latency and stability — how long the round trip takes and whether the connection survives keep-alive intervals.

1. Test an MQTT broker online

The fastest way is a browser-based client. Browsers can only speak MQTT over WebSockets, so you need the broker's wss:// endpoint — every broker in our public broker list shows it.

1. Open the online MQTT client and choose a broker.
2. Click Connect. A green status means the CONNACK came back.
3. Subscribe to a unique topic such as testmqtt/demo-42/#.
4. Publish {"hello":"world"} to testmqtt/demo-42/hello and watch it appear in the message list.

Try it in the online MQTT client

2. Test from the command line

The Mosquitto clients are the standard CLI tools. Open two terminals — one subscriber, one publisher:

mosquitto_sub -h broker.hivemq.com -p 1883 -t 'testmqtt/demo-42/#' -v

mosquitto_pub -h broker.hivemq.com -p 1883 -t 'testmqtt/demo-42/hello' -m 'hello from the CLI'

Add -u and -P for username and password, -q 1 to test QoS 1, and --cafile with port 8883 to test TLS.

3. Test in code

A tiny script is the most repeatable test — you can run it in CI or as a health check. Here is a round-trip test with MQTT.js that also measures latency:

import mqtt from 'mqtt';

const topic = `testmqtt/${Math.random().toString(16).slice(2, 8)}/ping`;
const client = mqtt.connect('wss://broker.hivemq.com:8884/mqtt');

client.on('connect', () => {
  client.subscribe(topic, { qos: 1 }, () => {
    const sentAt = Date.now();
    client.publish(topic, String(sentAt), { qos: 1 });
  });
});

client.on('message', (_topic, payload) => {
  console.log(`round trip: ${Date.now() - Number(payload)} ms`);
  client.end();
});

client.on('error', (err) => {
  console.error('connection failed:', err.message);
  process.exit(1);
});

Testing QoS, retained messages and Last Will

• QoS — publish with QoS 1 and 2 and confirm the publish callback fires. See MQTT QoS levels.
• Retained messages — publish with retain, disconnect, reconnect and subscribe: the last value should arrive immediately. See retained messages.
• Last Will — connect a client with a will message, kill it without a clean disconnect and check that subscribers receive the will. See Last Will and Testament.

If the test fails

Timeouts usually mean a blocked port or the wrong transport (TCP port from a browser). Immediate refusals point to credentials, client ID conflicts or ACLs. Our MQTT connection errors guide maps every CONNACK reason code to a fix.

Frequently asked questions