MQTT client ID generator
Generate up to 100 unique MQTT client IDs at once — random, UUID, hex or timestamp-based, with your own prefix. Turn on strict mode for IDs every MQTT 3.1.1 broker must accept.
Choose your options and press “Generate client IDs”.
IDs are generated in your browser with the Web Crypto API and never sent anywhere.
What the MQTT client ID is for
Every MQTT client sends a client identifier in its CONNECT packet. The broker uses it to recognise the client across reconnects: it is the key under which the broker stores the session — subscriptions, queued QoS 1 and QoS 2 messages and in-flight acknowledgements. If a device reconnects with the same ID and a persistent session, it picks up exactly where it left off. If it reconnects with a different ID, the broker treats it as a brand-new client and the old session lingers until it expires.
Rule 1: client IDs must be unique
A broker allows only one connection per client ID. When a second connection arrives with an ID that is already connected, the broker closes the first one — in MQTT 5 with reason code 0x8E Session taken over. This is the single most common cause of “my client keeps disconnecting” reports: two devices flashed with the same firmware constant, a web app opened in two tabs, or a service scaled to two replicas. Both clients reconnect, kick each other off, and the cycle repeats every few seconds. See MQTT connection errors for more symptoms.
Good client IDs are stable for a given device (so persistent sessions work) and unique across the fleet. A common pattern is a readable prefix plus something device-specific: a serial number, a MAC address, or a random value generated once and stored in flash. Browser and short-lived clients usually use a fresh random ID per connection.
Rule 2: the 23-character guarantee
The MQTT 3.1.1 specification says a broker must accept client IDs between 1 and 23 bytes long containing only 0-9, a-z and A-Z, and may accept anything else. Most modern brokers accept far longer IDs with dashes, underscores and colons, but some embedded and older brokers reject them with return code 2 (identifier rejected) or 0x85 Client Identifier not valid. If you cannot control which broker your devices will talk to, enable strict mode above. Differences between protocol versions are covered in MQTT 5 vs 3.1.1.
Empty client IDs
A client may send a zero-length client ID and let the broker pick one, but only together with a clean session (3.1.1) or clean start (5.0), because there is no stable key to store a session under. MQTT 5 brokers return the generated ID in the Assigned Client Identifier property. Some brokers disable this feature, so generating your own ID is the portable choice.
Ready to test? Paste a generated ID into the online MQTT client and connect to a public broker, or open a second tab with the same ID to see a session takeover happen live.
Client ID FAQ
How long can an MQTT client ID be?
MQTT 3.1.1 requires brokers to accept client IDs of 1 to 23 UTF-8 bytes using only 0-9, a-z and A-Z, and allows them to accept more. MQTT 5 keeps the same guarantee. In practice Mosquitto, EMQX, HiveMQ and most cloud brokers accept IDs of up to 65,535 bytes with any characters.
What happens if two clients use the same client ID?
The broker disconnects the existing connection and accepts the new one (a session takeover; MQTT 5 reason code 0x8E). If both clients reconnect automatically, they keep kicking each other off and both appear to be constantly disconnecting.
Can I use an empty client ID?
Yes, if you request a clean session (MQTT 3.1.1) or clean start (MQTT 5). The broker then assigns a unique ID; MQTT 5 returns it in the Assigned Client Identifier property. An empty ID cannot be combined with a persistent session in MQTT 3.1.1.
Should the client ID be secret?
No. Client IDs are identifiers, not credentials — they appear in broker logs and are easy to guess. Always authenticate with a username and password, token or client certificate, and use ACLs to stop one client from impersonating another.