MQTT 5 Topic Aliases Explained: Per-Connection Bandwidth

A factory floor PLC publishes temperature data to the topic factory/site-A/line-3/station-5/conveyor-7/motor/temperature every 100 milliseconds. That’s a 65-byte topic name sent 10 times per second, every second of every day. Over 24 hours, the topic name alone consumes 56 megabytes of bandwidth — not the payload, just the topic string. Multiply by hundreds of similar sensors and you have gigabytes of repeated topic names flowing across networks that already cost money per byte (cellular, satellite, leased lines).

MQTT 5 Topic Aliases solve this. The sender assigns a 2-byte integer alias to a topic on the first PUBLISH, then sends subsequent messages using just the alias and an empty topic name. That 65-byte topic becomes 2 bytes for every subsequent message — a 97% reduction in topic overhead. For high-frequency industrial publishers, this is one of the most operationally impactful MQTT 5 features.

This article explains how Topic Aliases work: the alias assignment mechanism, the per-connection state rules (the precision point most engineers get wrong), the bandwidth math, and how to deploy aliases correctly without triggering the Protocol Error codes (0x82, 0x94) that misuse generates.

For broader MQTT 5 context, see our MQTT 5 New Features Overview and MQTT 5 Flow Control (which Topic Aliases work alongside for bandwidth efficiency).

What Topic Aliases are in one paragraph

Topic Aliases are an MQTT 5 mechanism that lets publishers replace long topic name strings with 2-byte integer aliases in PUBLISH packets, dramatically reducing bandwidth for repetitive topics. The sender (client or Server) assigns an alias to a topic by including both the full topic name AND the Topic Alias property (0x23, UINT16 value 1 to Topic Alias Maximum) in the first PUBLISH. Subsequent PUBLISH messages reference the alias by including just the alias property and an empty topic name string. The receiver maintains a mapping table from alias to topic name. Critically, Topic Alias mappings are per Network Connection — they do NOT persist across reconnections, even when MQTT Session state is preserved via Session Expiry Interval. Misuse triggers Protocol Error (0x82) or Topic Alias invalid (0x94) Reason Codes, both terminating the connection.

Why Topic Aliases exist

MQTT topic names are UTF-8 strings that can be quite long, and they repeat with every PUBLISH. For systems with verbose hierarchical topic structures, this is wasteful:

The bandwidth problem in industrial IoT

Typical industrial topic patterns:

factory/eastern-region/plant-7/line-3/station-12/conveyor-A/motor-3/temperature
asset-tracker/fleet-1234/vehicle-001/gps/latitude
ot/site-04/building-2/floor-3/zone-7/sensor-mac-aabbccddeeff/value
sap-iot/customer-12345/tenant-acme/device-007/telemetry/v2/data

These are routine in production deployments — easy to read, semantically meaningful, but 40-80 bytes each. Sent 10 times per second per device, multiplied by hundreds or thousands of devices, the cumulative cost is significant. On constrained networks (cellular IoT, satellite, LoRaWAN bridges), every byte costs real money.

Why MQTT 3.1.1 had no solution

MQTT 3.1.1 sent the full topic name with every PUBLISH — there was no compression, no alias, no mechanism to avoid repetition. Engineers worked around it by shortening topic names (sacrificing readability) or accepting the bandwidth cost. Neither was ideal.

The MQTT 5 solution

Topic Aliases provide opt-in bandwidth reduction without requiring topic name compromises. You keep the long, semantically meaningful topic name and get bandwidth-efficient transmission. The first PUBLISH establishes the mapping; everything after uses the 2-byte alias.

This is one of the most operationally valuable MQTT 5 features for high-frequency publishers — sensors, industrial telemetry, machine-to-machine systems where bandwidth efficiency translates directly to cost savings.

Topic Alias Maximum (Property 0x22) — enabling the feature

Topic Aliases are opt-in. Both parties must agree to use them through the Topic Alias Maximum property exchanged during connection setup.

The Topic Alias Maximum property:

The value Topic Alias Maximum indicates the highest alias number the receiver will accept from the sender.

