Telegram Supergroup: What Changes and What Breaks

Most people meet the word supergroup at the worst possible moment: something stopped working, a bot started returning errors, or a saved chat identifier suddenly pointed at nothing. The group looks the same on screen, the members are all still there, and yet the thing your code was talking to is gone.

That happens because Telegram has two entirely different objects that both look like a group, and it will convert one into the other without asking. The conversion is automatic, it is triggered by ordinary administrative actions, it changes the identifier, and it cannot be undone.

This article covers the three chat types and their published ceilings, exactly what triggers migration, what breaks when the identifier changes, which capabilities only exist on the supergroup side, how topics differ from migration in the one way that matters, and the boost levels that gate the newer features.

Three Kinds of Chat, Not Two

The mental model most people carry is groups and channels. It is missing a category.

Basic groups

The original group type, small and simple. Underneath it is a distinct object with its own constructor, and that is the important part: it is not a small supergroup, it is a different thing with different capabilities.

That difference is invisible in the interface, which is the whole reason this subject confuses people. Two groups sitting next to each other in the same chat list can be different types entirely, with different limits, different permissions and different addressing, and nothing on the screen says so until you try to do something one of them cannot.

Supergroups and channels are the same object

This is the detail that reorganises everything else. A supergroup and a broadcast channel are the same underlying structure, distinguished only by a flag. One carries a flag marking it as a megagroup, the other a flag marking it as a broadcast. That is why they share so much behaviour, including their identifier format.

It also explains a great deal of apparently odd behaviour. Anything written about channels usually applies to supergroups, tools that claim to work with channels frequently work with supergroups without anybody planning it, and the errors you get are often worded for channels even when you are looking at a group. None of that is sloppiness; it is one object wearing two labels.

And there is a fourth for extreme sizes

Beyond supergroups sit gigagroups, which remove the participant ceiling entirely for groups larger than a supergroup supports. Most people will never encounter one, but it explains why the size answer is not simply a single number.

The existence of that fourth type is also a useful sanity check on ambition. If a plan involves a community large enough to need it, the plan involves a community larger than almost anything on the platform, and the structural question stops being the hard part long before then.

The Two Member Ceilings

The numbers are published as configuration values rather than folklore.

Two hundred, then two hundred thousand

A basic group holds at most two hundred members. A supergroup holds up to two hundred thousand. Both figures come from named configuration keys rather than from a help article, which means they are the values the client actually enforces.

Quoting configuration keys rather than round numbers matters here because these figures do change. A value read from the platform is current by definition; a number somebody typed into an article three years ago is a historical artefact presented as a fact, and this topic is full of the second kind.

The gap is the point

There is no middle tier. A group either lives in the small world or the large one, and the jump between them is a thousandfold. That is why the platform migrates automatically rather than asking: there is no gentle path between the two, so it moves you the moment you need anything from the far side.

Seen that way the automatic migration is a kindness rather than an ambush. The alternative would be an error telling you that your group cannot do the thing you just asked for, followed by a manual conversion you would have to discover on your own. The platform simply does it, and the cost of that convenience is that it happens without a conversation.

Why this matters before you grow

If you expect a community to pass two hundred people, you are going to end up in a supergroup regardless of preference. Knowing that in advance means you can migrate deliberately, at a quiet moment, rather than discovering it mid-campaign when the identifier changes underneath something you built.

There is a second reason to do it early that has nothing to do with software. Migration is invisible to members except for a service message, and in a small group nobody notices at all. In a large active one it arrives in the middle of conversations, and somebody always asks what happened, which is a question with a long answer.

How a Group Becomes a Supergroup Without Being Asked

The trigger is broader than most people expect, and it is not only about size.

Any supergroup-only action does it

A basic group migrates automatically if an admin tries to execute an action that is only supported by supergroups. That is the actual rule. It is not a size threshold with a warning; it is any attempt to use a capability that only exists on the other side.

Which means there is no threshold to watch and no warning to wait for. Groups with eleven members migrate every day, and groups with a hundred and ninety stay basic for years, because the trigger has nothing to do with how many people are in the room.

Which actions those are

