What is MQTT, and why do you need a viewer for it?
MQTT is a lightweight publish-subscribe messaging protocol built for constrained devices and unreliable networks, which is exactly why it powers so much of the connected-device world today. Instead of two systems talking directly, every client connects to a central broker. Publishers send messages to a topic, and any client subscribed to that topic — including with wildcards like + for a single level or # for everything below a level — receives the message almost instantly. That simplicity is the whole point: a battery-powered sensor can push a two-byte temperature reading without the overhead that heavier protocols like HTTP demand.
The tricky part is that MQTT traffic is invisible until you have the right tool. A desktop application like MQTT Explorer is the classic way to browse a broker's topic tree, but it needs an install, and it isn't always convenient when you're troubleshooting from a shared machine or a phone. That's the gap an MQTT viewer like this one fills — it's a browser-based MQTT client that connects straight to your broker over a WebSocket, so you can subscribe, publish, and read live packets without downloading anything.
Because browsers can't open a raw TCP socket, a browser MQTT client always talks over WebSocket rather than the classic port 1883 or 8883. If your broker (Mosquitto, EMQX, HiveMQ, VerneMQ, or a managed IoT platform) already exposes a WebSocket listener — often on port 8083, 8084, 8883, or 8884 with a path like /mqtt — you can point this viewer straight at it. If it doesn't yet, enabling a WebSocket listener alongside your existing TCP listener is usually a small configuration change on the broker side.
Understanding MQTT usage patterns helps explain what to look for once you're connected. A typical IoT setup has dozens of devices publishing to structured topics such as site/floor2/room9/temperature, with a dashboard or automation engine subscribed to a broad wildcard like site/#. Retained messages let a newly-connected subscriber immediately see the last known value on a topic instead of waiting for the next publish, which is why this viewer clearly flags retained packets in the message log. Quality of Service (QoS) then determines the delivery guarantee: QoS 0 fires and forgets, QoS 1 guarantees at-least-once delivery with possible duplicates, and QoS 2 guarantees exactly-once delivery at the cost of extra round trips.
MQTT v5, the newer revision of the protocol, adds several fields that a serious packet analyzer should expose rather than hide. Message expiry intervals let a broker discard stale messages automatically. Response topics and correlation data support request-response patterns over what is otherwise a one-way publish channel. User properties act like free-form HTTP headers, letting applications attach metadata without inventing a custom payload format. This viewer surfaces every one of those fields when you switch the connection to protocol version 5, so you can test v5-specific behavior instead of only the v3.1.1 basics.
Whether you're debugging a smart-home setup, validating firmware on an industrial sensor network, or simply learning how publish-subscribe messaging behaves, having a live, real-time window into broker traffic turns guesswork into observation. Connect, subscribe to a wildcard, and watch the topic tree fill in — that's usually the fastest way to understand a system you didn't build yourself.