In industrial telemetry the topic string on an MQTT message is often longer than the reading it carries. A well-structured topic that names the site, the asset, and the tag can run to dozens of characters, and every single PUBLISH repeats it in full. Over a metered cellular link, sending that string thousands of times a day wastes bytes on information the broker already knows. MQTT 5.0 added the topic alias to fix exactly this, letting a publisher send the long topic once and then refer to it by a small integer. This guide explains what a topic alias is, how the mapping is negotiated, and why it matters for edge publishers on constrained networks.
MQTT Topic Alias in one line: An MQTT topic alias is an MQTT 5.0 feature that lets a client send a long topic string only once, together with a small integer alias, and thereafter publish to the same topic using just that integer instead of the full string. It is a per-connection, per-direction optimization that cuts the byte overhead of every repeat message, which matters most for edge publishers sending frequent telemetry over metered or low-bandwidth links.
In MQTT the topic is a string that names where a message belongs, and in a well-organized system that string is deliberately descriptive. A topic might spell out an enterprise, a site, an area, a device, and a specific measurement, so it reads clearly and routes cleanly. The cost of that clarity is length. Every PUBLISH packet carries the topic string in full, so a device that reports a two-byte pressure reading many times a minute may spend far more bytes on the repeated topic than on the data itself.
The topic alias removes that repetition. On the first PUBLISH to a given topic the client includes both the full topic string and a topic alias property, which is a small integer chosen by the sender. The broker records the pairing for the life of that connection. On every subsequent PUBLISH the client sends an empty topic string and only the alias integer, and the broker looks up the string it stored earlier and treats the message as if the full topic had been sent. Two bytes of alias stand in for a topic that might otherwise be forty or fifty bytes long.
The mapping is strictly local to one connection and one direction. It is not a shortcut that other clients can see, it does not persist across reconnects, and a client-to-broker alias is independent of any alias the broker uses when delivering messages back to a subscriber. If the connection drops and is re-established, the aliases start empty again and each topic must be introduced with its full string once more before it can be referred to by number.
A topic alias only works if both ends agree on how many aliases are allowed, because the receiver has to allocate a table to remember the mappings. This is negotiated with the topic alias maximum property. When a client connects, the broker can advertise the largest alias value it is willing to accept from that client, and when the broker sends its CONNACK the client learns the ceiling it must stay under. If the broker sets a topic alias maximum of zero, it is declining to accept aliases at all, and the client must keep sending full topic strings.
The integers chosen matter less than staying within the agreed range and being consistent. A publisher typically assigns alias one to its most frequent topic, alias two to the next, and so on, up to the maximum the broker allows. If a device publishes to more distinct topics than the alias maximum permits, it simply cannot alias them all, so it usually aliases the busiest topics and sends the rare ones in full. Reusing an alias number for a new topic is permitted and re-binds it, so a client can recycle a slot when a topic is no longer needed, at the cost of re-sending the full string when it comes back.
Because the alias table is bounded and per-connection, topic aliasing is best thought of as a compression aid rather than a naming scheme. It does not change how topics are structured, how wildcards match, or how retained messages behave. It changes only the number of bytes on the wire for the topics a device sends most often, which is precisely the overhead that dominates on a chatty telemetry link.
For a field gateway pushing readings to a cloud SCADA platform over a cellular modem, bytes have a direct cost. Many industrial SIM plans are billed by data volume, and even where they are not, a marginal or congested link makes every unnecessary byte a small tax on reliability. A pump controller that publishes several tags every few seconds accumulates an enormous number of PUBLISH packets over a month, and if each one repeats a long topic string, the topics alone can account for a large share of the traffic. Topic aliasing trims that steadily, message after message.
The saving compounds with the structure that makes MQTT topics readable in the first place. The very naming discipline that a monitoring platform encourages, with clear site and asset paths so operators can subscribe intuitively, is what makes the strings long. Topic aliasing lets an operation keep those descriptive topics for humans and subscribers while paying the byte cost only once per connection at the publishing edge. It is a rare case where clarity and efficiency do not have to trade off against each other.
In a cloud SCADA context, a platform like Merobix ingesting telemetry from many remote sites benefits when each edge publisher is frugal on its uplink, because leaner messages mean fewer retransmissions on flaky links and lower data bills for the operator. Topic aliasing is one of several MQTT 5.0 features an edge device can use to keep its cellular footprint small. It sits alongside other efficiencies, such as sending readings only when they change, and together they let a site report frequently without saturating a modest cellular plan.
No. A topic alias mapping lives only for the duration of a single MQTT connection. When a client disconnects and reconnects, the alias table is empty again, so each topic must be sent once with its full string before it can be referred to by its integer alias. This is why aliasing helps most on stable, long-lived connections that publish many messages between reconnects.
No, they are different mechanisms at different layers. An MQTT topic alias is a transport-level shorthand for the topic string on a PUBLISH packet, negotiated per connection. A Sparkplug metric alias is an application-level integer that stands in for a metric name inside the payload after a birth message defines it. They solve similar byte-saving problems but operate independently, and a system can use both at once.
Yes. Topic aliases are a feature introduced in MQTT version 5.0 and are not available in MQTT 3.1.1. Both the client and the broker must support MQTT 5.0, and the broker must advertise a non-zero topic alias maximum, before a publisher can start using aliases. On an MQTT 3.1.1 connection every message continues to carry its full topic string.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.