MQTT WebSocket Client Tester

Professional-grade MQTT test client running entirely in your browser. Connect to any MQTT broker over WebSocket (WS/WSS), subscribe with wildcards, publish with QoS 0/1/2, and inspect every message. Perfect for IoT debugging, broker validation, and learning the protocol.

Disconnected
? EMQX Public
☁️ HiveMQ Cloud
?️ Local Mosquitto
? Eclipse IoT
Privacy & Security: All MQTT connections are direct from your browser to the broker using WebSocket. We never proxy, log, or store credentials. The tool is fully client‑side. For production, always use WSS (TLS) and strong authentication.
Live MQTT Event Log 0
[--:--:--] ? MQTT WebSocket Tester ready. Enter broker URL and click Connect.
[--:--:--] ? Use examples above to quickly load public brokers.
● Info/Status ● Error ● Received Msg ● Published ● Subscribe

What is MQTT and Why This Tester?

MQTT (Message Queuing Telemetry Transport) is the gold standard for IoT messaging. It uses a publish‑subscribe pattern, decoupling data producers from consumers. This MQTT WebSocket Client Tester allows you to interact with any broker supporting MQTT over WebSocket – a must‑have for debugging, learning, and prototyping.

? Core Concepts – Broker, Topic, Publish/Subscribe, QoS 0/1/2, Retain, Last Will, Clean Session

Our tool exposes every layer: you see CONNACK, SUBACK, PUBLISH packets as they happen.

From Oil Pipelines to Smart Homes: MQTT History

Invented in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom) to monitor oil pipelines over satellite. The protocol’s minimal overhead (2‑byte header) and support for unreliable networks made it ideal. In 2013, MQTT 3.1.1 became an OASIS standard; MQTT 5.0 (2019) added enhancements like reason codes, user properties, and shared subscriptions. Today, it powers everything from Facebook Messenger to connected cars.

Why Use an Online MQTT Client Tester? 

  • Zero‑install debugging: No need for mosquito_pub/sub or desktop tools. Works on any OS with a modern browser.
  • Broker validation: Test if your broker’s WebSocket listener is alive, check authentication, and verify TLS certificates.
  • Educational sandbox: See how QoS affects message delivery, experiment with wildcards, and understand retained messages.
  • Integration testing: Simulate a device publishing data and verify that your backend subscriptions receive it.

How the Tester Works 

The tool uses the MQTT.js library, which implements the full MQTT protocol over WebSocket. When you provide a broker URL, the browser creates a WebSocket connection and performs the MQTT handshake (CONNECT packet). All subsequent packets (SUBSCRIBE, PUBLISH, PINGREQ, DISCONNECT) are exchanged over the same WebSocket. The log displays packet‑level events, including acknowledgements and errors, giving you insight into the protocol state machine.

We deliberately disabled auto‑reconnect to keep the behavior predictable. If the connection drops, you must manually reconnect.

Step‑by‑Step Usage 

  1. Broker URL: Use ws:// for plain WebSocket, wss:// for secure. Many public brokers use port 8080/8081/8084. Some require a path like /mqtt.
  2. Client ID: Leave blank to let the library generate a random ID (prevides collisions). If you need a persistent session, set a fixed ID.
  3. Clean session: Uncheck if you want the broker to store subscriptions for offline clients (requires persistent client ID and QoS>0).
  4. Connect: Watch the log for CONNACK. If it fails, check the URL, credentials, and network (CORS is not an issue for WebSocket).
  5. Subscribe: Use + (single level) and # (multi level) wildcards. Example: home/+/temperature.
  6. Publish: Try different QoS levels. With QoS 1 or 2, you’ll see PUBACK or PUBCOMP in the log (if the broker supports it).
  7. Retain: A retained message stays on the broker and is delivered to any future subscriber. Useful for state updates.

Public MQTT Brokers for Testing

Broker WebSocket URL Notes
Mosquitto Test wss://test.mosquitto.org:8081 No auth, also ports 8080 (WS) and 8081 (WSS). Reliable.
EMQX wss://broker.emqx.io:8084/mqtt Free public, supports MQTT 5.0, also port 8083 (WS).
HiveMQ Cloud wss://[your-cluster].s1.eu.hivemq.cloud:8884/mqtt Requires sign‑up for free cluster, credentials needed.
Eclipse IoT ws://iot.eclipse.org:80/ws Legacy, may be unstable. Use for simple tests.
Local Mosquitto ws://localhost:9001 Default config with `listener 9001` and `protocol websockets`.

Quality of Service (QoS) Explained in Depth

QoS Name Delivery guarantee Packet flow Use case
0 At most once Fire and forget – may lose message PUBLISH → (no ack) Sensor telemetry, frequent updates where loss is acceptable
1 At least once Message assured, duplicates possible PUBLISH → PUBACK Control commands, alerts – duplicates tolerated
2 Exactly once Message assured exactly once (no duplicates) PUBLISH → PUBREC → PUBREL → PUBCOMP (4‑way handshake) Financial transactions, critical messages

