Discord.js V14 enables three intents by default: Guilds, GuildMembers, and MessageContent
When you create a new Discord bot using Discord.js V14, the library automatically turns on three intents — permissions that let your bot receive specific types of events from Discord's servers. These three are Guilds (information about servers your bot joins), GuildMembers (data about who is in those servers), and MessageContent (the actual text of messages people send). Every other intent starts turned off, which means your bot will not receive those events unless you explicitly enable them in your code.
This default setup exists because Discord requires bots to request only the data they actually need. If your bot does not need to read message content, it should not have permission to do so. The three defaults cover the bare minimum: knowing what servers the bot is in, knowing who the members are, and being able to read messages. If your bot needs to do something else — like track when users go online, monitor voice channel activity, or watch for emoji reactions — you have to add those intents yourself.
Key Takeaways
- Discord.js V14 turns on Guilds, GuildMembers, and MessageContent by default; all other intents are off.
- The MessageContent intent requires you to enable it both in your code and in the Discord Developer Portal under your bot's settings.
- If your bot tries to use an event it does not have an intent for, the event will not fire and your code will not run.
- Enabling intents you do not use wastes resources and may cause Discord to rate-limit or restrict your bot if it requests too much data.
- You enable additional intents by passing them to the GatewayIntentBits object when you create your bot client.
The three intents that are on by default and what they do
Guilds is the first default intent. It tells Discord to send your bot events whenever a server (called a guild in Discord's code) is created, updated, or deleted, and whenever your bot joins or leaves a server. Without this intent, your bot would not know what servers it belongs to or when the server's name or settings change. This is why it is always on — a bot needs to know which servers it is supposed to be in.
GuildMembers is the second default intent. It sends events when members join or leave a server, when their nickname changes, or when their roles are added or removed. If you want your bot to greet new members, track who is in the server, or check someone's roles before letting them use a command, you need this intent. Discord.js V14 includes it by default because most bots need basic information about who is in the server.
MessageContent is the third default intent, and it is the one that often surprises developers. This intent lets your bot read the actual text inside messages. Without it, your bot can see that a message was sent and who sent it, but the message content itself will be empty. If your bot responds to commands like !help or reads the words in a message to decide what to do, it needs this intent. However, Discord treats MessageContent differently — you must enable it in the Developer Portal as well as in your code, and it only works for messages your bot can see (not all messages in a server).
How to enable additional intents in your Discord.js V14 code
To turn on an intent beyond the three defaults, you add it when you create your bot client. In Discord.js V14, you use the GatewayIntentBits object. Here is the basic pattern: when you initialize your client, you pass an intents property that lists which intents you want.
If you want to add the Presence intent (so your bot knows when users go online or offline), you would write something like this: you import GatewayIntentBits from discord.js, then pass intents: [GatewayIntentBits.Guilds, GatewayIntentBits.GuildMembers, GatewayIntentBits.MessageContent, GatewayIntentBits.GuildPresences] to your client constructor. The order does not matter, and you can list as many as you need. If you want all intents at once (which is usually not a good idea for production bots), you can use GatewayIntentBits.All, but Discord discourages this because it wastes bandwidth and can get your bot rate-limited.
A common pattern is to enable only the intents your bot actually uses. If your bot responds to slash commands and reacts to messages, you might enable Guilds, GuildMembers, MessageContent, and GuildMessageReactions. If your bot tracks voice channels, you would add GuildVoiceStates. The Discord.js documentation lists all available intents, and you can check which ones your code actually needs by looking at which events you are listening for.
Why MessageContent requires setup in two places
The MessageContent intent is special because Discord treats message content as sensitive data. Even though you enable it in your code, Discord will not actually send message content to your bot unless you also enable it in the Developer Portal. This is a safety measure: it prevents a bot from secretly reading messages just because someone installed a malicious version of the code.
To enable MessageContent in the Developer Portal, go to your process settings, find the Bot section, scroll down to Intents, and toggle on Message Content Intent. Once you do this, your bot will receive message content for messages it can see. If you forget to enable it in the Portal, your bot's code will run without errors, but the message content will still be empty — which is a confusing bug to track down. Always enable it in both places if your bot needs to read messages.
What happens when your bot tries to use an intent it does not have
If your bot listens for an event that requires an intent you have not enabled, the event straightforward will not fire. For example, if you write code to listen for the presenceUpdate event (which fires when a user's online status changes) but you have not enabled the Presence intent, your code will not run when that event happens. Discord will not send the event to your bot at all.
This can be hard to debug because your code looks correct — there are no error messages, the event listener is set up properly, but nothing happens. The solution is to check which intents your event listeners need and make sure they are enabled. The Discord.js documentation for each event type lists which intent is required. If you are using a command handler or event handler system, you might add a comment above each listener noting which intent it needs, so you do not forget to enable it later.
The difference between intents and permissions
Intents and permissions are not the same thing, and this confusion trips up many new bot developers. Intents control what data Discord sends to your bot — they are about what your bot can receive. Permissions control what your bot is allowed to do in a server — they are about what actions your bot can take. You can have the MessageContent intent enabled, which means Discord will send you message text, but if your bot does not have the Send Messages permission in a channel, it still cannot post a reply.
When you invite a bot to a server, the invite link specifies which permissions the bot is asking for. The server owner grants or denies those permissions. Intents, by contrast, are set up in your bot's code and in the Developer Portal — they are not something a server owner controls. A bot needs both the right intent and the right permission to do most things: it needs the MessageContent intent to read messages, and it needs the Send Messages permission to reply to them.
Best practices for choosing which intents to enable
Enable only the intents your bot actually uses. Every intent you enable uses bandwidth and can slow down your bot if Discord is sending a lot of events. If your bot only responds to slash commands and does not need to read regular messages, do not enable MessageContent. If it does not track user presence, do not enable Presence. This keeps your bot lean and reduces the chance that Discord will rate-limit it for requesting too much data.
Test your bot with only the intents it needs. Start with the three defaults and add others one at a time as you build features. This way you will know exactly which intents each feature requires, and you will not accidentally enable something you do not use. If you are building a bot for production — one that will be in many servers — being selective about intents is even more important, because large bots that request too much data can face restrictions from Discord.
Frequently Asked Questions
Do I have to enable MessageContent in the Developer Portal if I enable it in my code?
Yes. You must enable it in both places. If you only enable it in your code, Discord will not send message content to your bot, and your message content will be empty. If you only enable it in the Portal, your code will not have the intent and will not listen for message events properly. Both are required.
What happens if I enable all intents with GatewayIntentBits.All?
Your bot will receive all events Discord sends, but this wastes bandwidth and can cause Discord to rate-limit your bot if it is in many servers. Discord discourages this for production bots. Use it only for testing or small private bots where you need to debug what events are being sent.
Can I change which intents are enabled after my bot starts?
No. Intents are set when you create your client and connect to Discord. If you need to change them, you have to restart your bot. This is why it is good to plan which intents you need before you deploy your bot to production.
If my bot does not have an intent, will it get an error message?
No. Your code will not throw an error. The event listener straightforward will not fire because Discord never sends the event to your bot. This is why debugging intent issues can be tricky — there is no error to tell you what is wrong.
Do intents affect which servers my bot can join?
No. Intents do not control whether your bot can join a server. Permissions do. Any server owner can invite your bot regardless of which intents it has enabled. The intents only affect what data your bot receives once it is in the server.