Hosts File Editor: the Windows hosts file as a table, with a scriptable command line

The hosts file as a table, not a text file

Hosts File Editor is a fast, friendly editor for the Windows `hosts` file, and the README is blunt about why that matters. The Windows `hosts` file at `%WinDir%\System32\drivers\etc\hosts` maps hostnames to IP addresses before DNS is consulted, and it is handy for pointing a domain at a local dev server, blocking sites, testing deployments, or switching between environments.

Editing that by hand in Notepad is tedious and error-prone, and the reasons are structural rather than aesthetic. The file is a flat list of lines, and you cannot tell which of two hundred entries are active, which are commented out, which belong to a project you abandoned in March, or which two of them conflict. A table fixes that, and the feature list is the list of things a table makes possible: cut, copy, paste, duplicate, enable, disable and move one or more entries at a time, filter and sort when there are a large number of host entries, archive and restore various hosts file configurations when switching between environments, and merge another hosts file into the current one while skipping duplicates.

There are two features that go further than a table. The first is a quick enable and disable of the entire hosts file, which in practice is a switch between using it and ignoring it, and the second is the archive, which stores named configurations and restores them, so the difference between environments becomes a selection rather than a diff.

The remaining conveniences are the ones that make a small utility pleasant to live with. There is automatic pinging of endpoints to check availability with a status bar progress indicator, so a stale entry is visible instead of mysterious. There is a taskbar Jump List, so you can switch presets from the tray without opening the window. There is a global shortcut key, `Ctrl+Shift+H` by default, to hide and restore the classic edition from the tray. And the modern variant supports light and dark themes.

The intended user is a developer or a systems administrator on Windows who moves a machine between environments, and the primary language is C#.

Elevation on demand rather than an admin session

The design decision that makes the app usable on a locked down machine is how it handles privileges. It runs as a standard user and asks for elevation on demand, with a single UAC prompt, only when you actually save changes to the hosts file, so day-to-day viewing, archiving, and backups need no admin rights.

That is the difference between this and the usual solution. The usual solution is to run a text editor as administrator all the time, which means every accidental keystroke happens with write access to a file that redirects name resolution for the whole machine. Here, the moment of raised privilege is scoped to the write.

The command line follows the same rule, and the README is precise about it. Commands that change the hosts file need administrator rights, exactly like saving in the GUI: run from a console running as administrator for silent operation, or accept the single UAC prompt per command. A declined prompt cancels cleanly with exit code `1`. And `list` and `help` never need elevation.

The repository layout shows how the elevation is implemented as a separate component. There is a `HostsFileEditor.Elevate/` project alongside the core, the CLI, the WinForms edition, the WinUI edition and their test projects, which is a clean way to keep the privilege escalation out of the core logic.

For a security-minded evaluation, the points to check are that the elevation is a separate process rather than a running privileged handle, that the prompt appears per write rather than being cached, and that the read-only paths genuinely avoid it. The README states all three, and the presence of a dedicated elevation project and of the `HostsFileEditor.Cli/` project is consistent with that separation.

The licence is GPL v3, with the file at `License.md`.

Two executables that run the same commands

There are two ways to invoke the tool from a script, and the difference between them is a real operational detail rather than a naming quirk.

`hfe.exe` is a small console launcher that ships next to the app, and the README says to use this in scripts. It is a console app, so `cmd` and PowerShell wait for it to finish before running the next line, and its output pipes and redirects naturally. Store installs also register `hfe` on `PATH` as an app-execution alias, so `hfe -s MyHosts1` works from any console.

`HostsFileEditor.exe` is the app itself, and it also accepts the same commands and runs them headless with no window. Because it is a windowed app, `cmd` does not wait for it, so the README tells you to wrap it as `start /wait "" HostsFileEditor.exe -s MyHosts1` for sequential steps, or just to use `hfe.exe`.

Run with no command and the app opens normally, which is the behaviour the graphical user expects.

The alias registration has a wrinkle that the README spends a paragraph on, and it is worth understanding before you script against it. If both editions are installed, the classic and modern Store apps each register the same `hfe` alias, and Windows treats the duplicate as a conflict, so which edition owns `hfe` is not guaranteed. You pick one under Settings, then Apps, then Apps and features, then App execution aliases, with the path spelled out for Windows 11 under Advanced app settings and App execution aliases.

There is a second consequence of the same design. Each Store package keeps its own isolated app data, so `hfe list` reflects whichever edition the alias points at, which may differ from the other edition's window. The recommendation that follows is practical: if you script with `hfe`, install just the edition you script against, or call that edition's `hfe.exe` by full path. And portable zip builds are unpackaged, so they do not register the alias at all, which is a Store-install-only concern, and only the classic edition ships a portable build.

The command line, the presets and the exit codes

Both editions include a headless command line, version 1.5.0 for the classic edition and 1.2.0 for the modern one, and the intent is stated plainly: so scripts can switch presets and toggle the hosts file. The example in the README is the case that matters, applying a preset before launching a program and restoring it afterwards:

hfe -s MyHosts1
program.exe
hfe -s DefaultHosts

The command set is small and complete.

apply <preset>   # switch the hosts file to a saved preset (archive), alias -s, switch
enable            # enable the hosts file
disable           # disable the hosts file (renames it aside)
import <file>    # replace the hosts file with <file>, then save
merge <file>     # merge <file> into the hosts file, skipping duplicates, then save
list              # list available presets
help              # show usage, also --help or -h

Presets are the archives you save in the application, which is the Archive feature, and `apply` matches the archive name case-insensitively, with or without its file extension. The `disable` command is worth understanding: it renames the file aside rather than deleting it, so the effect is reversible.

