# Discord bot permissions reference

> Discord bot permissions — what each one grants, which are dangerous, how the bitfield works, and why the permission you granted is not the one it has.

- Canonical: https://discordtools.blog/blog/discord-bot-permissions-reference
- Published: 2026-08-29
- Author: The Index desk
- Facts checked: 2026-08-30
- Sources:
  - Discord Developer Documentation — Permissions (https://docs.discord.com/developers/topics/permissions) — checked 2026-08-30
- Publication: The Index, an independent site not affiliated with Discord Inc.

---
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.

| Permission       | Bit value       | Notes                                         |
| ---------------- | --------------- | --------------------------------------------- |
| Create Invite    | `1`             | Often granted without thought                 |
| Kick Members     | `2`             | Bounded by position                           |
| Ban Members      | `4`             | Bounded by position                           |
| Administrator    | `8`             | Grants everything. Ignores channel overrides. |
| Manage Channels  | `16`            | Create, edit, delete channels                 |
| Manage Guild     | `32`            | Server settings, integrations                 |
| Add Reactions    | `64`            | Adding _new_ reactions only                   |
| View Audit Log   | `128`           | Read-only                                     |
| View Channel     | `1024`          | Gates everything else on that channel         |
| Send Messages    | `2048`          |                                               |
| Manage Messages  | `8192`          | Delete others' messages, pin                  |
| Attach Files     | `32768`         | Separate from Send Messages                   |
| Mention Everyone | `131072`        | `@everyone`, `@here` and all roles            |
| Manage Roles     | `268435456`     | Bounded by position — see below               |
| Manage Webhooks  | `536870912`     | Effectively "post as anyone, in any channel"  |
| Moderate Members | `1099511627776` | Timeout                                       |

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.

```js
// 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.

| Bot type      | Reasonable set                                                       |
| ------------- | -------------------------------------------------------------------- |
| Logging only  | View Channel, Send Messages, Embed Links, View Audit Log             |
| Welcomer      | View Channel, Send Messages, Embed Links, Attach Files, Manage Roles |
| Moderation    | Above + Manage Messages, Kick, Ban, Moderate Members                 |
| Tickets       | Above + Manage Channels                                              |
| Notifications | View Channel, Send Messages, Embed Links                             |

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](/blog/vetox-ai-capabilities), 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.