Direction semantics

This is where engineers commonly trip up:

• Client’s Topic Alias Maximum in CONNECT = the maximum alias the Server can use when publishing to this client
• Server’s Topic Alias Maximum in CONNACK = the maximum alias the client can use when publishing to the Server

The two values are independent. A client can declare Topic Alias Maximum = 0 (refusing Topic Aliases for inbound traffic) while still using Topic Aliases for outbound traffic if the Server’s CONNACK declares a non-zero Topic Alias Maximum.

Default value implication

The default Topic Alias Maximum is 0 — meaning Topic Aliases are disabled by default. To use them, at least one side must explicitly declare a non-zero value. Many MQTT 5 client libraries don’t enable Topic Aliases by default; engineers must opt in.

Tuning Topic Alias Maximum

Higher values consume more memory at the receiver (one entry per possible alias). Production systems balance memory cost against the number of distinct topics they expect to publish.

Topic Alias (Property 0x23) — the alias itself

The Topic Alias property is what appears in actual PUBLISH packets.

Property details:

The alias is a sender-chosen integer — the sender decides which topic gets which alias. The receiver just maintains the mapping table.

Why 0 is reserved

Alias value 0 is reserved to mean “no alias” — useful for absence-checking. If a receiver tries to look up alias 0 in its mapping table, that’s a protocol violation. Always use 1 through Topic Alias Maximum.

The first-publish vs subsequent-publish flow

Topic Aliases work via a two-phase exchange:

Phase 1: Establish the alias

The first PUBLISH for a topic includes BOTH the full topic name AND the alias number:

Sender → Receiver: PUBLISH
  Topic Name: "factory/site-A/line-3/sensor-42/temperature"
  Properties:
    Topic Alias: 7
  Payload: "23.5"

The receiver:

1. Reads the topic name normally
2. Stores the mapping: alias 7 → “factory/site-A/line-3/sensor-42/temperature”
3. Processes the PUBLISH as usual

Phase 2: Use the alias

Every subsequent PUBLISH for the same topic uses the alias with an empty topic name:

Sender → Receiver: PUBLISH
  Topic Name: "" (zero-length UTF-8 string)
  Properties:
    Topic Alias: 7
  Payload: "23.6"

The receiver:

1. Sees the empty topic name
2. Reads the Topic Alias property → 7
3. Looks up alias 7 in its mapping table → “factory/site-A/line-3/sensor-42/temperature”
4. Processes the PUBLISH using the looked-up topic name

Worked example

Connection established with Server Topic Alias Maximum = 10.

PUBLISH #1: 
  Topic: "factory/zone-1/temperature"  (28 bytes)
  Topic Alias: 1
  Payload: "21.3"
  [Total topic-related bytes: 28 + 2 = 30]

PUBLISH #2 (same topic):
  Topic: ""  (2 bytes for length=0)
  Topic Alias: 1
  Payload: "21.4"
  [Total topic-related bytes: 2 + 2 = 4]

PUBLISH #3 (same topic):
  Topic: ""  (2 bytes)
  Topic Alias: 1
  Payload: "21.5"
  [Total topic-related bytes: 4]

After the first message establishes the alias, every subsequent message saves 26 bytes. For 1000 messages per hour, that’s 26 KB/hour saved per topic.

Per-connection state — the critical rule

This is the most commonly misunderstood Topic Alias behavior. Read it carefully:

Topic Alias mappings exist for the duration of a single Network Connection only. They are NOT part of MQTT Session state. They do NOT persist across reconnections, even when Session Expiry Interval is non-zero and the Session itself is preserved.

When a client disconnects and reconnects:

• Session state IS preserved if Session Expiry > 0: subscriptions remain, unacknowledged QoS messages remain, retained messages remain
• Topic Alias mappings ARE NOT preserved: the alias table at both ends is empty on every new connection
• The client must re-establish aliases from scratch by sending full topic name + alias number again

Why this rule exists