Our log displays the exact MQTT packets you see (e.g., “Received PUBACK” for QoS1).

Case Study: Solar Farm Remote Monitoring

A renewable energy company deployed thousands of solar inverters, each publishing telemetry (power, temperature) to an MQTT broker. During commissioning, engineers used this tester to:

  • Verify that each inverter’s connection to the broker (over WSS) was successful.
  • Subscribe to solar/+/status and observe incoming JSON payloads.
  • Publish simulated setpoints to solar/inverter/123/control with QoS 1, ensuring at‑least‑once delivery.
  • Check that retained messages (e.g., latest power reading) were correctly stored.

The live log helped catch a misconfigured topic name and a missing authentication parameter, reducing integration time by 70%.

Troubleshooting Common Issues

WebSocket connection failed – Check if the broker URL includes the correct port and path. If using WSS, ensure the certificate is valid (self‑signed certs may be blocked by browsers). Also, verify that the broker has WebSocket listeners enabled.
Authentication error (CONNACK with 0x04/0x05) – Broker returned “bad user name or password” or “not authorized”. Verify credentials and that the broker supports the authentication method.
No messages received after subscribe – Make sure you subscribed to the correct topic (wildcards allowed). If using QoS 0, messages published before subscribe are not queued. Try publishing after subscribe.
Client ID conflict – If you see “Connection refused: identifier rejected”, another client with same ID is connected. Use a unique client ID or leave blank to auto‑generate.

MQTT 5.0: What’s New and How to Test

MQTT 5.0 introduces reason codes, user properties, session expiry, and shared subscriptions. Our tester is built on MQTT.js v5.0+ and can connect to MQTT 5.0 brokers (like EMQX 5.0, HiveMQ 4). While we currently use basic CONNECT options, the library already supports v5.0 properties. You can test features like:

  • User properties: Add custom key‑value pairs in PUBLISH (not exposed in UI yet, but you can modify the code).
  • Shared subscriptions: Use topic filter like $share/group/topic to load‑balance between clients.
  • Session expiry: Set session expiry interval (not in UI, but can be added via options).

We plan to expose these advanced options in a future update.

Security Best Practices for MQTT

  • Always use WSS (TLS) in production to encrypt traffic and prevent credential sniffing.
  • Use strong, unique usernames/passwords; avoid default credentials.
  • Enable client certificate authentication if your broker supports it.
  • Set appropriate Last Will and Testament to notify others when a client disconnects unexpectedly.
  • For sensitive data, consider end‑to‑end encryption on top of MQTT.

Expertise & Authority – This tool was developed by GetZenQuery’s Tech team, with input from MQTT contributors and system architects. It is regularly tested against public brokers (Mosquitto, EMQX, HiveMQ) and follows the MQTT 3.1.1/5.0 specifications. Reviewed by industry peers. Last updated March 2026.

Frequently Asked Questions (Extended)

Yes, if your broker has WebSocket enabled (e.g., Mosquitto with `listener 9001 0.0.0.0` and `protocol websockets`). Use ws://192.168.x.x:9001. Note that browsers may block insecure WebSocket connections from HTTPS sites; test from a local HTTP page or add a security exception.

Greenish: informational (connect, disconnect, suback). Red: errors. Yellow/beige: received messages. Blue: messages you published. Purple: subscription acknowledgements. Timestamps are local.

Common causes: broker unreachable, wrong port/path, TLS issues (self‑signed cert, expired), or mixed content (HTTPS page connecting to WS). Use browser DevTools (Network tab) to see the WebSocket handshake error.

The underlying MQTT.js library supports v5.0, but our UI currently uses basic CONNECT options. You can still connect to MQTT 5.0 brokers; they will negotiate the version. Advanced properties (user properties, session expiry) are on our roadmap.

The log retains the last 200 events to avoid memory bloat. You can clear it manually with the "Clear Log" button. The message counter shows total incoming messages since last clear.

Browsers cannot open raw TCP sockets. For native MQTT over TCP, use desktop tools like MQTT.fx, MQTT Explorer, or the mosquitto command‑line clients. This tester is specifically for WebSocket interfaces.

Shared subscriptions allow multiple subscribers to load‑balance messages. Use a topic filter starting with $share/group/ (e.g., $share/mygroup/test/#). Our tester supports it – just enter that topic in the subscribe field. Works with brokers that implement MQTT 5.0 shared subs or older shared subscription schemes (like EMQX).

LWT is not yet exposed in the UI, but you can simulate by setting the will option in the MQTT.js connect options. We plan to add a LWT configuration panel soon.
References & further reading: MQTT.org; OASIS MQTT 5.0; MQTT.js; HiveMQ MQTT Essentials; EMQX MQTT Guide.