Setting a public username, turning on granular permissions, linking the group to a channel as its discussion area, enabling the administrative log, and converting to a forum are all supergroup-only. Any one of them performed by an admin migrates the group there and then.

Worth noting that the list grows over time. Every new group capability the platform ships is built on the supergroup structure, because the basic group is effectively frozen. So the practical rule is not to memorise the list but to assume that anything modern is supergroup-only, and to treat any unfamiliar setting as a potential trigger.

So it usually happens by accident

Somebody decides the group should be findable, sets a username, and has just performed a structural conversion. Nothing in that moment feels like a database migration, which is precisely why the consequences arrive later and appear unrelated.

The delay is what makes it hard to diagnose. The username was set on Tuesday and the scheduled post failed on Friday, so nobody connects the two. Anyone maintaining automation for a group they do not administer should ask whether anything changed structurally before investigating their own code, because the answer is often yes and nobody thought to mention it.

The response you get back

The result of a migration carries two objects at once: the old group with a field pointing at what it became, and the new supergroup itself. That pairing exists so software can follow the change, and any tool that ignores it will keep addressing something that no longer receives messages.

Reading that pointer is a few lines of work and it is the difference between software that survives a migration and software that quietly stops. Most libraries expose it; most integrations never check it, because it only matters on a day that has not happened yet.

The Identifier Changes, and What Breaks

This is the part that generates the support tickets.

A new identity, not a renamed one

The migrated supergroup receives new identifiers, and messages have to be sent to the new entity using different addressing values. The old identifier does not become an alias. It refers to the object that was left behind.

That object still exists, which is the confusing part. It is not deleted, it does not error, and requests against it can succeed. They simply have no effect anybody can see, because the members and the conversation moved elsewhere and left an empty structure holding the old address.

The history splits in two

Message history is not merged for you. Retrieving the full record means requesting two lists with two different addresses and joining them on the client side. Any archive, export or analytics job written before the migration will silently see only half.

Whether it sees the older or newer half depends on which address it holds, and both failure modes look plausible. A report that shows the last two months and nothing before it, or everything up to a date and then silence, is usually this rather than a data loss. Checking for a migration is faster than debugging the export.

What this does to a bot

Anything holding a stored chat identifier stops working, and it does not fail loudly. Scheduled posts go to a group nobody reads, moderation stops applying, and integrations keep reporting success while addressing an empty shell. If a bot mysteriously went quiet in one group and works everywhere else, this is the first thing to check.

The single-group detail is the diagnostic. A credential problem, a network problem or a code problem affects everything, so a failure confined to exactly one chat is almost always about that chat rather than about your system. That narrows the search to two or three possibilities, and this is the most common of them.

The fix is boring and reliable

Store identifiers as something you can update, resolve them again after any structural change, and treat the migration pointer as a signal to re-read rather than an oddity to ignore. Our guide on Telegram admin rights covers the permission side that usually changes at the same moment.

Re-resolving is also cheap enough to do routinely rather than only after trouble. A daily job that refreshes the chats an integration knows about costs a handful of requests and removes an entire class of silent failure, which is a good trade for anything that matters.

Migration Is One Way

The most common question about supergroups has a short and unwelcome answer.

There is no way back

Conversion to a supergroup is one way only. There is no downgrade, no revert and no support process. A group that becomes a supergroup stays one for the rest of its life.

It is worth being blunt about that because a great deal of writing on this subject implies otherwise, usually by confusing it with forum mode, which does reverse. The two conversions look similar in the interface and behave in opposite ways, and mixing them up is the most common error in this whole topic.

Why people want to go back

Usually because something about the new object surprised them, most often the identifier change or the fact that new members can read history. Neither is reversible by undoing the migration, because the migration cannot be undone; they are handled with settings inside the supergroup instead.

History visibility in particular is a setting rather than a consequence. A supergroup can be configured so that new members do not see what was said before they arrived, which addresses the actual worry without needing anything reversed. Anybody asking how to undo a migration is usually asking this question in the wrong words.

What to do instead

If the change genuinely does not suit the community, the only real option is creating a fresh basic group and moving people across, which costs the history and most of the members. That is a high price, and it is a good argument for treating the first username you set on a group as a decision rather than a detail.

