Test an MQTT Broker from Your Browser (No Install)

You can test an MQTT broker from your browser in about two minutes — no Mosquitto install, no Python, no admin rights. Open the online MQTT client, connect over secure WebSockets (wss), subscribe to a topic, publish a message and watch it come back. If that round trip works, the broker is up, reachable from your network and routing messages.

This guide walks through the full test step by step, shows how to point it at your own broker and how to share a ready-made test with a colleague or a device developer.

How browser MQTT works

Browsers cannot open raw TCP sockets, so a web page cannot speak MQTT on port 1883 directly. Instead it uses MQTT over WebSockets: the same MQTT packets, framed inside a WebSocket connection that starts as an HTTP upgrade request.

Two consequences matter for testing: the broker must have a WebSocket listener enabled (with the right path — usually /mqtt), and from an https page you must use wss. The TestMQTT client also offers TCP and TLS; because browsers can't open those sockets, it relays them through the TestMQTT server. That is handy for checking a TCP-only broker, but keep in mind the connection then comes from the relay's network, not yours. For background, see MQTT over WebSockets.

Step 1 — Connect

1. Open testmqtt.com/client. The protocol defaults to WSS and a recommended broker is preselected.
2. Click Connect. The status changes to connected and the log records the successful connection (the broker's CONNACK).
3. A unique client ID (testmqtt_xxxxxxxx) is generated for every tab, so two tabs never kick each other off the broker.

To test your own broker, choose Custom broker… in the broker list and fill in the settings:

If the broker uses a self-signed certificate, the browser decides whether to trust it, not the page. Open https://host:8084/ once in a tab and accept the certificate, or better, use a certificate from a public CA.

Step 2 — Subscribe and publish

Use a topic nobody else is using. On a shared broker, test is busy; something like testmqtt/<your-name>-<random>/# keeps your messages separate.

1. In Subscriptions, add testmqtt/demo-7f3a/# with QoS 1.
2. In Publish, set the topic to testmqtt/demo-7f3a/sensor, pick the Sensor JSON template or type your own payload, and click Publish.
3. The message appears in the message list, marked as received. Double-click it to see the full details: topic, QoS, retained flag, size and the complete payload.

If you publish and nothing appears, check that the subscription filter actually matches the topic — testmqtt/demo-7f3a/+ matches one level, # matches all levels below. The topic matcher settles this in seconds, and topics and wildcards explains the rules.

For a steady stream, set a repeat interval on the publish panel. That makes it easy to watch the connection for a few minutes and spot disconnects or gaps.

Step 3 — Test retained messages and Last Will

A proper broker test goes beyond one message:

• Retained: publish to testmqtt/demo-7f3a/status with retain on. Disconnect, reconnect and subscribe again — the broker must deliver the last retained value immediately. To clear it, publish an empty retained payload — or use Clear retained message in the message details.
• Last Will: in Settings, set a will topic such as testmqtt/demo-7f3a/lwt with payload offline. Open a second tab subscribed to that topic, then close the first tab without disconnecting. After roughly 1.5× the keep-alive interval, the broker should publish the will. A clean Disconnect does not trigger it — that is correct behaviour.
• MQTT 5: switch the protocol version to 5 and reconnect. If the broker only supports 3.1.1 you will get a CONNACK error such as Unsupported Protocol Version; the reason codes tool explains each code.

Step 4 — Cross-check from another client

A browser test proves the WebSocket listener works. Devices usually use TCP or TLS, so close the loop: keep the browser subscribed and publish from a terminal.

mosquitto_pub -h broker.connectmq.com -p 1883 \
  -t testmqtt/demo-7f3a/sensor -m '{"temp":21.5}' -q 1 -d

mosquitto_pub -h broker.connectmq.com -p 8883 \
  --cafile /etc/ssl/certs/ca-certificates.crt \
  -u "$MQTT_USER" -P "$MQTT_PASS" \
  -t testmqtt/demo-7f3a/sensor -m '{"temp":21.5}' -q 1

If the message shows up in the browser, both listeners share one broker and routing works across transports. If TCP works but the browser doesn't — or the other way round — the problem is the listener or network path for one transport, not the broker as a whole.

Share a ready-made test

When you debug with someone else — a firmware developer, a customer, a teammate — send them a link that opens the client already connected to the right endpoint and subscribed to the right topic:

https://testmqtt.com/client?url=wss://broker.connectmq.com:8084/mqtt&topic=testmqtt/demo-7f3a/%23

url sets protocol, host, port and path and connects automatically; topic sets the subscription (encode # as %23). Both of you see the same messages live, which is far quicker than exchanging screenshots of logs. Credentials are never part of the link — each person enters their own.

When the browser test fails

Your browser's developer tools show the raw WebSocket frames under Network → WS, which is often the quickest way to see whether CONNECT went out and what came back. Debugging MQTT with Chrome DevTools walks through it.

Open the browser test client

Testing from the browser is the fastest first check you can run: it needs nothing installed, works from any machine, and a shared link gets everyone looking at the same live topic. Once the browser round trip succeeds, cross-check over TCP or TLS and you know the broker, the listeners and the network path are all in order.

Frequently asked questions