Discord Permissions: Why Yours Are Not Working

You gave the role the permission. You checked it twice. The person still cannot post in the channel, or worse, somebody who should not be able to see a channel can see it perfectly well. Nothing in the interface explains why, so you start moving toggles, and every toggle you move makes the next problem harder to reason about.

The interface is not lying to you, it is showing you one layer of an eight step calculation. Discord resolves permissions by starting at the server floor and applying overwrites in a fixed order, and at every level an allow is applied after a deny. That single ordering explains almost every case people describe as broken, including the one where a role that explicitly denies something loses to a role that allows it.

This article goes through the whole calculation in the order the platform performs it, the fifty two permissions and the ones that quietly require two factor authentication, why the names on your screen are not the names in the system, what the role hierarchy actually governs and the four cases it is limited to, how category syncing breaks the moment you touch a child channel, and the denials you never set that happen anyway. Every rule, name and number below was pulled from Discord's own developer documentation on 9 August 2026 rather than remembered.

Permissions Are a Number, Not a Checklist

What is actually stored

The documentation is explicit about the underlying shape. Permissions are stored in a variable length integer, serialised into a string, and calculated using bitwise operations. The example given is that the permission value 123 is serialised as the text 123. What looks like a page of switches is one number with bits set.

Two layers produce that number rather than one. A set of base permissions is configured at the server level for each role, and separately there are overwrites that can be assigned to roles or to individual members on a per channel basis. The screen you are looking at is usually only one of those two, which is the first reason a setting can look correct and behave otherwise.

Why that matters to you

Because a number cannot express a maybe. Every permission is on or off for a given calculation, and the whole system is about deciding which number applies to which person in which channel. Once you picture the screen as a view onto arithmetic rather than a list of preferences, the surprises stop being surprises.

The documentation even publishes the calculation as pseudocode, in two functions. One computes the base permissions from the server level roles, the other applies the channel overwrites on top of the result. That split is worth carrying in your head, because almost every confusing case is a disagreement between the two halves rather than a fault inside either one.

The version detail worth knowing

In the current interface version all permissions are serialised as strings, including the allow and deny fields inside overwrites. In the older version they were plain numbers, and the documentation notes those could not grow beyond thirty one bits. Since the highest permission bit is now well past that, anything still reading the old format is structurally incapable of seeing newer permissions.

You can see the growth in the bit positions themselves. The oldest permissions sit at the bottom of the range, creating invites at zero and kicking members at one, while recent additions like sending polls and pinning messages sit in the high forties and low fifties. A permission's number is a rough timestamp, and the ones near the top are the ones a stale integration is most likely to be blind to.

The Everyone Role Is the Floor

It is a real role with a real identifier

The default role is not a special case bolted onto the side. It is an ordinary role, and the documentation notes that it carries the same identifier as the server it belongs to. Everything else is layered on top of it, so whatever you grant there is granted to every member without exception.

Its position is zero

Role position is a number, and the default role starts at zero. Every role you create sits above it. That ordering is what the hierarchy rules further down operate on, and it is the reason a newly created role is meaningful the moment it exists even before you assign anything to it.

Roles carry more than permissions, which matters for how a server reads to the people in it. They have names and colours, and they can be pinned to the sidebar so their members are listed separately from everybody else. That display choice is independent of what the role can actually do, so a role can look important and hold nothing, or hold everything and look like nothing.

The mistake this causes

The common error is treating the default role as a place to be generous, then trying to claw permissions back per channel. That works, but it means every new channel starts permissive and you are always subtracting. Starting restrictive at the floor and adding upward produces a server you can still reason about a year later. The same argument applies on the other platform we write about most, in the breakdown of every admin right.

There is a structural reason the restrictive approach holds up. Roles can carry separate permission profiles for the server context and the channel context, so a role that is deliberately thin at the server level can still be given exactly what it needs in the two channels where it works. Building that way means the server level answer to what can this role do stays short enough to read.

Fifty Two Permissions, and Eleven With a Condition

The size of the list

There are fifty two permissions in the table, occupying bit positions from zero to fifty two with one position unused. That is a large surface, and the reason most servers are configured badly is not carelessness. Nobody sits down and considers fifty two independent decisions.

They are also not evenly weighted, which is the part worth internalising. A handful decide whether somebody can destroy or reshape the server, a larger group decides what they can do in a conversation, and a long tail covers voice features like priority speaking, soundboards and embedded activities. Reading the list once and sorting it into those three groups is an hour that pays for itself.

