Online MQTT Web Client: Test Any Broker from Your Browser

An MQTT web client online lets you connect to a broker, subscribe to topics and publish test messages straight from a browser tab, without installing anything. In this guide you will learn how browser clients actually reach a broker, run a full test session with the client built into the ConnectMQ portal, and build a tiny browser client of your own for the cases a hosted tool cannot cover.

Why Use an MQTT Web Client Online?

Command-line tools such as mosquitto_sub are excellent, but they are not always available. You may be on a locked-down corporate laptop, helping a colleague over a video call, or checking a field installation from a tablet. A browser-based client removes the setup step: open a page, enter the host and credentials, and you are looking at live traffic.

Typical jobs for a web client:

• Confirming that a new device actually publishes, and on the topic you expect.
• Sending a one-off command, such as a configuration update or a relay toggle, to a device under test.
• Checking retained messages after a deployment.
• Showing a non-technical stakeholder that data is flowing, without explaining a terminal.
• Reproducing a bug report with the exact payload a customer sent.

A web client is a testing and debugging tool, not a production consumer. Keep long-running integrations in a proper service and use the browser for interactive work.

How Browser MQTT Clients Connect

Browsers cannot open raw TCP sockets, so a browser client cannot use the classic MQTT ports 1883 or 8883. Instead it tunnels MQTT inside a WebSocket connection. The broker must expose a WebSocket listener, and the client must know both the port and the path. If you want the full background, read our guide to MQTT over WebSocket.

ConnectMQ exposes these listeners on every broker:

Two browser rules explain most failed connections. First, a page loaded over HTTPS may not open an unencrypted ws:// socket; the browser blocks it as mixed content. Second, the path matters: connecting to wss://broker.connectmq.com:8084 without /mqtt reaches the server but never completes the MQTT handshake. Use secure WebSocket with the full path and both problems disappear. The broker serves a Let's Encrypt certificate, so browsers trust it without any extra configuration.

Step by Step: Test a Broker with the ConnectMQ Web Client

The quickest route is the MQTT client built into the portal, because it already knows your broker's endpoints and credentials.

1. Sign up at app.connectmq.com, choose the free Serverless plan and create a broker. The portal generates a username, password and client ID for you.
2. Open the in-browser MQTT client from the portal. Your broker connection details are available alongside it.
3. Connect. A successful CONNACK means the credentials and client ID were accepted. Remember that client IDs are bound to the issued credentials, so use the client ID the portal gave you rather than inventing one.
4. Subscribe to a wildcard filter for your project, for example factory1/#, so you see everything under that root.
5. Publish a test payload such as {"temperature": 21.7} to factory1/line1/sensor1/telemetry with QoS 1. It should appear immediately in the subscription pane.
6. Publish once more with the retain flag set, disconnect, reconnect and subscribe again. The retained value should arrive instantly, which proves the broker stores the last value for that topic.
7. Open the live topic explorer in another tab. The same topic now appears in the tree, which is a convenient cross-check that the message really passed through the broker.

If you only want to experiment, you can also point any web client at the public MQTT test broker at wss://broker.connectmq.com:8084/mqtt. It accepts anonymous connections with any non-empty unique client ID. Use a unique topic prefix like connectmq/demo/k3x9/..., because everything on the public area is readable by everyone.

Build a Minimal Browser Client with MQTT.js

Sometimes you need behaviour a generic tool does not offer: a custom payload generator, a button wired to a specific command, or a page you can hand to a field technician. MQTT.js runs in the browser and speaks WebSockets natively. Install it in any bundler-based project (Vite, webpack or similar) with npm install mqtt, then use the following module:

import mqtt from "mqtt";

const prefix = `connectmq/demo/${Math.random().toString(16).slice(2, 8)}`;
const clientId = `web-${Math.random().toString(16).slice(2, 10)}`;

const client = mqtt.connect("wss://broker.connectmq.com:8084/mqtt", {
  clientId,
  protocolVersion: 5,
  clean: true,
  connectTimeout: 10_000,
  reconnectPeriod: 3_000,
  // For your private broker, add the credentials from the portal:
  // username: "YOUR_USERNAME",
  // password: "YOUR_PASSWORD",
  // and use clientId: "YOUR_CLIENT_ID"
});