The exit codes are documented, which is what makes the tool scriptable rather than merely callable. Exit code `0` is success, `1` is a runtime error such as a preset or file not found or a declined permission, and `2` is a usage error for an unknown or malformed command. Errors print a one-line message to stderr.

That is a complete and disciplined CLI contract, and it is the part of the project most likely to be used in production scripting, for example in a test harness that has to point a machine at a fixture environment before each run and put it back afterwards.

Where the command line and the window disagree

There is one behaviour in this tool that will bite a script author, and the README documents it in a way that is worth reading twice.

The CLI runs independently of an open GUI window. If the editor is open with unsaved changes, a CLI change to the hosts file is not reflected there until you refresh with F5, and saving stale GUI edits afterwards overwrites the CLI change. Last writer wins.

That is a straightforward consequence of two independent writers to one file with no locking, and the application does not attempt to prevent it. The practical consequence is that a script that switches presets while someone has the editor open with unsaved changes can lose the editor's changes, and a script that switches presets and then has the editor save can undo the script's change. Neither is a bug in the ordinary sense, and both are avoidable by not running the CLI against a machine where the GUI is open with pending edits, which is easy to arrange in a build agent and easy to forget on a developer machine.

The usage notes contain two more behaviours of the same kind, and they are about the graphical interface rather than the CLI. The classic edition closes to the tray by default, and to exit completely you must select Exit from the File menu or the tray context menu, which is a behaviour people trip over the first time. Only one instance of the application is allowed at a time, and trying to open it again activates the previously running instance.

And there is a quirk worth knowing about the table itself. When selecting rows to move, delete, copy or cut, you need to select the entire row using the row header cell, because if no entire rows are selected those operations apply individually to the selected cells instead. The same section notes that using the filter and sort while editing is quirky, since the filter and sort are applied once a cell is edited, so your cell may change position or disappear depending on the current sort and filter. Both are consequences of the table being a live view over the file rather than a form, and both are documented rather than hidden.

Two editions over a shared core, and how to get it

The download section is where the packaging decisions become concrete. The application runs on Windows 10 and 11, x64 or ARM64, and two editions are available, the modern WinUI edition and the classic WinForms edition, and they share the same core and the same features.

The Microsoft Store is the recommended route, and it is the one that removes work rather than adding it. The Store installs and updates automatically with no separate download, and the two listings are Hosts File Editor (modern), the new WinUI edition, and Hosts File Editor (classic), the classic WinForms edition.

The portable build is version 1.5.2, and the README describes the classic edition rebuilt on .NET 10 as fully self-contained, with no runtime to install, running as a standard user and asking for elevation on demand with a single UAC prompt only when you save changes to the hosts file.

The repository shows the engineering behind both. There is a `HostsFileEditor.slnx` solution, separate projects for the core, the CLI, the elevation helper, the WinForms edition, the WinUI edition and the test projects, plus `Directory.Build.props` and `Directory.Build.targets` for shared build settings, `global.json` pinning the SDK, `coverage.runsettings`, `build-all.ps1` and `publish-store.ps1` for the two build paths, and a `signing/` directory alongside `HostsFileEditorTestCert.pfx` for the Store signing. There is also a `privacy.md` and a `CLAUDE.md`.

The last release picture is a single day of work. v1.5.0, v1.5.1 and v1.5.2 were all published on 2026-07-14, and the last push to `master` was on the same date, so this was a release day rather than a steady cadence. The repository is not archived.

Where Hosts File Editor is the wrong tool

There are three cases where this application is more than you need, and the first is the most common.

The first is a hosts file you edit once. If your workflow is adding one line to block a site, or pointing one domain at a local server for an afternoon, Notepad is faster, and it needs no installation, no update cycle and no second application to learn.

The second is an environment where DNS is not the mechanism in play. Corporate networks increasingly resolve internal names through their own DNS, and some managed endpoints use a filtering resolver that ignores the hosts file entirely, in which case a carefully curated hosts file has no effect at all. The application will happily show you a green status bar for entries that are not being consulted.

The third is a machine you do not own, or should not modify. The hosts file changes name resolution for every application on the machine, including the security software on it, and the tool makes that change convenient, which is the opposite of what a policy that forbids local DNS overrides wants.

The alternative approach, and the one to weigh against, is a proxy or a development domain resolver, and the difference in approach is where resolution happens. A hosts file redirects individual names inside the operating system, which is precise, needs no network infrastructure, and breaks the moment a name is not in the file. A local resolver or a proxy intercepts the query, which handles wildcard patterns and dynamic environments, at the cost of a service that has to run, be configured and stay running.

For the case this tool is built for, which is one machine moving between a fixed set of known configurations, the hosts file is still the right mechanism, and the tool's contribution is the archive and the scripting. The hosted case, where several developers and a CI runner need the same mapping at once, is the case where a shared resolver beats editing a local file.

Editorial conclusion

Adopt Hosts File Editor if you switch between hosts file configurations often, because the archive of presets, the whole file toggle and the headless `hfe` command line turn a manual file edit into a scripted step, and the app only asks for elevation when it actually writes. Do not adopt it if you edit the hosts file once a year, since Notepad is enough, and note that the two Store editions register the same command alias. Verify three things first: that the hosts file path it targets matches your machine, since the README documents it as `%WinDir%\System32\drivers\etc\hosts`, that the port the CLI actually uses matches what your script expects, because the app and the console launcher are separate executables, and that your scripts refresh any open editor window, since a CLI change is not pushed into a running GUI and a later GUI save overwrites it.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. scottlerch/HostsFileEditor on GitHub