The group that decides who can be reached at all is the one worth reading first if a server is part of how you find customers. Creating invites, mentioning everyone, and managing webhooks each hand somebody a channel to the whole membership, and each is a single toggle. The wider version of that thought, on a platform built the opposite way, is in how invite links actually behave.

Each one is scoped to channel types

Every permission carries markers for the channel types it applies to, text, voice and stage. So a permission is not simply on or off for a person, it is on or off for a person in a kind of place. A voice only permission set on a text channel is not a subtle bug, it is a value with nowhere to apply.

The same markers are what tell you which permissions can appear in a channel overwrite at all. If a permission carries no marker for the type of channel you are editing, no amount of setting it there will change behaviour. That is a common source of the feeling that a change did nothing, because it genuinely did nothing.

Voice channels are where this shows up most, because the voice specific permissions are numerous and none of them mean anything in a text room. Somebody sets priority speaker or the soundboard permissions on a text channel, sees no change, and concludes the whole system is unreliable. It behaved exactly as documented, which is the recurring theme of this article.

Eleven require two factor authentication

Eleven of the fifty two carry a marker meaning they require the owner account to use two factor authentication when the server has server wide two factor enabled. They are the destructive ones, including kicking, banning, the administrator permission itself, and managing channels or the server. If a moderator action fails on a protected server, this is the first thing to check.

Note where the requirement actually sits. It is on the owner account using two factor authentication, not on the moderator performing the action, and it only applies once the server has the setting enabled. So a server can work perfectly for months and then have every moderation action start failing after a single change made by one person at the top.

The Client Does Not Use the Real Names

Discord says so itself

This is not a community complaint, it is a note in the documentation. It states that permission names may be referred to differently in the client, and then gives examples. Manage Permissions refers to the role management permission. Use Voice Activity refers to a different constant entirely. Timeout Members refers to the moderate members permission.

Why this costs people hours

Because every guide, bot configuration page and support answer uses the system names, while your screen uses the friendly ones. Somebody tells you to grant a permission, you search the interface for that exact wording, and it is not there. The permission is there. The label is not.

It also breaks searching in the other direction. Somebody reports that a bot needs a permission using the friendly name, you grant something that sounds close, and the bot still fails because the constant it asked for was a different one. Matching by meaning rather than by string is how a server ends up granting more than it intended.

The habit that fixes it

When you are configuring anything that talks to the interface, work from the system names and treat the interface label as a translation. Any bot that asks for a permission is asking for the constant, not the phrase on your settings page, and matching them by eye is how servers end up with the wrong thing granted.

The Eight Step Calculation

The order, exactly as documented

Permissions are applied in a fixed hierarchy of eight steps. Base permissions for the default role at server level. Permissions allowed by the user's roles at server level. Channel level denies for the default role, then channel level allows for the default role. Channel level denies for specific roles, then allows for specific roles. Finally member specific denies, then member specific allows.

There is a separate mechanism sitting alongside this one that is easy to miss. Application command permissions let you enable or disable specific commands for entire channels as well as for individual roles or users. So a command can be unavailable in a channel while the underlying permission looks perfectly fine, and nothing in the permission screen will tell you.

Read the pattern rather than memorising the list

The shape is simpler than the list. It moves from broad to narrow, server before channel, role before individual, and at every single level the deny is applied before the allow. That last detail is doing more work than the other seven steps combined and it is the subject of the next section.

Why the order is worth knowing by heart

Because it turns an argument into a lookup. When two people disagree about why somebody can see a channel, the answer is always at one of eight named positions, and you can walk them in order until you find the step that decided it. Without the order you are guessing at a system that is not guessing at all.

It also tells you where to make a change. If you want something to apply to everyone in one room, the default role overwrite at channel level is the correct lever. If you want an exception for one person, the member specific overwrite is the last word and nothing after it can undo it. Choosing the right step is most of what good server configuration is.

Why Allow Beats Deny

The example is in the documentation

The documentation gives the case directly. A user has two roles. Role A denies the view channel permission on a channel. Role B allows it on the same channel. The user can view the channel. Then it states the reason plainly, which is that this happens regardless of the role positions.

What that means for your server

It means a deny is not a lock. It is one value in a sequence that something later can overturn, and the thing that overturns it does not have to outrank it. If you have ever built a private channel by denying access to one role and then wondered how somebody got in, look for a second role on that person that allows it.

The member specific level is the exception worth remembering, because it sits at the very end of the sequence. A member specific deny still loses to a member specific allow, but both of them beat everything at role level. When you genuinely need one person kept out of one room and nothing else will hold, that is the step that holds.

The design this forces on you