Topic Aliases are an optimization — not a critical correctness feature. Persisting alias state across disconnections would add complexity for marginal benefit. The design keeps the implementation simple by making aliases per-connection.

Practical implications

Implementations need to:

1. Reset the alias table on every CONNECT (both client side and Server side)
2. Re-establish aliases on the first PUBLISH for each topic after reconnection
3. Not rely on alias persistence in any code logic

A common bug: a client maintains its alias table across reconnections internally and sends Topic Name: "", Topic Alias: 7 immediately after reconnecting. The Server has no mapping for alias 7 in the new connection and responds with DISCONNECT (Protocol Error 0x82).

Wireshark / debugging perspective

When troubleshooting, look at PUBLISH packets near connection establishment:

• The first PUBLISH for each topic should include both Topic Name AND Topic Alias
• Subsequent PUBLISH for the same topic uses empty Topic Name + Topic Alias
• After reconnect, the pattern restarts from “first PUBLISH” state

Re-mapping aliases mid-connection

A sender can change which topic an alias refers to during a single connection. To re-map an existing alias:

First PUBLISH:
  Topic: "factory/temperature"
  Topic Alias: 3
  [alias 3 now → "factory/temperature"]

Later PUBLISH:
  Topic: "factory/pressure"
  Topic Alias: 3
  [alias 3 now → "factory/pressure" — re-mapped]

Subsequent PUBLISH:
  Topic: ""
  Topic Alias: 3
  [refers to "factory/pressure"]

This is useful when the sender has a small Topic Alias Maximum but publishes to many topics. The sender can cycle aliases through different topics as needed — using more recent aliases for high-frequency topics, retiring less-used mappings.

Re-mapping is transparent to the receiver — the receiver just updates its mapping table. There’s no acknowledgement of the re-mapping; it’s a side effect of the PUBLISH.

When to re-map vs use new aliases

If Topic Alias Maximum allows it, use new alias numbers for new topics — simpler and less error-prone. Re-map only when you’ve exhausted your alias range. Senders with rich topic spaces should request higher Topic Alias Maximum values to avoid re-mapping complexity.

Independent client/Server alias spaces

The client’s outbound aliases and the Server’s outbound aliases are completely independent:

Client → Server publishes:
  Uses alias space governed by Server's Topic Alias Maximum
  Alias 5 might mean "factory/temperature" outbound from client

Server → Client publishes:
  Uses alias space governed by Client's Topic Alias Maximum
  Alias 5 might mean something completely different, or be unmapped

Each direction has its own alias table at each end. The Server maintains:

• Table A: aliases the client has established for client→Server traffic
• Table B: aliases the Server has established for Server→client traffic

Similarly the client maintains Tables A and B. There’s no shared alias space.

Asymmetric usage is common

Many deployments enable Topic Aliases in only one direction. A common pattern: high-frequency sensor data flows client→Server with aliases enabled (Server’s Topic Alias Maximum > 0), while infrequent control messages flow Server→client without aliases (Client’s Topic Alias Maximum = 0). This optimizes bandwidth where it matters and avoids complexity where it doesn’t.

Failure modes — 0x82 and 0x94

Misuse of Topic Aliases triggers two specific failure modes:

Reason Code 0x82 — Protocol Error

Triggered when:

• Topic Alias = 0 (the reserved value)
• PUBLISH has empty Topic Name AND no Topic Alias property (receiver has no way to determine the topic)
• PUBLISH has empty Topic Name AND Topic Alias references an unmapped alias (e.g., alias was never established in this connection)

The receiver responds with DISCONNECT (Reason Code 0x82) and closes the connection.

Reason Code 0x94 — Topic Alias invalid

Triggered when:

• Topic Alias value > the receiver’s declared Topic Alias Maximum

For example, if the Server’s CONNACK declared Topic Alias Maximum = 10 and the client sends a PUBLISH with Topic Alias = 15, the Server responds with DISCONNECT (Reason Code 0x94).

Diagnostic table

For broader Reason Code coverage, see our MQTT 5 Negative Acknowledgements article.

Bandwidth savings worked example

