How to Get a Discord Bot Token (and Why You Can Only See It Once)

To get a Discord bot token, open the Discord Developer Portal, select your application, go to the Bot page, and click Reset Token under Token. Copy the value immediately: Discord shows it once, and the only way to see a token again is to generate a new one. There is no "reveal" button for an existing token, so if you have lost yours, resetting is the answer, not recovery.

Last verified: November 2026 against Discord's Developer documentation and the Developer Portal.

Discord's own getting started guide puts it plainly: "You won't be able to view your token again unless you regenerate it, so make sure to keep it somewhere safe (like in a password manager)." That single sentence explains most of the "where is my Discord bot token" searches. The token you copied last month is not stored anywhere you can read back; Discord's developer help center even has an article titled "Why can't I copy my bot's token?" for exactly this situation.

1. Sign in at discord.com/developers/applications with the Discord account that should own the bot. Ownership matters: whoever owns the application controls its token.
2. Click New Application, give it a name, agree to the terms shown, and create it.
3. In the left sidebar, open Bot. Newly created applications have a bot user enabled by default, so there is no separate "Add Bot" step on current portals.
4. Under Token, click Reset Token and confirm. If your account uses two-factor authentication, expect to be asked for a code.
5. Copy the token that appears and paste it straight into your secrets store or .env file. Do not paste it into chat, a ticket or a screenshot.
6. While you are on the Bot page, check the Privileged Gateway Intents toggles. A token that works but a bot that sees empty messages is an intents problem, not a token problem.

Three other values on the same application are often confused with the token. None of them can log a bot in:

If you paste the client secret or public key where the bot token belongs, the Gateway closes the connection with close code 4004 Authentication failed, and REST calls return HTTP 401 (Unauthorized).

The token is a bearer secret. Every HTTP request your bot makes sends it in a header with the literal prefix Bot, as shown in Discord's API reference:

Authorization: Bot YOUR_BOT_TOKEN

Libraries add that prefix for you, so pass the bare token. A quick way to confirm the token is valid without starting your whole bot is to ask the API who you are:

curl -s -H "Authorization: Bot $DISCORD_TOKEN" https://discord.com/api/v10/users/@me

A valid token returns your bot user's JSON (with "bot": true). An invalid one returns 401 with {"message": "401: Unauthorized", "code": 0}.

discord.js

import { Client, GatewayIntentBits } from "discord.js";

const client = new Client({ intents: [GatewayIntentBits.Guilds] });
client.once("ready", () => console.log(`Logged in as ${client.user.tag}`));
client.login(process.env.DISCORD_TOKEN);

discord.py

import os, discord

intents = discord.Intents.default()
client = discord.Client(intents=intents)
client.run(os.environ["DISCORD_TOKEN"])

Reading from os.environ[...] rather than os.getenv(...) is deliberate: a missing variable raises immediately with a clear error instead of passing None to the library and producing a confusing authentication failure.

Discord's docs warn never to share your token or check it into version control. In practice that means the token exists in exactly two kinds of places: a secrets store and the environment of the running process.

Local development: .env plus .gitignore

# .env  (never committed)
DISCORD_TOKEN=paste-the-token-here

# .gitignore
.env

Add .env to .gitignore before the first commit. Commit a .env.example with the variable names and empty values so collaborators know what to set. Load the file with dotenv (Node), python-dotenv, or Node's built-in --env-file=.env flag on recent Node versions.

Production

• Hosting platforms: use the platform's environment-variable or secrets panel rather than shipping a .env file in the image.
• CI/CD: GitHub Actions secrets, GitLab CI variables marked masked and protected.
• Containers: pass the token at runtime (docker run -e DISCORD_TOKEN, Kubernetes Secrets, Docker secrets), never with ENV or ARG in the Dockerfile - build args and layers are readable by anyone who can pull the image.
• Logs: never log the client options object or the raw request headers; both contain the token.

One small habit pays for itself: give the variable the same name everywhere (DISCORD_TOKEN), so a reset means changing one secret per environment rather than hunting through config files.

Anyone who has your token is your bot. They can read everything it can read, post as it, and use every permission it was granted in every server it is in - including Administrator if someone was generous with the invite. Treat a leaked token as a live incident:

1. Reset the token on the Bot page right now. The new value replaces the old one; anything still holding the old token stops authenticating. This is the only step that actually stops an attacker.
2. Update your deployment with the new token and restart. Your own bot is now offline until you do.
3. Check what happened. Review the audit log in the servers your bot is in for messages, role changes, bans or webhook creations you did not make.
4. Remove the token from where it leaked, then clean up history. Deleting a commit or rewriting Git history does not un-leak a secret; it only prevents the next person from finding it. The reset in step 1 is what matters.
5. Reduce blast radius for next time: request only the permissions the bot needs (see the Discord permissions calculator) and avoid Administrator.

What GitHub does with leaked Discord tokens

GitHub's secret scanning recognizes Discord bot tokens. In GitHub's list of supported secret scanning patterns, the Discord Bot Token (discord_bot_token) is a partner pattern - meaning tokens found in public repositories are reported directly to Discord - and push protection can block a commit that contains one. Do not count on that as your safety net: forums, paste sites, Docker images and client-side bundles are not GitHub, and what Discord does with a partner report is Discord's process, not something you control. If you suspect exposure, reset the token yourself.

Crash loops after a reset

A bot process that keeps restarting with an old token sends a stream of 401s. Discord's rate limit documentation temporarily restricts IP addresses that make too many invalid requests - currently 10,000 per 10 minutes, counting 401, 403 and 429 responses. Make your process exit and stay down on authentication failure instead of retrying forever, or a stale token on one server can get your whole host temporarily blocked.

A bot owned by one person's account is a single point of failure: if that person leaves or loses access, nobody can reset the token. Discord's Developer Teams fix that. Team membership requires two-factor authentication on each member's account, and an existing app moves over with Transfer App to Team at the bottom of its General Information page.

Give engineers who deploy the bot the Developer role and keep Admin for the people who manage access. When someone leaves the team, reset the token as part of offboarding; they may still have a copy.

Use two applications, not one token in two places

Create a second application for development (for example "MyBot Dev") with its own token, and install it only in a private test server. You get a token you can paste into a laptop .env without risking production, slash-command experiments that never appear in real servers, and the freedom to reset the dev token whenever it ends up somewhere it should not. Production keeps its token in the secrets manager and nowhere else.

Token-related errors at a glance

Some tutorials show how to pull the token from your own Discord client's browser storage and run "a bot" with it. That is a user token, and automating a normal user account is a "self-bot". Discord's OAuth2 documentation states that developers must abide by the Developer Terms of Service, "which includes refraining from automating standard user accounts (generally called 'self-bots') outside of the OAuth2/bot API." Breaking the Developer Terms puts the account itself at risk.

A user token is also far more dangerous to leak than a bot token: it is your account, with your DMs, friends and every server you have joined. If you have ever pasted your user token into a tool or script, secure the account immediately: change your password and turn on two-factor authentication.

The legitimate options are a real bot application (this guide), a channel webhook if you only need to post messages into one channel, or OAuth2 with user consent when you need to act on behalf of users within the scopes Discord allows.

A valid token on its own does not put your bot anywhere. The bot still needs to be installed to a server, which is an OAuth2 authorization done by someone with Manage Server in that server. The checklist from token to a responding bot:

1. Token stored as DISCORD_TOKEN and confirmed with the /users/@me curl above.
2. Install link configured on the Installation page (scopes bot and applications.commands, plus the permissions your bot needs), then opened by a server admin.
3. Intents requested in code match the toggles on the Bot page. Requesting a privileged intent that is not enabled closes the connection with close code 4014.
4. Channel permissions let the bot see and post where you are testing; otherwise you get 50013 Missing Permissions or 50001 Missing Access.

If the bot logs in and then stays silent, our Discord bot not responding guide walks through the remaining causes in order, and the Discord error code directory explains each code you might hit. For long-term community setups, see Discord bot community management.

If what you actually need is a support or lead-capture bot on Discord rather than a codebase to maintain, Conferbot's Discord integration connects a bot you build visually, and you paste the token into it once instead of hosting a process yourself.