If you do have to rebuild, do it in the order that loses least. Create the new group, invite the core members deliberately rather than in bulk, and leave the old one running long enough for people to notice the move. Our article on Telegram invite links covers the mechanics of moving people without losing half of them.

What a Supergroup Can Do That a Basic Group Cannot

The capability list is the reason the platform pushes everything in this direction.

Public identity and discovery

A supergroup can hold a public username, which makes it linkable and findable rather than reachable only by invitation. That single capability is the most common migration trigger, and it changes the group from a private room into a destination. Our article on how to find Telegram groups covers what that looks like from the searcher's side.

Public identity cuts both ways and the second edge is sharper than people expect. A findable group is findable by everybody, including the people who scrape member lists for a living, and the same properties that let genuine members find you let everything else find you too. That is a reason to set the permission defaults before publishing the username rather than afterwards.

Administrative visibility

Supergroups have an administrative log recording what admins did and when. In a basic group there is no record, so a deletion or a ban is simply something that happened. For any group with more than one moderator that log is the difference between a team and a series of arguments.

It is also the only evidence that exists when a member claims their message was deleted unfairly. Without it the conversation is one person's memory against another's; with it the question is settled in a few seconds. Groups that grow past a handful of moderators discover this the hard way roughly once.

Structure and integration

Only a supergroup can be converted into a forum, be attached to a channel as its discussion area, or carry geolocation features. Each of those turns the group from a single stream into a component of something larger.

The pattern behind all three is the same. A basic group is an endpoint, while a supergroup is a building block, and the platform has spent years adding ways to connect building blocks to each other. Anything that involves a group being part of a larger structure lives on this side of the line by design.

The trade you are accepting

All of that arrives with public visibility, a larger ceiling and a permanent identity change. There is no configuration in which you get the capability list and keep the small private object, because they are different structures rather than different settings.

Which is worth accepting rather than fighting. Every guide promising the capabilities without the consequences is describing something that does not exist, and time spent looking for that configuration is time not spent deciding whether the trade is right for this particular community.

Permissions Become Granular, and So Does Silence

The permission model is the least discussed and most useful difference.

Rights per member, not per role

Supergroups support a granular permissions system, which means restrictions can be applied to a single member rather than only to everybody. You can stop one person sending media without changing what anybody else can do, and you can do it temporarily.

Temporary is the underrated half. A restriction with an expiry needs no follow-up, no reminder and no second decision, which means a moderator can act immediately without committing to anything permanent. Most heated moments resolve themselves within a day, and a tool that matches that timescale prevents the escalation that permanent measures cause.

Default rights for everybody

The same system sets what an ordinary member may do by default, covering messages, media, links, polls and invites separately. Turning off link posting for new arrivals is a two-second change that removes most low-effort spam without any bot at all.

Starting restrictive and loosening later is also easier than the reverse, socially as well as technically. Adding a restriction after an incident reads as punishment aimed at whoever caused it; having it in place from the start reads as house rules. The setting is identical and the reception is not.

Slow mode

A supergroup can enforce a minimum interval between messages from the same member, configured in seconds. It is the single most effective tool against a group that has become unreadable, and it works without banning anybody or appointing more moderators. Bots that automate this sit on top of it rather than replacing it, which our guides to Rose bot and Combot cover in practice.

Choose the interval to match the room rather than copying a number. A few seconds is enough to break a flood while leaving a real conversation intact; a minute turns an active group into a noticeboard. If in doubt, start short, since the point is to slow a stampede rather than to make talking difficult.

Restriction beats removal

Because restrictions are per member and can be temporary, the correct response to a difficult member is usually not a ban. A day of restricted posting resolves most situations and leaves no permanent grievance, which is an option a basic group simply does not have.

That difference changes how a community feels over time. Groups whose only tool is removal accumulate former members with a grievance, while groups that can restrict accumulate members who had a bad day and stayed. Over a year those two paths produce noticeably different rooms.

Topics, and the Conversion That Does Reverse