Let’s quantify the savings for a realistic industrial scenario:

Scenario parameters

• 100 sensors per gateway, each publishing 10 messages/second
• Each sensor uses topic: industrial/site-A/equipment-007/sensor-042/temperature (51 bytes UTF-8)
• Payload per message: 20 bytes (timestamp + value)
• 24-hour operation, 365 days/year

Without Topic Aliases

Per message overhead:
  Topic Name length (2 bytes) + Topic Name (51 bytes) = 53 bytes
  Per-message bandwidth: 53 (topic) + 20 (payload) + 10 (other MQTT headers) = ~83 bytes

Per sensor per day:
  10 msg/sec × 86,400 sec/day × 83 bytes = ~68.5 MB/day

Per gateway (100 sensors) per day:
  100 × 68.5 MB = ~6.85 GB/day

Per year:
  ~2.5 TB/year per gateway

With Topic Aliases (after first PUBLISH per topic)

Per message overhead:
  Topic Name length (2 bytes for empty) + Topic Alias property (3 bytes: id + UINT16) = 5 bytes
  Per-message bandwidth: 5 (topic+alias) + 20 (payload) + 10 (other headers) = ~35 bytes

Per sensor per day:
  10 × 86,400 × 35 = ~29 MB/day

Per gateway per day:
  100 × 29 MB = ~2.9 GB/day

Per year:
  ~1.06 TB/year per gateway

The savings

• Bandwidth reduction per message: 53 – 5 = 48 bytes (90% reduction in topic overhead)
• Per gateway per year: ~1.44 TB saved
• For 1000 gateways: ~1.44 PB/year saved
• On a cellular IoT network at $0.10/GB: ~$144,000/year savings per 1000 gateways

These numbers vary by topic length and message frequency, but the structural pattern is clear: Topic Aliases pay for themselves rapidly on any bandwidth-constrained deployment.

Interaction with other MQTT 5 features

Topic Aliases interact thoughtfully with other MQTT 5 mechanisms:

Flow Control synergy

Topic Aliases reduce per-message size. The same Receive Maximum allows more effective throughput because smaller messages mean less memory per in-flight message. For full Flow Control mechanics, see our MQTT 5 Flow Control article.

Maximum Packet Size compatibility

Smaller packets (thanks to aliases) are less likely to exceed Maximum Packet Size limits. Topic Aliases can help fit messages within tight packet size constraints on constrained networks.

Session Expiry — but not for aliases

Even when Session Expiry preserves session state across reconnections, Topic Alias mappings still reset. This is the precision point worth emphasizing — Session ≠ Topic Aliases.

User Properties don’t conflict

User Properties (0x26) on PUBLISH packets are additional metadata that doesn’t affect Topic Aliases. The two features can be used together freely.

Retained messages

A retained PUBLISH (RETAIN flag = 1) can use Topic Aliases like any other PUBLISH. The Server stores the topic name (resolved from alias) along with the retained payload, so retained messages remain valid across reconnections even though aliases don’t.

Subscription Identifiers — different mechanism entirely

Subscription Identifiers (Property 0x0B) are a separate MQTT 5 feature for subscription filtering — they don’t relate to Topic Aliases. Topic Aliases are sender-side bandwidth optimization for outbound topics; Subscription Identifiers are receiver-side filtering for inbound topics. Both can be used independently.

Backward compatibility

MQTT 3.1.1 has no concept of Topic Aliases. Compatibility considerations:

MQTT 5 client to MQTT 3.1.1 Server

The Server doesn’t support MQTT 5 features. The client’s CONNECT returns CONNACK with Reason Code 0x84 (Unsupported Protocol Version). Topic Aliases are moot in this scenario.

MQTT 3.1.1 client to MQTT 5 Server

The Server downgrades to MQTT 3.1.1 semantics. Topic Aliases are not used — full topic names are sent in every PUBLISH as in MQTT 3.1.1.

Mixed-version Server clusters

