MQTT Explorer

Last reviewed Sep 13, 2026 · 847 words

MQTT Explorer is not something you host. It is an Electron desktop app you install on your laptop, point at your broker, and use for 20 minutes when a sensor stops reporting or an automation fires for no reason. It appears in a self-hosting directory because a Docker image that wraps it in a browser tab exists, and because everyone running Mosquitto ends up needing it, but treat it as a diagnostic instrument, not a service. Nothing about your smart home depends on it being up.

The topic tree is the product

Connect to a broker and MQTT Explorer subscribes to #, then draws every topic it sees as a collapsible tree. Click a node and you get the current payload, a history of previous payloads with the changed bytes highlighted, and, for numeric values, a small chart that starts plotting immediately. That is the whole feature list, and it is enough to answer the three questions that make up 90% of MQTT debugging: is the device publishing at all, what exactly is it publishing, and is the topic spelled the way my automation expects.

The diff highlighting earns its place quickly. A Zigbee2MQTT device that publishes a 40-field JSON blob every 30 seconds is unreadable in mosquitto_sub; in the tree you see only the two fields that moved. Retained messages are marked, which matters because a stale retained payload is the cause of a surprising number of "ghost" states in Home Assistant.

What you will actually use it for

Three jobs, in my experience, cover nearly every session.

Checking discovery. Home Assistant's MQTT integration builds entities from config messages published under homeassistant/. When a device shows up with the wrong name, or not at all, expand that branch and read the retained config payload; the mistake is usually visible in 10 seconds.

Publishing test messages. The publish panel lets you send a payload to any topic with a chosen QoS and retain flag. Sending ON to cmnd/tasmota_abc123/POWER and watching the stat/ branch respond is the fastest way to confirm a device works before you touch an automation.

Clearing retained junk. Publish an empty payload with retain set and the broker drops the retained message. MQTT Explorer has a delete button that does exactly this for a topic or an entire subtree, which is the cleanest fix when you rename devices and the old ones linger.

Running it in Docker is possible but rarely worth it

There is a community image that runs the app inside a browser-accessible session, typically on port 4000. It works, and it suits the case where the broker sits behind a VPN and you would rather not open a tunnel from every laptop. It also puts a tool with full publish rights on your broker behind a web page, so put it behind authentication or bind it to localhost. At 128 MB of RAM it is cheap to leave running, but I would still only start it when needed. For everyone else, the native download for Windows, macOS and Linux is the right choice and takes one minute.

Connecting to a broker that has TLS or auth

The connection dialog takes host, port, username, password and a TLS toggle. Mosquitto's default listener is 1883 in plain text; if you have enabled a TLS listener on 8883, tick the encryption switch and, for a self-signed certificate, disable validation or load the CA. WebSocket listeners (Mosquitto commonly uses 9001) work through the ws:// and wss:// options. One habit that pays off: create a read-only broker user for exploration with an ACL that allows subscribing to # and nothing else, and use that for everyday browsing. Publish rights are only needed when you are deliberately sending something.

Where it stops and what to add

MQTT Explorer has no automation, no rules, no history beyond the current session, and no alerting. It will not tell you a sensor went quiet at 3 a.m. That is a job for Home Assistant, Node-RED or an MQTT-aware monitor, and the boundary is a feature: a debug client that could also change your setup is one you would have to protect. Releases are infrequent and the app has looked much the same for years, which is fine because MQTT itself has not changed. If you outgrow it, the broker's own tooling (mosquitto_sub -v -t '#') and a Grafana dashboard fed from your automation platform cover what a bigger tool would.

What I'd do

Install the desktop build on the machine you do your home-automation work from, save a connection profile per broker with a read-only account, and reach for it before touching any YAML when something misbehaves. Skip the Docker version unless your broker is only reachable from the server's network. If you are building the stack for the first time, my Home Assistant first month notes cover the order to set things up in; MQTT Explorer belongs in the toolbox by week two.