Forum mode looks like another one-way door and is not, which is worth knowing precisely because migration taught everybody to be cautious.

What enabling it does

A supergroup can be turned into a forum, splitting the single conversation into separate topics. It is a mode on an existing supergroup rather than a new object, which is why it behaves so differently from migration.

Keeping that distinction straight is worth the effort. Migration replaces the object and issues a new address; forum mode changes how one object presents its messages and touches neither. Nothing breaks when you enable topics, which is exactly why it is safe to try and exactly why people who have been burned by migration hesitate anyway.

It can be switched off again

Forums can be converted back to ordinary supergroups by the same method with the flag reversed. Only an owner can perform the toggle in either direction, but the door swings both ways. That makes trying topics a genuinely low-risk experiment.

The one thing that does not come back cleanly is the arrangement itself. Switching off returns a single stream, and the messages that were spread across topics land in one place, so a forum that ran for months and is then disabled produces a history that reads oddly. The structure is reversible; the tidiness is not.

Managing topics

Topics are created by anyone holding the manage-topics right, which is its own admin permission rather than a general one. They can be edited, deleted, pinned and reordered, and pinning is capped at a published limit of five per forum.

Five is enough for the topics people actually need at the top, which is usually rules, announcements and one or two active threads. If the list of things you want pinned is longer than that, the real problem is the number of topics rather than the pinning limit.

When topics help and when they hurt

They help a busy group with genuinely separate conversations and hurt a quiet one, because splitting a small amount of activity across six topics produces six silent rooms. The honest test is whether the current group already has parallel conversations interrupting each other. Our piece on Telegram topics goes through the setup in detail.

A reasonable starting shape is three topics, not ten. Every topic is a room that has to justify its own existence, and it is far easier to add one when a conversation genuinely outgrows the main thread than to consolidate six dead ones later without anybody feeling their corner was closed down.

The General Topic

Every forum has one topic that behaves unlike the others.

It exists whether you want it or not

A forum always contains a General topic carrying the identifier one, and it cannot be deleted. It is the default destination for anything sent without specifying a topic, which includes a great deal of automated traffic.

Service messages land there too, meaning joins, leaves, pins and topic creations all accumulate in the same place. In an active forum that turns General into a log nobody reads, which is precisely the situation the hiding option exists for.

It can be hidden

While it cannot be removed, it can be hidden from the topic list. That is the usual answer for forums where General fills with service messages and stray posts that make the list look untidy.

Why it matters for anything automated

A bot or integration that posts without naming a topic is posting into General, which in a hidden-General forum means posting somewhere nobody looks. That is a common cause of automation that appears to run correctly and produces no visible result.

The fix is to name the topic explicitly in whatever posts, and to test in the forum rather than in a normal group. An integration verified in a simple supergroup and then deployed into a forum is testing a different configuration from the one it will run in, which is how this reaches production in the first place.

Boost Levels Gate the Newer Features

Several supergroup capabilities are not available by default at all, and the gate is a boost level.

The published thresholds

A supergroup gains the ability to associate a custom emoji sticker set at boost level four. Profile background icons arrive at level five, transcription for members without the paid tier at level six, emoji status at level eight, fill wallpapers at level nine, and custom wallpapers at level ten. Each of those is a documented configuration key rather than a guess.

Reading them as a ladder rather than a list is more useful. The early levels change what a group can do, and the later ones change how it looks, so the return on each additional level falls as you climb. Knowing where that curve flattens is the difference between spending to unlock capability and spending to unlock decoration.

What that means practically

A new supergroup cannot look like an established one, no matter how it is configured, because the appearance features are behind a ladder. That is deliberate, and it is the mechanism that turns community support into visible status.

It also gives a genuine signal to anybody arriving. A group with the visual features has an audience that spent something on it, which is harder to fake than a member count and is read that way by people who know what they are looking at.

Where boosts come from

Members holding the paid tier grant them, and giveaways generate them at scale. Our articles on Telegram channel boost and the Telegram giveaway cover both routes, and the second is the one most groups actually use to climb.