A Server fleet handling both MQTT 5 and MQTT 3.1.1 clients can use Topic Aliases with MQTT 5 clients and full topic names with MQTT 3.1.1 clients on the same Server. The two clients can publish to the same topic — internally the Server normalizes to the full topic name for retained messages, subscription matching, etc.

For broader version comparison, see our MQTT 5 vs MQTT 3.1.1 Comparison article.

Implementation guidance

For client implementations

1. Read Server’s Topic Alias Maximum from CONNACK before using outbound aliases
2. Maintain a Topic → Alias mapping table for outbound topics
3. Send full topic name + Topic Alias on first PUBLISH for any new topic
4. Send empty topic name + Topic Alias on subsequent PUBLISH for the same topic
5. Reset the entire mapping table on every disconnect/reconnect
6. Handle re-mapping when alias range is exhausted
7. Track and respect the receiver’s Topic Alias Maximum

For Server implementations

1. Declare Topic Alias Maximum in CONNACK (commonly 100-1000)
2. Maintain inbound alias table per connection
3. Handle re-mapping silently (no acknowledgement)
4. Detect violations:
   • Topic Alias = 0 → DISCONNECT 0x82
   • Topic Alias > Topic Alias Maximum → DISCONNECT 0x94
   • Empty topic + unmapped alias → DISCONNECT 0x82
   • Empty topic + no alias → DISCONNECT 0x82
5. Reset all alias tables when the Network Connection closes

Pseudocode

python

class TopicAliasManager:
    def __init__(self, server_topic_alias_max):
        self.max_alias = server_topic_alias_max
        self.topic_to_alias = {}  # outbound mapping
        self.next_alias = 1
    
    def get_or_create_alias(self, topic):
        if topic in self.topic_to_alias:
            return self.topic_to_alias[topic], False  # use existing
        if self.next_alias > self.max_alias:
            return None, False  # no alias available
        alias = self.next_alias
        self.topic_to_alias[topic] = alias
        self.next_alias += 1
        return alias, True  # new alias, send full topic
    
    def reset(self):
        # Called on every new connection
        self.topic_to_alias.clear()
        self.next_alias = 1

def publish(topic, payload):
    alias, is_new = topic_alias_mgr.get_or_create_alias(topic)
    if alias is None:
        # Out of aliases — send without alias
        send_publish(topic=topic, payload=payload)
    elif is_new:
        # First time using this alias — include full topic name
        send_publish(topic=topic, topic_alias=alias, payload=payload)
    else:
        # Reuse existing alias — send empty topic
        send_publish(topic="", topic_alias=alias, payload=payload)

Common errors and troubleshooting

Frequently asked questions

What is an MQTT 5 Topic Alias?

A Topic Alias is a 2-byte integer (UINT16, range 1-65,535) that an MQTT 5 sender uses to refer to a topic without sending the full topic name string. The first PUBLISH for a topic includes both the full topic name AND a Topic Alias property establishing the mapping. Subsequent PUBLISH messages for the same topic use an empty topic name string and reference the alias. This reduces bandwidth dramatically for repetitive topics.

How do Topic Aliases reduce bandwidth?

Topic Aliases reduce bandwidth by eliminating repeated topic name strings. A 50-byte topic name sent 10 messages per second consumes 500 bytes per second of topic-only overhead. After Topic Alias establishment, the same 10 messages use just 30 bytes (3 bytes per message for the empty topic + 2-byte alias). For high-frequency publishers (industrial sensors, asset trackers, telemetry systems), the savings compound to gigabytes per day per gateway and dollars per day on cellular/satellite networks.

Do MQTT 5 Topic Aliases persist across reconnections?

No. This is the most critical Topic Alias rule. Topic Alias mappings exist only for the duration of a single Network Connection. Even when MQTT Session state IS preserved (Session Expiry Interval > 0, Clean Start = 0), Topic Alias mappings are NOT preserved. Both the client’s and Server’s alias tables reset to empty on every new connection. The client must re-establish aliases by sending full topic names on the first PUBLISH for each topic after reconnection.

What is Topic Alias Maximum in MQTT 5?

