BetterDiscordAddons: seven plugins for a client you do not control

Small patches to a client that ships weekly

BetterDiscordAddons is a series of plugins for BetterDiscord, and the repository description calls it a series of plugins and themes. The README, however, lists only plugins, seven of them, and no themes appear in the repository listing either. The `Plugins/` directory at the root is where they live, and each one has its own folder with a README link.

The setting is worth stating plainly. Discord's desktop client is not a platform for third party extensions, so these plugins run through BetterDiscord, a mod loader for the client, and they work by reaching into the client interface the user already has. The scope of what they can do is bounded by that: they can change what the interface shows and how it behaves, and they cannot change what the server enforces.

That boundary shows up in the list. PermissionsViewer shows the permissions a user has on a server or a channel, but it displays what the server has told the client, it does not grant anything. RoleMembers shows who is in each role, which is information the client already receives. DoNotTrack stops the client sending things like Sentry and Analytics data, which is a change to the client rather than to the account. Nothing in the list attempts to change what a server administrator can do.

That is a coherent scope for a personal client modification, and it is also the reason to read the list carefully before installing anything: the useful changes are the ones about the interface and about what your own machine sends, not the ones about permissions you do not have.

What each of the seven plugins does

The README is short, and each entry is a single sentence, which is enough to judge whether a plugin is relevant.

BetterFormattingRedux is a rewrite of Anxeal's BetterFormatting that includes new options and settings. That relationship matters: it is a fork or a reimplementation of an existing plugin rather than a new idea, and the author's claim is about the options and settings, so anyone who used the original will want to compare before switching.

BlurNSFW blurs images in any channel, DM or group, which is a privacy control for shared screens and for screenshots you take of your own client. The important detail is that it applies everywhere, including direct messages, rather than only in servers where the setting would be visible.

DoNotTrack stops Discord from tracking everything you do, with Sentry and Analytics named as the examples. This is the one plugin in the set with a clear security or privacy motivation, and it operates entirely on the client side, so it affects what your own machine sends rather than what an account setting would.

HideDisabledEmojis hides disabled emojis from the emoji picker, and HideIconBadge hides the badge that appears on the taskbar icon, which is the unread or notification indicator.

PermissionsViewer allows you to view all the permissions for users, servers and channels, and RoleMembers allows you to see the members of each role on a server.

The two inspection plugins are the reason most people would look at this repository, and they are also the ones most likely to stop working. A permissions panel and a role list are both built out of the client's own internal state and its rendering, so a Discord release that changes either will break them until the plugin is updated.

TypeScript and Svelte, bundled by esbuild through Bun

The build tooling tells you what kind of project this is. The `package.json` is a development manifest, marked private, with a single script:

  "scripts": {
    "build": "bun scripts/build.ts"
  },

A Bun script drives the build, and the toolchain underneath it is TypeScript with Svelte for the user interface and esbuild for bundling, with `esbuild-svelte` bridging the two. The dependency list is a development dependency list, which is what you would expect for a repository that produces plugin bundles rather than a published library: there is no runtime dependency section, and there are no dependencies at all in the dependencies key.

The interesting parts of that list are the type packages. Alongside `typescript` and `svelte-check` there are `@types/react`, `@types/react-reconciler` and `@types/node`, and the presence of React and React reconciler typings in a Svelte project is a signal about the environment rather than the UI framework. Discord's own client is built with React, so anything that inspects or patches the client's component tree has to speak React's data structures even when the plugin itself is written in Svelte.

`bun.lock` at the repository root is the lockfile for that toolchain, and the `eslint.config.js` and `tsconfig.json` files sit alongside it, so the repository has the usual static analysis setup.

The top level layout is `Plugins/`, `src/`, `scripts/`, `package.json`, `tsconfig.json`, `eslint.config.js`, `bun.lock`, a `LICENSE` file and a `CONTRIBUTING.md`. The separation of `src/` from `Plugins/` suggests shared source lives in one place and each plugin directory carries its own artefacts or documentation, with the build script assembling the output.

No releases, and a licence the platform cannot classify

Two pieces of metadata deserve attention before anyone installs anything from this repository.

The first is the absence of releases. There are no GitHub releases for the repository, and the README does not describe an update mechanism, a release channel or a version compatibility matrix. The repository is not archived, and the last push was on 2026-06-07, so the code is being worked on, but there is nothing versioned to pin. For a collection of plugins that patch a client which ships changes frequently, that means you cannot say which version of a plugin you are running or when it last matched the client.

The second is the licence. The repository is recorded with a custom licence that GitHub cannot classify, with the LICENSE file named as the place to look, while the `package.json` metadata records `MIT` in its licence field. Those two statements can agree, in which case there is no problem, and they can disagree, in which case the file is the one that governs. The distinction is worth resolving before you copy any of the code into a product, because the plugin sources are the part people reuse.

Neither of these is an argument against the project. They are arguments for reading the LICENSE file and for treating the plugins as things you install and update yourself, rather than as dependencies your build pins.

The rest of the project structure supports that reading. There is a `CONTRIBUTING.md` at the root, so there is a contribution path for people who want to fix a plugin that Discord's last update broke, and a `.github/` directory for the workflow configuration.

Building your own plugin instead of adopting the collection

The realistic alternative to installing this collection is to write the plugin yourself against BetterDiscord, and the repository makes that more accessible than it might sound, because the toolchain is right there: a Bun build script, esbuild, TypeScript and Svelte, with a `src/` directory and a `scripts/` directory to work in.

The difference in approach is who carries the maintenance. A plugin you write is tied to your own client's version and your own use of it, and when Discord changes the interface you fix it in your own repository on your own schedule. Nothing about the plugin collection's release process, or its absence of one, affects you. The cost is that you spend the time that the author of each plugin already spent, seven times if you want the whole set and once if you want one of them.

A plugin you adopt gives you someone else's work on the problem and inherits their schedule. For the inspection plugins, the permissions viewer and the role member list, that is a real advantage, because those two are the most likely to need adjusting after a Discord release and the least interesting to write from scratch.

The privacy and cosmetic plugins fall the other way. BlurNSFW and HideIconBadge are small enough that reimplementing them is quick, and the tracking block depends on what the client currently sends, which changes with the client. A user who wants those three behaviours and nothing else has a reasonable case for writing them rather than installing a collection.

One more option is to take a single plugin folder and treat it as a starting point, which is what the `src/` and `scripts/` layout is set up to support, and to ignore the rest of the collection entirely.

Editorial conclusion

BetterDiscordAddons suits a Discord user who wants small, specific changes to the desktop client, such as seeing who holds a role or blocking the client's telemetry, and who is comfortable installing a third party mod loader. It does not suit a team that needs a supported, versioned dependency, because the repository publishes no releases and a plugin that patches the client UI will need work whenever Discord changes it. Before installing, read the LICENSE file in the repository rather than trusting the MIT field in package.json, and check that the plugin you want still matches the current Discord client.

Frequently asked questions

Official sources

1. Issues
2. README
3. zerebos/BetterDiscordAddons on GitHub