Grant access with allows and keep denies rare and deliberate. A server where visibility is built by adding permissions to specific roles behaves predictably. A server where visibility is built by denying things to various roles will eventually leak, and the leak will look like a platform fault rather than an arithmetic result.

The Hierarchy Governs Four Things and Nothing Else

What the rules actually cover

The documented hierarchy rules are narrow and worth listing. A bot may grant roles positioned lower than its own highest role. It may edit lower roles, but may only grant permissions it already has. It may only sort roles lower than its own. And it may only kick, ban, and edit nicknames for users whose highest role is lower than its own.

The sentence that follows them

Immediately after that list the documentation says that otherwise, permissions do not obey the role hierarchy. Four specific actions respect rank. Everything else, including who can see and post in what, is decided by the eight step calculation and does not care which role is higher.

Where this bites

People assume a higher role wins arguments. It does not. It wins the four listed contests, which are all about one account acting on another account, and it has no say at all in channel visibility. Half the confusion about permissions is this assumption applied to a system that never made that promise.

The second half of the confusion is the clause about editing. A bot may edit roles below its own, but it may only grant permissions it already holds itself. So a bot that cannot ban members cannot create a role that can, no matter how high the bot sits. That rule stops privilege from being manufactured out of nothing, and it is the reason a correctly ranked bot still refuses some requests.

Administrator Is Not Just a Bigger Role

What it actually does

The administrator permission is described as allowing all permissions and bypassing channel permission overwrites. Read the second half carefully. It does not merely grant everything at server level, it steps around the entire channel layer, which is where all your careful work lives.

Why that makes it dangerous

Every private channel, every restricted category, every deny you set is invisible to somebody holding it. There is no configuration that hides a channel from an administrator, because the bypass is part of the permission's definition rather than an oversight. Granting it to somebody you would not show everything to is a contradiction.

What to do instead

Grant the specific permissions the job needs. It is more work once and it is the difference between a server you can delegate and a server where every helper sees everything. Anybody building automation for a server should ask for the narrow set too, which is the same discipline as running a moderation bot properly.

There is a practical test for whether a request is reasonable. Ask what the tool would be unable to do without the permission it is asking for. If the answer is specific, grant it. If the answer is a shrug, the request is convenience rather than necessity, and convenience granted at this level is how a server ends up with four accounts that can delete it. Our notes on keeping working accounts alive come from the same instinct.

The same test applies to people, not only to software. Somebody helping you moderate needs the moderation permissions and nothing structural, and the difference between those two sets is the difference between a bad week and a lost server. Teams that end up running several of these at once usually stop doing it by hand, which is the case for a single panel across accounts rather than a browser full of tabs.

Category Syncing and How It Breaks

It is syncing, not inheritance

The documentation is careful with the word. Channels do not inherit from categories, they sync with them. If a child channel has the same permissions and overwrites as its parent category, it is considered synced, and further changes to the category are reflected in it.

One touch breaks it permanently

Here is the part that catches everybody. Any further change to a child channel causes it to become de-synced from its parent, and from that moment its permissions no longer change with the category. Not for that setting. For everything. The channel has left the arrangement.

Why servers drift

Because de-syncing is silent and happens during ordinary work. Somebody adjusts one channel during an incident, and six months later a category wide change reaches nineteen channels and skips that one. Nothing announced it. If a category change did not apply everywhere, you are looking for the channel that got touched.

The practical defence is to decide early which channels are meant to follow their category and which are deliberately special, and to write that down somewhere other than the server itself. A category with nineteen synced channels and one exception is fine when the exception is intentional and recorded. It is only a problem when nobody remembers making it.

Denials You Never Set

Viewing is the foundation

Denying the view channel permission implicitly denies other permissions on that channel. The documentation is precise about the mechanism, saying permissions like sending messages are not explicitly denied, they are ignored, because the person cannot read messages there in the first place.

Sending has its own chain

The same thing happens one level down. Denying the send messages permission implicitly denies mentioning everyone, text to speech messages, attaching files and embedding links. Again these are not marked as denied anywhere. They are ignored because the base action they depend on is unavailable.

What this does to your audit

It means reading the permission screen is not enough to know what somebody can do. Two people can have identical looking permission sets and behave completely differently because one of them lost the base action. Check the foundation permission first, then the specific one, in that order.

This is also why permission screenshots are weak evidence during an argument. A picture of a role's settings does not show the overwrites on the channel, the person's other roles, or whether a base action was removed somewhere upstream. If somebody sends you one to prove a person cannot do something, the picture is not able to prove that.