Topic Alias Maximum (Property 0x22) is a UINT16 value (range 0-65,535) sent in CONNECT or CONNACK that declares the highest alias number the receiver will accept. The client’s Topic Alias Maximum in CONNECT applies to messages flowing from Server to client; the Server’s Topic Alias Maximum in CONNACK applies to messages flowing from client to Server. Default value is 0, meaning Topic Aliases are NOT used. To enable Topic Aliases, at least one side must declare a non-zero Topic Alias Maximum.

What is the difference between Topic Alias and Topic Alias Maximum?

Topic Alias (Property 0x23) is the specific alias number sent in PUBLISH packets — it identifies which topic the message refers to. Topic Alias Maximum (Property 0x22) is sent in CONNECT/CONNACK to declare the largest Topic Alias value the receiver will accept. So Topic Alias is the runtime value; Topic Alias Maximum is the configuration limit. A Topic Alias > Topic Alias Maximum triggers DISCONNECT with Reason Code 0x94.

What does Reason Code 0x94 mean in MQTT?

Reason Code 0x94 means “Topic Alias invalid” — the receiver got a PUBLISH with a Topic Alias value that exceeds its declared Topic Alias Maximum. For example, if the Server declared Topic Alias Maximum = 10 in CONNACK and the client sends a PUBLISH with Topic Alias = 15, the Server responds with DISCONNECT carrying Reason Code 0x94. To fix: either request a higher Topic Alias Maximum or use alias values within the declared range.

What does Reason Code 0x82 mean in the context of Topic Aliases?

Reason Code 0x82 (Protocol Error) is triggered by several Topic Alias misuses: (1) Topic Alias = 0 (the reserved value), (2) PUBLISH with empty Topic Name AND no Topic Alias property (no way to determine the topic), (3) PUBLISH with empty Topic Name and a Topic Alias that has not been previously established in the current Network Connection. The latter case commonly occurs when clients incorrectly assume alias state persists across reconnections.

Can I change which topic an alias refers to during a connection?

Yes. A sender can re-map an existing alias to a different topic by sending a PUBLISH with both a topic name AND the same alias number. This is useful when Topic Alias Maximum is small and the sender publishes to many topics — aliases can be cycled. Re-mapping is transparent to the receiver; the receiver just updates its mapping table. There’s no explicit acknowledgement of re-mapping.

Are client and Server Topic Aliases the same alias space?

No. Client and Server Topic Alias spaces are completely independent. Alias 5 in client→Server direction has no relationship to alias 5 in Server→client direction — they’re separate mapping tables. Each side maintains separate tables: aliases the other side has established for inbound traffic, and aliases this side has established for outbound traffic. This separation lets each direction be tuned independently.

Do Topic Aliases work with QoS 0, 1, and 2?

Yes. Topic Aliases work with all QoS levels — they’re orthogonal to QoS. A QoS 2 PUBLISH using Topic Aliases follows the same four-message handshake (PUBLISH → PUBREC → PUBREL → PUBCOMP) as a QoS 2 PUBLISH using full topic names. The alias is established on the first PUBLISH regardless of QoS level.

What’s the maximum value for Topic Alias Maximum?

The maximum value is 65,535 (the maximum a UINT16 can hold). In practice, most Servers default to much lower values (often 10-100) to limit per-connection memory usage. Production deployments can configure higher values if their topic spaces require many distinct aliases. Memory cost scales linearly: each potential alias requires storage for the mapping (typically 50-200 bytes per entry depending on average topic name length).

Should I use Topic Aliases in my MQTT 5 deployment?

Use Topic Aliases when: (1) you publish frequently (multiple messages per second per topic), (2) topic names are long (40+ bytes), (3) you operate on bandwidth-constrained networks (cellular IoT, satellite, LoRaWAN bridges), (4) you want to reduce per-message bandwidth costs. Skip Topic Aliases when: (1) you publish to many different topics rarely, (2) topic names are short, (3) bandwidth is plentiful, (4) simplicity is more important than optimization. Most industrial IoT deployments benefit significantly from Topic Aliases.