dnsChanger desktop: a cross-platform DNS switcher built on Electron

One DNS switcher for three desktops

dnsChanger is an open source DNS Changer for Windows, Mac and Linux. The stated goal is to gather the best DNS servers in a secure application, and the project's own summary of that goal is worth repeating, because the word best is doing a lot of work and the word secure is doing the rest.

The functional idea is simple. Changing the resolver on a modern operating system is a settings panel, and a settings panel is per operating system, per network adapter, and often per user profile. A tool that presents one list of servers and applies it to the system removes that friction, and the release page lists Windows, macOS and Linux all as stable.

The application is a desktop app, not a command line tool, although the repository topics list cli among the tags, so the project is aware of the scripted use case. The site is dnschanger.github.io, the licence is MIT, and the downloads come from the GitHub releases section.

The primary language is TypeScript, and the repository is a monorepo-shaped single package with src/ for the application code, public/ and assets/ for static content, an index.html at the root for the renderer entry, and a store/ directory whose purpose is not described in the documentation. There is also a .gitmodules file, so the build depends on at least one Git submodule, which is worth knowing before you try to build from a shallow clone.

The features the project documents are deliberately few, which is honest for a utility of this kind. There is an app, a list of servers, an antivirus result link, a changelog, a contribution guide, and a privacy note about analytics.

Electron, Vite, React and Tailwind

The stack is a fairly standard modern desktop setup, and the package manifest shows it clearly.

The main process entry is ./dist-electron/main/index.js, which is what Electron loads. The renderer is a Vite project with index.html at the repository root, and the React plugin comes from @vitejs/plugin-react. Styling is Tailwind, with @tailwindcss/vite and @tailwindcss/postcss both present at version 4.3.3.

The TypeScript setup is split, which is the norm for Electron projects where the main process and the renderer want different lib settings. There are three tsconfig files: tsconfig.json at the root, tsconfig.node.json and tsconfig.web.json. The type checking is run through the build:code script, which is tsc --noEmit combined with vite build, so a type error fails the build rather than shipping.

There is a debug block in the manifest that points the debug build at a Vite dev server on 127.0.0.1:7777, which is how the developer workflow is wired: the renderer talks to a running dev server and the Electron main process loads it.

Two linters are configured, which is unusual and worth a note. There is an .eslintrc.js and a .prettierrc, and also a biome.json with @biomejs/biome at 2.5.4. The format script only calls prettier, writing across the TypeScript and TSX files under src/, so Biome is presumably used for something other than formatting, most likely linting. Either way, a contributor needs to know which tool to reach for.

The user interface also pulls in @heroicons/react and lodash, and the type definitions list @types/ping and @types/auto-launch, which hints that the app measures reachability to a server and can launch itself at login.

Build, publish and test targets

The scripts section of the package manifest is the practical documentation for anyone who wants to build or contribute, and it is worth reading as a whole.

The build is vite build followed by electron-builder, with the configuration in electron-builder.yml. The publish scripts are per platform and always publish: publish:win builds and runs electron-builder with the win target and the always publish flag, publish:linux does the same for linux, publish:mac for mac, and publish:auto lets electron-builder pick the host platform. The always flag is the one to know about, since it means a local build on a matching platform will try to publish rather than only produce an artefact.

Testing is split across three tools, which is more than most projects of this size manage. Jest is configured with jest.config.ts and the @jest/globals package, there is a build:code script that type checks, and end-to-end tests run with Playwright, with a pree2e step that builds the app in test mode first, vite build --mode=test, so the end-to-end suite runs against a test build rather than a development server.

Internationalisation is handled by typesafe-i18n, with the i18n script invoking the generator and a .typesafe-i18n.json configuration at the root. There is a removeLocales.js file at the root as well, which is presumably part of trimming unused translations from a release build, and the store/ directory sits alongside a .github/ directory that holds the banner image used in the README.

The changelog lives in changelog.md at the repository root and is the place to look before upgrading.

Analytics, the antivirus badge and the trust question

Two documents in this repository deserve careful reading, and both are about trust rather than features.

The privacy note states that the app has analytics that will track the number of users and servers only and nothing more. That is a narrow claim and it is stated in the project's own words, which is better than no statement at all. For a tool whose entire job is to redirect your network traffic to a third party DNS server, the question of what the tool itself sends is the first question, and the answer given is a count.

The antivirus badge is the second document. The README carries an antivirus PASS badge and links a VirusTotal result for a specific file hash, with a nocache parameter so the scan reflects the current file. Linking a hash rather than a general claim is the right way to do this, because a scanner verdict only applies to the exact binary that was scanned. The caveat is the obvious one: a VirusTotal result is a set of scanner verdicts, not a security review, and for an Electron application the interesting surface is the main process code and the native modules it loads, which no scanner evaluates.

The honest framing is that this is a desktop application that must change system DNS configuration, which is a privileged operation on every platform it supports. Any tool in that category deserves the same scrutiny, whether it is open source or not, and this one at least publishes its source, links a scanned artefact, and documents its analytics scope.

Maintenance state and where the project is headed

The release history shows a steady stream of patch releases through the summer of 2026: v2.3.12 on 2026-08-16, v2.3.13 on 2026-08-17 and v2.3.14 on 2026-08-25, with the version in the package manifest matching the newest tag. The last push was on 2026-10-19, and the repository is not archived.

Two things stand out about the cadence. The releases come in tight clusters, a day apart and then a week, which reads as a bug fix reaching users quickly rather than as a large feature cycle. And the gap between the newest tag and the last push is about eight weeks, which is normal and suggests the next patch is not far away.

The repository topics give a better picture of the project's shape than the README does. They include dns-changer, electro and electronjs, reactjs, nodejs, typescript, windows, macos, pc, cli, shecan and radar-game. Two of those, shecan and radar-game, point to features and dependencies the README does not describe, and a reader who wants to know what they are will have to read the code.

The project also has a Discord community linked from the README, a contribution guide in CONTRIBUTING.md, and a donation link. The author field in the package manifest names sajjadmrx, and there is a tether address and an alternative donation page listed.

The licence is MIT, and there is a LICENSE file at the root, so if you want to fork it for your own organisation the terms are simple.

Editorial conclusion

Adopt dnsChanger desktop if you switch DNS servers often, want one interface that works the same on Windows, macOS and Linux, and are comfortable granting an Electron app the system rights that changing a resolver requires. Do not adopt it if you need to be certain that nothing leaves your machine beyond a resolver change, because the project ships analytics that count users and servers, and do not treat the antivirus badge as a security review of a native component. Before you start, read the privacy note and changelog.md, check the VirusTotal result for the specific build you download, and confirm the DNS servers the app offers are ones you have a reason to use rather than ones it recommends by default.

Frequently asked questions

Official sources

1. DnsChanger/dnsChanger-desktop on GitHub
2. License: MIT
3. Project website
4. README
5. Releases