Threads and Timed Out Members

Threads inherit, with one exception

Threads inherit permissions from the channel they were created in, except for one. The send messages permission is not inherited. A person needs the separate permission for sending messages in threads, which is what allows people to participate in threads inside announcement channels where they cannot post normally.

Viewing is still required

The documentation adds a rule people trip over constantly. A person must have the view channel permission to see any thread in that channel, even if they were directly mentioned or added to the thread. Being invited into a conversation does not grant access to the room it is in.

That rule is more useful than it looks when you are designing a server rather than debugging one. It means a thread cannot be used to quietly widen access, because the thread never escapes the visibility of the channel holding it. Anybody planning to run private discussions inside a public structure has to solve it at the channel level, and no amount of thread configuration will do it for them.

Timing somebody out is a permission change

A timed out member temporarily loses all permissions except viewing channels and reading message history. Owners and anybody holding administrator are exempt from that, which is consistent with the bypass described earlier and worth knowing before you rely on a timeout to stop somebody senior.

Putting It Together

A short diagnostic order

When something is wrong, work in the order the platform does. Check whether the person has the base action at server level, then walk the eight steps looking for the first channel level entry that touches it, then check whether a second role is allowing what you thought you had denied. The answer is almost always at step three or step six.

Write the answer down when you find it. The same three or four misconfigurations recur in every server, and a short note saying which step caused which symptom turns the second occurrence into a two minute fix rather than another afternoon. That is the whole difference between a server that gets easier to run and one that gets harder.

Three rules that prevent most of it

Keep the default role restrictive, build access with allows rather than denies, and never hand out administrator as a convenience. Those three cover the majority of what people describe as Discord permissions being confusing, and none of them require remembering fifty two constants.

A fourth is worth adding for anybody running a server with other people in it. Write down why each role exists, in one line each, somewhere outside the server. Permissions decay because the reasoning behind them is never recorded, so a year later nobody can tell a deliberate exception from an accident, and the safe move always looks like granting more. Structuring rooms so that fewer exceptions are needed is the related idea in splitting a group that grew too big.

One last note for anybody arriving here from the messaging side rather than the community side. Permissions decide who can speak in a room you own, and they have nothing to say about reaching people who are not in it yet. Those are separate problems with separate ceilings, and the second one is measured in what breaks when you add members quickly.

Where this connects to running anything at scale

If a server is part of how you reach people rather than a hobby, permissions are the difference between delegating safely and not delegating at all. The messaging side of that problem, on a platform with a very different design, is in why mass messaging fails on Discord, and the account side of working at volume sits in a proper account tool and the direct message product. Anything genuinely bespoke is built to order.

Frequently Asked Questions

Why is my Discord permission not working

Usually because a second role allows what you denied. The documentation states that if one role denies a permission on a channel and another allows it, the person gets it, regardless of the role positions. Allows are applied after denies at every level of the calculation.

How does Discord calculate permissions

In eight ordered steps. Server level defaults, then server level role permissions, then channel level denies and allows for the default role, then channel level denies and allows for specific roles, then member specific denies and allows. Broad to narrow, and deny before allow at each level.

Does a higher role override a lower one

Only for four things. Granting roles, editing roles, sorting roles, and kicking, banning or renaming members. The documentation says that otherwise permissions do not obey the role hierarchy, so channel visibility is decided by the calculation rather than by rank.

Why is my channel not synced with its category

Because something in it was changed. A channel is synced only while its permissions match the category exactly, and any further change to the channel de-syncs it. After that, category changes stop reaching it entirely.

What does Administrator actually do

It grants all permissions and bypasses channel permission overwrites. The second half is the important one, since it means no channel restriction applies to that person. There is no way to hide a channel from an administrator.

How many permissions does Discord have

Fifty two, occupying bit positions from zero to fifty two with one position unused. Each is marked for the channel types it applies to, meaning text, voice or stage.

Why does the permission name not match my screen

Because the client uses different labels. The documentation says so directly and gives examples, noting that Manage Permissions refers to the role management permission and Timeout Members refers to the moderate members permission.

Why did my moderator action fail

Possibly two factor authentication. Eleven permissions, including kicking, banning and managing the server, require the owner account to use two factor authentication when the server has it enabled server wide.

Why can somebody not see a thread they were added to

Because viewing the parent channel is required. The documentation states that a person needs the view channel permission to see any thread in that channel even if they were directly mentioned or added to it.

What can a timed out member still do

View channels and read message history, and nothing else. Owners and anybody with the administrator permission are exempt, so a timeout does not restrict them at all.