WebCord: a Discord client built without the Discord API

What WebCord actually is, and who it is for

WebCord is a desktop client for Discord, made in Poland and built on Electron, that the README describes as "implemented directly without Discord API". That phrase is the whole design. Rather than reimplementing Discord's protocol, WebCord loads the discord.com web page inside an Electron window and then modifies what happens around it: permissions, user agent, stylesheets, and a set of internal pages for settings, documentation and about.

The README summarises the project as "a pack of security and privacy hardenings, Discord features reimplementations, Electron / Chromium / Discord bugs workarounds, stylesheets, internal pages and wrapped https://discord.com page". If you read that list carefully, only one item is a client. Everything else is scaffolding around somebody else's web application.

The audience follows from that. WebCord suits Linux users who want Discord in a window with a smaller memory and permission footprint than the official client, users on ARM hardware (the repository topics include aarch64, arm64, armhf and armv7l), and people who want to control what the page is allowed to load. It does not suit anyone who wants a client that owns its own transport, because WebCord deliberately does not have one.

The mechanism: a wrapped page, not a protocol implementation

The architecture is visible in the repository layout. package.json sets "main": "app/code/common/main.js", so the compiled TypeScript entry point lives under app/code/common, and the build script is plain tsc. There is no server component and no gateway connection: the Electron main process starts, and a renderer loads the Discord web page.

Everything WebCord claims as a feature sits in the gap between those two. The README says it blocks known tracing and fingerprinting methods, sets its own user agent to the one used by Chromium browsers, and spoofs web API modifications "in order to prevent distinguishing it from the real Chrome/Chromium browsers". That last part is the interesting engineering decision: the goal is not to be detected as a different client, it is to be indistinguishable from a browser. Content Security Policy settings let you block third-party websites, and the README mentions an option to block the typing indicator. Custom stylesheets are described as "on its way", so theming through CSS is not a shipped feature yet.

Electron version policy is another explicit choice. The README states that WebCord uses "the latest major release currently supported and available at the package time", in contrast to the official Discord client. That buys a newer Chromium engine and newer sandboxing, at the cost of tracking upstream Electron releases rather than pinning to a version Discord has validated.

Installing WebCord from a package or from source

The README does not publish install commands. It points to two documents instead: Repos.md, described as "Community maintained repositories providing WebCord", and Build.md for compiling from source. The FAQ has an entry titled "Which file I should download?", which is the honest starting point if you have found a release asset and do not know which one applies to you.

If your distribution is covered by a community repository, that is the path the project expects you to take. For Arch Linux specifically, the related search data shows people looking for a webcord arch package, and the repository list in Repos.md is where the project says to look rather than the README itself.

Building from source uses the npm scripts declared in package.json. The install step is the standard one, then the start script compiles TypeScript and launches Electron in a single command:

npm install
npm start

The start script is defined as "tsc && electron .", so a successful run compiles first and then opens the application window. If the TypeScript compiler reports errors, Electron never launches, which makes the type checker a hard gate rather than a suggestion. To compile without launching, use the build script:

npm run build

For distributables, package.json defines package and make scripts backed by electron-forge, with makers listed for deb, rpm, snap, flatpak, dmg, squirrel, wix, zip and AppImage. Running npm run make produces a platform-specific artifact through the corresponding maker. The lint and test scripts run oxlint, and the README notes that ESLint forbids practices such as the any type, so a contribution that uses it will not pass.

Where the wrapped-page approach fails

The most concrete limitation is stated by the project itself, at the top of the README: a major rewrite is being worked on, and "most efforts around WebCord will be kept at minimum". The same paragraph says there might be no time-intensive and major updates on top of the existing code, while maintenance updates and low-cost improvements continue. Anyone evaluating WebCord as a long-term dependency should read that as the project's own description of its pace, not as an outside assessment.

A second limitation follows from the architecture. Because WebCord does not implement the Discord API, every feature it offers is a modification of a page the project does not control. When Discord changes its web client, WebCord has to work around the change. The README lists "Electron / Chromium / Discord bugs workarounds" as a category of the codebase, which tells you how much of the project is reactive.

There is also a documented history of a security flaw in exactly this area. The README recounts that the screen share dialog was originally injected into the page, meaning Discord could technically access window thumbnails and simulate mouse click events to trigger screen sharing without user interaction. The README says this was fixed. The episode is worth knowing because it shows the class of risk that comes with injecting UI into a third-party page.

Finally, the README is explicit that Linux mobile support is "still not ideal". Electron is not designed for mobile devices, and the project says it tries its best to be responsive on small and touch screens while planning to focus on it later. If you are choosing WebCord for a phone or tablet, that is the wrong tool for now.

WebCord compared with a patched official client

The natural alternative is a client that modifies the official Discord desktop application rather than wrapping the website. The related search data includes webcord vs vesktop and vesktop vs webcord reddit, and the search questions include webcord vs vencord, so this is the comparison people actually make.

The difference in approach is structural. A patched official client starts from Discord's own Electron application and injects changes into it, which means it inherits Discord's update channel and its desktop-specific code paths. WebCord starts from the discord.com web page in a fresh Electron shell, which means it inherits the browser build of Discord and none of the desktop client's internals. That is why WebCord's feature list reads as hardening and workarounds rather than plugins: it has no native client to patch, only a page to wrap.

The practical consequence is that the two approaches fail differently. A patched client breaks when Discord changes the desktop app in ways the patch does not expect. WebCord breaks when Discord changes the web page in ways its injected scripts and stylesheets do not expect. Neither is more correct; they are exposed to different upstream surfaces. If your reason for leaving the official client is plugin availability, WebCord is not the answer, because custom stylesheets are still described as on their way and the project does not present itself as a plugin host.

Licence, maintenance and the cost of upgrading

WebCord is MIT licensed, and the README says it is "strongly advised" to read the application licence in addition to the documentation. MIT is permissive: you can reuse and redistribute the code, including in modified form, provided the licence text and copyright notice travel with it. That applies to WebCord's own source. It does not extend to Discord's web client, which WebCord loads from discord.com and does not ship, and it says nothing about Discord's terms of service. The FAQ has an entry asking whether the project violates those terms, and that entry, not the MIT text, is the document that matters for that question.

The upgrade cost has two parts. The first is that the app tracks Electron's latest supported major release at package time, as the README states, so a rebuild can pull in a newer Chromium than the one you last tested. The second is the rewrite: the README says a major rewrite is in progress and that effort on the current code is being kept at a minimum. If you build from source, you are building the code that is being replaced. The repository's most recent release listed is v4.14.0, and the last push to the repository was on 2026-09-23, so the current line is still receiving changes even while the rewrite is underway.

Editorial conclusion

Adopt WebCord if you want the Discord web app in a desktop window with tighter permission handling, a spoofed Chromium user agent and the option to block third-party origins through Content Security Policy, and you accept that the project is in a rewrite phase with maintenance-level attention. Do not adopt it if you need a client with its own protocol implementation, plugin ecosystem or a stable long-term roadmap; the README says most effort is being held at a minimum while a major rewrite is worked on, and the FAQ's own answer on ToS is the first thing to read before you install. Verify two things first: that a package for your platform exists in the community repositories listed in Repos.md, and that the FAQ entry on microphone permissions matches your desktop environment, because that is where most first-run problems land.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. SpacingBat3/WebCord on GitHub