Both routes cost money in the end, and the difference is who pays. Asking members to boost spends their goodwill and their limited slots; running a giveaway spends your budget and returns prizes to them. The second scales and the first does not, which is why groups that climb steadily are usually the ones running draws rather than the ones asking.

Do not chase the ladder

The lower levels unlock things people notice and the higher ones unlock wallpaper. Spending real money to reach level ten for a background is a decision worth stating out loud before making it, because said plainly it usually stops sounding sensible.

The same test works for the whole ladder. Say what the next level unlocks and what reaching it will cost, out loud, in one sentence. Levels four through six survive that test comfortably in most groups, and the top of the ladder rarely does unless the group is itself the product.

Linking a Discussion Group to a Channel

One of the migration triggers deserves its own explanation, because it is the most useful thing on the list.

What linking does

A supergroup can be attached to a broadcast channel as its discussion area, at which point every channel post gains a comment thread that lives in the group. The channel keeps its one-to-many shape and the conversation happens next door.

Members do not have to think about any of it, which is the point. Somebody commenting on a post is joining the discussion group without a separate decision, and the two objects behave like one thing from the outside while remaining two things underneath.

Why it is worth the migration

It is the only supported way to have both broadcast reach and real conversation without splitting your audience across two places they have to join separately. For anybody publishing regularly, that is the single strongest argument for being a supergroup.

It also solves a problem channels have on their own, which is that a broadcast with no reply path gives you no idea whether anything landed. Comments are the cheapest feedback available, and a channel running blind is usually a channel that keeps repeating whatever the author already believes works.

What it costs

Every comment thread is a surface for spam, and a linked group inherits the channel's entire audience rather than a self-selected subset. The permission defaults described earlier are the first line of defence, and they should be set before linking rather than after the first bad day.

Plan the moderation load as well as the settings. A channel of ten thousand generates comment volume no single person reads, and the discussion group becomes either a moderated space or an abandoned one within a fortnight. Deciding which before linking is easier than discovering it afterwards.

Working With Supergroups Programmatically

Everything above changes shape once code is involved.

The type flag decides your code path

Because supergroups and channels share a structure, code that distinguishes them by name or by guessing will eventually be wrong. The flags are the reliable signal, and reading them is the difference between handling a broadcast channel and a two-hundred-thousand-member group correctly.

It is also the difference between a tool that quietly does the wrong thing and one that refuses. Treating a broadcast channel as a group produces operations that make no sense there, and the platform will often accept them and do nothing useful, which is worse than an error because nobody investigates a success.

Member access is not the same

Retrieving participants behaves differently across the types, and the limits that apply to large supergroups are not the limits that apply to a small basic group. Anybody building a member list runs into this immediately, and our article on Telegram group scraping sets out what is actually retrievable rather than what a tool promises.

The short version is that visibility is a property of the chat rather than of your software. No amount of clever code changes what a given group exposes, so the useful question when a list comes back short is which chat you are reading rather than which library you are using.

Adding people is its own problem

The ceilings that matter when adding members are separate from the ceilings on group size, and they bite far sooner. That is the subject of our guide to Telegram add member limits, and it is the reason our Member Adder product exists as a paced tool rather than a loop.

Pacing is the entire product in that sentence. Anybody can write the loop; what takes work is a loop that respects limits it cannot see directly and backs off before the account pays for it, which is a different piece of software from the naive version despite doing the same thing.

Store what survives a migration

The practical rule for any integration is to keep a resolvable reference rather than a raw identifier, and to re-resolve after anything structural. That single habit removes the entire category of failures described earlier in this article.

The same applies to anything holding a channel reference for cloning or mirroring, which is why our Channel Clone product resolves rather than assumes. A mirror pointed at a stale address produces a job that runs perfectly and copies nothing.

If You Are Building an Audience

Structure is a means, so it is worth saying what it is a means to.

The supergroup is the container, not the growth

Migrating gives you a bigger container and better tools. It does not put anybody in the room. A group of forty in a structure that supports two hundred thousand is still a group of forty, and no setting changes that.

Worth saying because the migration feels like progress. Something happened, the group gained capabilities, and it is easy to read that as growth. It is preparation for growth, which is useful and is not the same thing, and confusing the two is how a channel ends up with an immaculate structure and no audience.

