MQTT client online: test an MQTT broker in your browser

An online MQTT client lets you connect to a broker, subscribe to topics and publish messages without installing a desktop tool or a command-line client. In Swastik Codes you create an MQTT request, enter the broker URL (mqtt://, mqtts://, ws:// or wss://), press Connect, add a topic filter on the Topics tab and publish from the Message tab. Both MQTT 3.1.1 and MQTT 5.0 are supported, including QoS 0, 1 and 2, retained messages, last will messages and MQTT 5 properties.

This guide walks through that flow using the public Eclipse Mosquitto test broker, test.mosquitto.org, and then covers what to check on your own broker.

What you need

• A broker reachable from the public internet. The Swastik Codes web app does not connect from your browser tab directly: browsers cannot open raw TCP sockets, so the swastik.codes server opens the MQTT connection on your behalf and relays packets to your tab. That relay refuses private, loopback and other reserved addresses, so a broker on localhost or 10.0.0.5 cannot be reached from the web app. The Swastik Codes desktop app for Windows and Linux connects from your own machine, so it reaches local brokers.
• The broker's credentials, if it needs them: username and password, a client certificate, or MQTT 5 enhanced authentication.
• A free Swastik Codes account, because protocol connections run through the server.

For a first try, test.mosquitto.org accepts anonymous connections on port 1883 (plain MQTT over TCP) and port 8080 (MQTT over unencrypted WebSocket). It is a shared public test broker: anyone can read what you publish, so never send real data there, and use a unique topic prefix such as swc-demo/<your-name>/ so you do not collide with other people.

Step 1: create an MQTT request and connect

1. Open the app and sign in.
2. Click + in the tab bar and choose MQTT from the New request menu.
3. Enter the broker URL. The scheme picks the transport:
   • mqtt://host:1883 or tcp://host:1883 for plain MQTT over TCP,
   • mqtts://host:8883 (also ssl:// or tls://) for MQTT over TLS,
   • ws://host:port/path or wss://host:port/path for MQTT over WebSocket, with the mqtt subprotocol.
4. Choose the version next to the URL: MQTT 3.1.1 or MQTT 5.0.
5. Press Connect.

For the demo, enter mqtt://test.mosquitto.org:1883, or ws://test.mosquitto.org:8080 to try the WebSocket transport.

The Settings tab holds the connection options: Client ID (leave it empty for a random id per connection, or generate one), Keep-alive (s), Clean session (called Clean start in MQTT 5), Connection timeout (ms), automatic reconnection with a number of attempts and a delay, and TLS options: Use TLS (mqtts / wss), Verify the broker certificate, Server name (SNI), and PEM fields for a CA certificate, client certificate and client key for mutual TLS. Username and password live on the Authorization tab.

Step 2: subscribe to topics

Open the Topics tab, type a topic filter and click Subscribe. MQTT filters use two wildcards:

• + matches exactly one level: sensors/+/temp matches sensors/kitchen/temp but not sensors/kitchen/1/temp.
• # matches any number of levels and must come last: swc-demo/alice/# matches everything under that prefix.

Pick the QoS for each subscription. The broker delivers each message at the lower of the publisher's QoS and the subscription's QoS. Each subscription has a switch to unsubscribe and subscribe again without deleting it, and you can add a description to remember what a topic is for.

With MQTT 5, each subscription also has subscription options:

• No local: do not receive messages you published yourself.
• Retain as published: keep the retain flag as the publisher set it instead of clearing it.
• Retained messages: Send on subscribe, Only for new subscriptions or Never send, which control whether the broker replays retained messages when you subscribe.
• Subscription id: a number the broker attaches to every message delivered through this subscription.

Incoming messages appear in the log with their topic, QoS, retain flag and payload, and you can filter the log by topic.

Step 3: publish messages

On the Message tab, enter a topic, choose the QoS (QoS 0, QoS 1 or QoS 2), set Retain if you want the broker to keep the message for future subscribers, choose a payload format and write the payload. Formats are Text, JSON, XML, Hex and Base64; Hex and Base64 let you publish binary payloads such as Protobuf or CBOR. Press Publish.

Try this with the demo broker: subscribe to swc-demo/alice/#, then publish to swc-demo/alice/kitchen/temp:

{ "celsius": 21.5, "at": "{{$isoTimestamp}}" }

You should see your own message come back through the subscription. Variables and dynamic values are resolved before publishing.

What the QoS levels mean

• QoS 0, at most once: fire and forget. Fine for frequent telemetry where a lost reading does not matter.
• QoS 1, at least once: the receiver acknowledges with PUBACK and the sender retries until it does. Duplicates are possible, so consumers should be idempotent.
• QoS 2, exactly once: a four-step handshake (PUBLISH, PUBREC, PUBREL, PUBCOMP). Slower, but no duplicates between two hops.

Swastik Codes performs the full handshake for each level in both directions, so you can see how your broker and consumers behave with each.

Retained messages

A retained message is the last known value of a topic. When you publish with Retain on, the broker stores the message and sends it to every new subscriber immediately. To clear a retained message, publish an empty payload with retain on to the same topic. This is a common source of confusion: a dashboard shows stale data because somebody once published a retained message to the topic.

Step 4: last will and MQTT 5 properties

The Last will tab configures the message the broker publishes on your behalf if the client disconnects without a proper DISCONNECT, for example on a network failure. Turn on Send a last-will message and set a topic, payload, QoS and retain flag. A common pattern is a retained status topic: the device publishes online after connecting, and the will publishes offline. In MQTT 5 the will can also have a Delay interval (s) and message properties.

With MQTT 5.0 selected, the Properties tab adds CONNECT properties: Session expiry (s), Receive maximum, Maximum packet size (bytes), Topic alias maximum, Request response information, Request problem information, user properties, and Authentication method and Authentication data for enhanced auth. Individual publishes get message properties under MQTT 5 properties: Content type, Response topic, Correlation data, Message expiry (s), Topic alias, Payload format indicator (UTF-8) and user properties.

Response topic and correlation data are how request/response works over MQTT 5. Publish a command with Response topic: swc-demo/alice/replies and some correlation data, subscribe to swc-demo/alice/replies, and check that your service answers with the same correlation data.

Step 5: save messages

Click Save next to Publish to keep the current message, including its topic, QoS, retain flag and format, with the request. Saved messages are listed on the Saved tab and can be published again with one click while connected. Save the request to a collection with Ctrl+S or Cmd+S and everyone in the workspace gets the broker URL, subscriptions, will and saved messages.

Run your own broker

For a private test broker, Eclipse Mosquitto is a small and well-documented choice. A minimal mosquitto.conf with password authentication and both TCP and WebSocket listeners:

# mosquitto.conf
listener 1883
protocol mqtt

listener 8083
protocol websockets

allow_anonymous false
password_file /mosquitto/config/passwd

Create the password file and start it with Docker:

docker run --rm -v "$PWD:/mosquitto/config" eclipse-mosquitto \
  mosquitto_passwd -c -b /mosquitto/config/passwd tester 's3cret'

docker run -d --name mosquitto -p 1883:1883 -p 8083:8083 \
  -v "$PWD:/mosquitto/config" eclipse-mosquitto

Put TLS in front of it (a listener 8883 with certfile and keyfile, or a TLS-terminating proxy for the WebSocket listener) before exposing it on the internet. To see traffic flowing, run a small simulated device with the mqtt package for Node.js:

// device.mjs  (npm install mqtt)
import mqtt from 'mqtt';

const client = mqtt.connect('mqtts://broker.example.com:8883', {
  username: 'tester',
  password: process.env.MQTT_PASSWORD,
  protocolVersion: 5,
  will: { topic: 'devices/sensor-1/status', payload: 'offline', qos: 1, retain: true },
});

client.on('connect', () => {
  client.publish('devices/sensor-1/status', 'online', { qos: 1, retain: true });
  client.subscribe('devices/sensor-1/commands', { qos: 1 });
  setInterval(() => {
    const reading = { celsius: 20 + Math.random() * 5, at: new Date().toISOString() };
    client.publish('devices/sensor-1/telemetry', JSON.stringify(reading), { qos: 0 });
  }, 5000);
});

client.on('message', (topic, payload) => {
  console.log('command on', topic, payload.toString());
});

Now connect from Swastik Codes, subscribe to devices/#, and publish to devices/sensor-1/commands. Stop the device process abruptly and watch the broker publish the offline will.

Troubleshooting

CONNACK says "not authorized" or "bad user name or password". Check the Authorization tab. On MQTT 5 the reason code in the log tells you exactly which check failed.

The connection is refused for a private address. The relay blocks private and loopback addresses. Use a broker with a public hostname.

TLS errors on mqtts://. Make sure the port really serves TLS (8883 by convention), set Server name (SNI) if you connect by IP, and add the CA certificate if the broker uses a private CA.

WebSocket connection fails. Most brokers serve MQTT over WebSocket on a specific path, often /mqtt. Include it in the URL.

I get disconnected right after connecting. Two clients with the same client id kick each other off. Leave Client ID empty for a random one.

Old messages arrive the moment I subscribe. They are retained messages. Clear them by publishing an empty retained payload, or set Retained messages to Never send on an MQTT 5 subscription.

Frequently asked questions

Which MQTT versions are supported?

MQTT 3.1.1 and MQTT 5.0. MQTT 5 adds reason codes, properties, subscription options, session expiry and enhanced authentication, and all of those are available in the editor.

Can I connect over WebSocket?

Yes. Use a ws:// or wss:// URL and the client speaks MQTT over WebSocket with the mqtt subprotocol. Plain TCP (mqtt://) and TLS (mqtts://) work as well.

Can I publish binary payloads?

Yes. Choose Hex or Base64 as the payload format and the bytes are decoded before publishing.

Can I test a broker on my local network?

Not from the web app, because the relay refuses private and loopback addresses. Use the desktop app, which connects from your own computer, or expose a test broker on a public hostname, protected by a password and TLS.

Is test.mosquitto.org safe to use?

It is fine for learning and quick checks, but it is public: anything you publish can be read by anyone. Use a unique topic prefix and never send credentials or personal data.

Try it

Open Swastik Codes, create an MQTT request, connect to mqtt://test.mosquitto.org:1883 and subscribe to your own topic prefix. You will need a free account to connect. The MQTT client feature page lists every option. If your system also pushes data to browsers, see how to test Server-Sent Events and how to test a WebSocket API.