---
source_url: https://www.pubnub.com/docs/general/channels/channel-naming
title: Channel Naming Conventions
updated_at: 2026-06-04T11:10:03.063Z
---

> Documentation Index
> For a curated overview of PubNub documentation, see: https://www.pubnub.com/docs/llms.txt
> For the full list of all documentation pages, see: https://www.pubnub.com/docs/llms-full.txt


# Channel Naming Conventions

PubNub doesn't define specific types for a channel. Your use case defines the purpose and the kinds of messages you send on that channel. Learn more in [Channel overview](https://www.pubnub.com/docs/general/channels/overview).

* Message broadcasting, such as speaker to audience announcements.
* Private/direct chat: typical 2 person chat sessions.
* Group chat: 3 or more participant chat sessions.
* Live audience engagement chat: hundreds to tens of thousands of users chatting concurrently.
* Control signals: controlling devices or client apps.
* Signal protocol, for example, getting clients connected over audio/video.
* Inbox messages, such as invitation for the user to chat or notification to the user of new messages/activity.

## Descriptive channel naming with prefixes

While it's possible to use a User ID generator to name channels, the randomness of a User ID format prevents the developer from taking advantage of many PubNub features.

###### Enhance channel naming with serverless processing

Dot-delimited naming conventions unlock powerful platform features. [Functions](https://www.pubnub.com/docs/serverless/functions/overview#using-wildcards-in-functions) can bind to wildcard channel patterns so one Function processes messages from all matching channels. [Events & Actions](https://www.pubnub.com/docs/serverless/events-and-actions/overview#event-listeners) listeners can filter events by channel name, letting you react to publishes or presence changes on specific channels or groups of channels without code. Consistent naming also simplifies [pattern-based access grants](https://www.pubnub.com/docs/general/security/access-control) and [Insights channel pattern analytics](https://www.pubnub.com/docs/pubnub-insights/api-overview#metrics).

Use a prefix that identifies the purpose of the channel or the types of messages sent on that channel.

Add a dot (`.`) after the prefix to enable wildcard-based features, including:

* Wildcard Subscribe
* Wildcard channel binding for Functions
* Presence ACL configuration (an advanced means for configuration presence based on channel naming patterns)

:::tip Wildcard subscribe
For more information, refer to [Channel Subscriptions](https://www.pubnub.com/docs/general/channels/subscribe#wildcard-subscribe).
:::

Validate your channel name:

Channel name

## Recommended channel naming convention

A reliable default channel naming convention is `[channelType].[channelID]`, where `[channelID]` could be the ID of the chat room, a user ID, device ID, an event ID, region, department, customer ID, or whatever is appropriate for the use case. Use ASCII characters for all parts of the channel name, for example:

* `group.room123`
* `inbox.user123`
* `command.device123`

You can also compose the `channelID` portion of the full channel name from multiple entities. For example, combine an event ID with a room ID, or an event ID with a customer ID:

* `group.event123.room123`
* `inbox.customer123.user123`
* `broadcast.customer123.event123.room123`

:::warning Channel name depth
If your channel name is more than 3 levels deep (for example `name(lvl1).user(lvl2).event(lvl3).room(lvl4)`), you must disable the Wildcard Subscribe feature in the [Admin Portal](https://admin.pubnub.com/) to be able to publish to this channel. Otherwise, you will only be able to subscribe to it.
:::

### Naming consistency

Consistent naming convention is particularly useful when managing access to multiple channels. When granting permissions, you can specify them as a regular expression rather than a list of channels.

Using RegEx limits the size of the token that will be sent in the grant request. This way you keep your grants simple and within the size limit (32 KiB). For more information about granting permissions, refer to [Manage Access](https://www.pubnub.com/docs/general/security/access-control).

## Delimiter variations

You should consider the delimiters that you use because the `.` is a special character and is only useful for PubNub features at the second level: `foo.bar` vs `foo.bar.baz`.

In other words, you can only leverage `foo.*` but not `foo.bar.*` for function channel binding.

For most use cases, however, using a `.` after the channel type prefix is the best option since you most likely want to have a specific Function that handles all messages over that type of channel or possibly no Function at all.

There are occasions when you want to have a different Function implementation per customer or event, so that would factor into where that`.` is positioned.

For more detailed channel naming convention recommendations tailored to your specific requirements, feel free to contact your PubNub account manager and solution architect.

## Terms in this document

* **Channel** - A pathway for sending and receiving messages between devices, created automatically when you first use it, that can handle any number of users and messages for different communication needs, like 1-1 text chats, group conversations, and other data streaming.
* **Channel pattern** - A way to group and analyze channel data to track performance metrics like message counts and user engagement over time with PubNub Insights.
* **User** - An individual or entity that interacts with a system, application, or service. In PubNub, a user typically refers to someone who sends or receives messages through the platform, identified by a unique user ID or username.
* **User ID** - UTF-8 encoded, unique string of up to 92 characters used to identify a single client (end user, device, or server) that connects to PubNub.