The short answer

Paste one MQTT topic name or subscription filter to review a small set of structural and policy signals. The checker calls out empty levels, misplaced multi-level wildcards, very broad single-level wildcard use, terms that look sensitive, unclear message intent, and unusually deep hierarchies. A clean result means only that these heuristics found no obvious issue.

Broker authorization remains the control. Test concrete allowed and denied operations with the identity, tenant, client type, and broker configuration that will run in production.

What to enter

Check topic names and subscription filters separately. A topic name is the string attached to a published application message and cannot contain wildcard characters. A subscription filter may contain + for one level or # for the remaining levels, subject to MQTT’s placement rules.

Use realistic structure but replace identifiers that reveal customers, people, facilities, credentials, or internal naming. For example:

v1/acme/device-42/telemetry

or:

v1/acme/+/status

The checker does not need a broker URL, username, password, certificate, or payload.

Checks performed

The current implementation applies readable, deterministic rules:

  • A leading slash, trailing slash, or double slash produces an empty topic level.
  • # is flagged unless it is the complete filter or occupies the final level after /.
  • More than one + is treated as a broad subscription surface that deserves explicit review.
  • Terms such as password, secret, token, or email trigger a sensitive-data warning.
  • If no level resembles telemetry, event, command, ack, state, or status, the checker asks whether direction or intent is visible.
  • More than eight levels prompts a review for mutable metadata embedded in the hierarchy.

These are design prompts, not a complete MQTT parser. The multiple-+ warning is intentionally conservative: several single-level wildcards can be legitimate for an administrative consumer, while the same filter may be unacceptable for a device identity.

Worked examples

v1/acme/device-42/telemetry returns no obvious structural issue. Its levels are non-empty, the hierarchy is compact, and the final level communicates message intent. You must still prove that device 42 can publish only within its own tenant and identity boundary, and that it cannot subscribe to another device’s telemetry.

/acme/+/+/data/#/archive produces several review points. It begins with an empty level, contains multiple + wildcards, places # before the final level, and uses data rather than a clear direction or intent term. Fixing the syntax does not automatically make the authorization scope safe.

Limitations

The checker does not connect to a broker or inspect ACLs. It does not validate UTF-8 constraints, null characters, reserved $ namespaces, shared-subscription syntax, topic aliases, maximum packet size, broker-specific limits, normalization, homoglyphs, or the distinction between every legal topic name and filter. It also cannot know whether a tenant ID, device ID, or operation belongs in a particular level.

Do not use the result as evidence that a client is isolated. Build negative tests that attempt cross-tenant publish, cross-device subscription, wildcard escalation, retained-message access, and system-topic access. Keep application-level authorization where broker rules alone cannot express the business boundary.

Privacy and sharing

Topic input remains entirely in the browser and is deliberately excluded from the URL, copied parameter set, and exported parameters. That prevents the share feature from placing a potentially sensitive hierarchy in browser history or referrer data. The result summary can still be copied or exported as JSON, CSV, or Markdown, but it contains only the heuristic findings.

The page makes no network request with your topic. Avoid entering production secrets anyway; topic paths should not contain them in the first place.

FAQ

Is more than one + invalid MQTT?

No. The checker flags it because it widens the subscription surface. Whether it is acceptable depends on client role and authorization policy.

Why does a valid filter still receive a warning?

Syntax and least privilege are different questions. A filter may be legal while being too broad for the identity using it.

Can this tool test an ACL?

No. Use integration tests against the configured broker with allowed and denied identities. Include retained messages and $ topics where relevant.

Use Designing MQTT topic hierarchies to choose stable levels, separate commands from events, preserve tenant boundaries, and plan versioning before writing broker rules.