Discord bot permissions reference

Discord permissions are a 64-bit integer where each bit is one permission. The number in an invite URL is that integer, which is why invite links carry values like 8 or 268435456.

Understanding two things — how the integer composes, and how the effective set is computed — covers almost every permission question that reaches a support channel.

The bitfield

Each permission is a power of two. Combining them is addition, or more precisely a bitwise OR.

An invite link with permissions=8 is requesting Administrator. That is the single most useful thing to be able to read at a glance, because a bot asking for 8 is asking for everything.

Parse them as BigInt, never as Number

The API returns permission values as strings, and this is not a stylistic choice. 64-bit permission integers exceed JavaScript’s safe integer range, so parsing one with Number() silently loses precision on the high bits — which are exactly where the newer permissions live.

// Wrong — high bits are silently corrupted
const perms = Number(member.permissions);

// Correct
const perms = BigInt(member.permissions);
const canTimeout = (perms & (1n << 40n)) !== 0n;

The failure mode is nasty because it is partial: everything below bit 53 behaves correctly, so the bug passes every test written against the common permissions and appears only when checking a recent one. Use BigInt and 1n << Nn shifts throughout, or use a library’s own permission type.

Implicit gates

Two permissions behave as prerequisites rather than as capabilities, and both produce failures that look unrelated to permissions.

View Channel gates everything else on that channel. A bot with Send Messages, Manage Messages and Embed Links but not View Channel can do none of them there — the API reports Missing Access (50001) rather than Missing Permissions (50013), which is the fastest way to tell the two apart.

Send Messages does not imply the rest. Attach Files, Embed Links, Add Reactions and Use External Emojis are all separate bits. A bot posting plain text successfully and failing on embeds is missing Embed Links, not misconfigured.

The permissions worth refusing

Administrator (8) grants every permission, present and future, and is not restrained by channel overrides. A bot with Administrator that is compromised — or simply badly written — can delete every channel in the server. Very few bots genuinely need it; most that request it are doing so because computing the correct bitfield was more effort than asking for everything.

Manage Webhooks (536870912) is quieter and nearly as dangerous. A webhook can post to any channel with any username and avatar. A bot with this permission can create one, hand the URL to anything, and impersonate any member in any channel. Grant it only to bots whose whole purpose is webhook management.

Manage Guild (32) deserves a mention alongside them. It reaches server settings and integrations, which is a wider surface than most bots requesting it use — and it is the permission that lets something change the server’s fundamental configuration rather than operate within it.

Mention Everyone (131072) is worth a moment’s thought on any bot that formats external content. It is the difference between a scraped title containing @everyone being inert text and being a server-wide ping.

Manage Roles is bounded by position

Manage Roles does not mean “manage all roles.” It means “manage roles positioned below my highest role.”

This is the cause of most “the bot has the permission but it still fails” reports. The permission is present; the reach is not. Move the bot’s role above the roles it needs to act on and the problem disappears without touching any checkbox.

The same bound applies to Kick, Ban and Moderate Members: the target’s highest role must sit below the actor’s.

How the effective set is computed

For a member in a channel, in order:

1. Start with @everyone’s server-level permissions.
2. OR in the permissions of every role the member holds. Roles combine; they do not override.
3. If the result contains Administrator, stop — they have everything.
4. Apply the @everyone channel override: denies, then allows.
5. Apply role channel overrides: all denies combined, then all allows combined.
6. Apply the member-specific channel override: deny, then allow. This wins over everything above.

Two consequences worth internalising. Removing a permission from one role achieves nothing if another role the member holds still grants it. And a member-specific allow on a channel beats a role-level deny, which is how you make an exception for one person without creating a role.

Bot permissions have a second gate

A bot’s effective permissions are the intersection of what its role grants and what the channel allows — the same as a member. But there is an additional constraint people forget: the bot cannot grant itself, or anyone, a permission it does not itself hold.

A bot with Manage Roles but not Ban Members cannot create a role with Ban Members. This is deliberate and prevents privilege escalation through role creation.

Reading an invite link

An invite URL looks like:

https://discord.com/api/oauth2/authorize?client_id=...&permissions=268520512&scope=bot%20applications.commands

Two things to check before clicking. permissions — if it is 8, the bot wants Administrator. scope — bot is the bot itself; applications.commands allows slash commands. Anything beyond those two, particularly OAuth scopes touching your account rather than the server, deserves a second look.

You can edit the permissions value in the URL before authorising. The bot may not work correctly with a reduced set, but it is your server.

Re-inviting replaces the managed role’s permissions with whatever the new link requests. That is useful — it is the clean way to correct a permission set — and it is also how a bot silently loses a permission somebody added by hand months earlier.

A least-privilege starting point by bot type

Grant the narrowest set that works, then add on failure rather than starting broad.

None of these needs Administrator, and none needs Manage Webhooks unless it is explicitly delivering through webhooks you configured.

Auditing what you have granted

Server Settings → Integrations lists every bot and the permissions it holds. Worth reading through once a quarter, particularly for bots added years ago when the server was smaller and the standard was looser.

The two questions: does anything hold Administrator that does not need it, and does anything hold Manage Webhooks that is not a webhook tool. Those two account for nearly all of the real risk.

Bots that expose granular per-section permission control in a dashboard make this easier to keep honest, since you can delegate one area to a staff member without handing over the whole configuration. Vetox’s version, Access Control, covers 40 grantable dashboard sections across 11 groups — moderation, AI, tickets, applications, one entry per notification platform, and administration among them — so a moderator can be handed exactly Auto-Mod, Protection and the logs and nothing beyond it. It sits behind the Max tier, is enforced server-side on every request rather than only in what the sidebar shows, and can itself be restricted to the server owner alone so a delegated administrator cannot grant themselves a wider scope than the one they were given. The principle applies regardless of which bot you run: grant the narrowest set that works, and re-check it periodically.

Frequently asked questions

What does permissions=8 mean in an invite link? Administrator — every permission, present and future, unrestrained by channel overrides.

Why does my bot have the permission and still fail? Manage Roles, Kick, Ban and Moderate Members are all bounded by role position. The bot must sit above its target.

Why do permission values come back as strings? They are 64-bit and exceed JavaScript’s safe integer range. Parse them as BigInt.

What is the difference between error 50001 and 50013? 50001 is Missing Access — the bot cannot see the channel. 50013 is Missing Permissions — it can see the channel and may not act.

Can I reduce the permissions in an invite link? Yes, edit the permissions value before authorising. The bot may not work fully, but the server is yours.