Where members actually come from

Two places: people who find you, and people you reach. Discovery depends on being public and on being where your audience already looks, which is what our scaling guide covers. Reaching people is outbound work, which is what our Mass DMs tooling and Account Manager handle, and what ProspectPulse is for finding in the first place.

Get the structure right early

Because migration is irreversible and identifier changes break things, the cheapest moment to become a supergroup is before anything depends on the group. Doing it deliberately on a quiet day costs nothing; discovering it during a campaign costs whatever was running at the time.

If a group already matters, do the conversion when the least is depending on it, then verify every integration afterwards rather than assuming. The verification takes minutes and the alternative is finding out from a member that something has been broken for a week.

What All of This Adds Up To

A supergroup is not a bigger group, it is a different object. It shares its structure with broadcast channels and differs from them by one flag, which is why it behaves so unlike the basic group it replaced. The ceilings are two hundred and two hundred thousand, with a further type beyond that for extreme sizes.

The conversion is the part that hurts. It fires automatically whenever an admin uses any capability that only supergroups have, including something as ordinary as setting a public username. It issues new identifiers, splits the message history into two lists that have to be joined by whoever is reading them, and it cannot be reversed under any circumstances.

What you get in exchange is the whole useful half of the platform's group features: public discovery, an administrative log, per-member permissions, slow mode, forum topics, and the ability to sit behind a channel as its comment section. Topics, unlike migration, can be switched off again. Several of the newer features sit behind published boost levels. And none of it puts a single person in the room, which remains a separate job entirely.

Frequently Asked Questions

What is a Telegram supergroup?

A distinct chat type that shares its underlying structure with broadcast channels and differs from them by a single flag. It holds far more members than a basic group and supports public usernames, an administrative log, per-member permissions, slow mode, forum topics and attachment to a channel as its discussion area.

What is the difference between a group and a supergroup?

They are different objects rather than different sizes. A basic group caps at two hundred members and has none of the advanced features. A supergroup holds up to two hundred thousand and supports public discovery, granular permissions, the admin log, forums and discussion linkage. The platform converts one into the other automatically.

How do I convert a group to a supergroup?

Usually you do not have to, because it happens by itself. A basic group migrates the moment an admin performs any action that only supergroups support, such as setting a public username or enabling granular permissions. If you want it deliberately, performing one of those actions is the way to trigger it.

Can I convert a supergroup back to a normal group?

No. Migration is one way only, with no downgrade path and no support process. The only way to have a basic group again is to create a new one and move people across, which loses the history and most of the members, so the original decision is effectively permanent.

Why did my group ID change?

Because the group migrated to a supergroup, which receives entirely new identifiers rather than keeping the old one. The previous identifier still refers to the object left behind. Anything holding the old value keeps addressing an empty shell, usually without reporting any error at all.

Why did my bot stop working in one group?

Check whether that group became a supergroup. After migration a stored identifier no longer reaches the members, and the failure is silent rather than loud. Re-resolving the chat and updating whatever you stored fixes it, and treating the migration pointer as a signal to re-read prevents it recurring.

How many members can a supergroup have?

Up to two hundred thousand, against two hundred for a basic group, both taken from named configuration values rather than a help page. For communities beyond that there is a further type which removes the participant limit entirely.

Can a supergroup be turned into a forum?

Yes, and unlike migration this one is reversible. An owner can enable forum mode and can switch it off again with the same method, so trying topics is a low-risk experiment. Topics themselves are managed by anyone holding the manage-topics right, and at most five can be pinned.

What is the General topic and can I delete it?

It is the default topic present in every forum, carrying the identifier one, and it cannot be deleted. It can be hidden from the topic list. Anything posted without naming a topic goes there, which is why automation in a forum with a hidden General often appears to do nothing.

Why can I not use custom wallpapers or emoji sets in my supergroup?

Because those features sit behind boost levels. Custom emoji sticker sets need level four, profile background icons level five, transcription for members without the paid tier level six, emoji status level eight, fill wallpapers level nine and custom wallpapers level ten. Boosts come from paying members and from giveaways.