client.on("connect", (connack) => {
  console.log("Connected, reason code:", connack.reasonCode ?? 0);
  client.subscribe(`${prefix}/#`, { qos: 1 }, (err, granted) => {
    if (err) return console.error("Subscribe failed:", err);
    console.log("Granted:", granted);
    client.publish(
      `${prefix}/sensor1/telemetry`,
      JSON.stringify({ temperature: 21.7, ts: Date.now() }),
      { qos: 1 }
    );
  });
});

client.on("message", (topic, payload) => {
  console.log(`${topic} -> ${payload.toString()}`);
});

client.on("error", (err) => console.error("MQTT error:", err.message));
client.on("close", () => console.log("Connection closed"));

Open the browser console and you should see the connect message, the granted QoS and your own payload echoed back. Because the code uses MQTT 5, the connack.reasonCode value is available, and a refused connection will report a meaningful reason rather than a generic failure.

Never Ship Production Secrets to the Browser

Anything you put in front-end JavaScript is visible to the user. For an internal debugging page that is acceptable; for a public dashboard it is not. If many people need read access, issue a dedicated credential for the dashboard and keep device credentials separate, or put a small backend between the browser and the broker. Our MQTT security best practices cover credential separation in more detail.

Troubleshooting Online MQTT Client Connections

Most problems come down to transport details. Work through this checklist in order:

1. Wrong port. 1883 and 8883 do not work from a browser. Use 8084 for wss://.
2. Missing path. The URL must end in /mqtt.
3. Mixed content. An HTTPS page cannot open ws://. Switch to wss://.
4. Empty client ID. The public broker requires a non-empty client ID; your private broker requires the issued one.
5. Duplicate client ID. If two tabs use the same client ID, the broker disconnects the older session each time the other connects, and both tabs flap. Give every tab a unique ID on the public broker.
6. Wrong credentials. Copy username and password directly from the portal. Repeated failed logins can trigger IP blocking as part of the broker's brute-force protection, so fix the credentials before retrying in a loop.
7. Corporate proxy. Some proxies strip WebSocket upgrade headers. Test from another network to confirm.
8. Quota reached. The free Serverless plan allows up to 25 connections. With MQTT 5 the broker can return reason code 0x97 (quota exceeded), which the MQTT.js client exposes in its error.

Reading the Symptoms

When to Move Beyond the Browser

A web client is ideal for interactive checks, but it stops at the tab. When you need to log traffic for hours, replay messages or script tests, move to tools that run outside the browser. The mosquitto_pub and mosquitto_sub examples cover scripted testing, the ConnectMQ VS Code extension shows CONNACK, SUBACK and PUBACK reason codes inside your editor, and the ConnectMQ Desktop MQTT explorer is better suited for long sessions. To inspect a large topic hierarchy visually, see our walkthrough of the MQTT topic browser.

For production traffic itself, the important decision is the broker, not the client. A managed MQTT broker gives you secure WebSocket endpoints, issued credentials and a portal with a web client and topic explorer out of the box, so the browser checks you just learned work from the first day.

Get Started with ConnectMQ

Create a free broker at app.connectmq.com on the Serverless plan; no credit card is needed. You get credentials, all four transports including secure WebSockets, and the in-browser client used in this guide. To learn how ConnectMQ compares with running your own server, read our guide to choosing a cloud MQTT broker.

Frequently Asked Questions

Can a browser connect to MQTT port 1883 or 8883?

No. Browsers cannot open raw TCP sockets, so they must use MQTT over WebSocket. On ConnectMQ that means wss://<host>:8084/mqtt for encrypted connections.

Is it safe to use an online MQTT web client with real credentials?

It is safe when the client runs in a trusted page, such as the portal of your own broker, over wss://. Avoid typing production credentials into unknown third-party websites, and never embed device credentials in public front-end code.

Why does my web client keep disconnecting?

The most common cause is two sessions using the same client ID, which makes the broker drop the older one each time. Give every tab and tool a unique client ID.

Does the free plan include the web client?

Yes. The free Serverless plan includes the portal with the in-browser MQTT client and the live topic explorer.

Can I use MQTT 5 features from the browser?

Yes. MQTT.js supports MQTT 5 with protocolVersion: 5, so you can read reason codes and use features such as message expiry and user properties from a browser.