# WinUtil: a URL piped into PowerShell, running as Administrator > The recommended install fetches a script from the internet and executes it with system-wide rights, which makes the obvious question the right one. The repository answers it better than you might expect, because the entire script is there to read, the build is signed, and the presets live in a JSON file. **ChrisTitusTech/winutil** — Chris Titus Tech's Windows Utility - Install Programs, Tweaks, Fixes, and Updates. - Repository: https://github.com/ChrisTitusTech/winutil - Stars: 63,156 · Forks: 3,700 - Language: PowerShell - License: MIT - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/christitustech-winutil ## The install is a remote script executed with admin rights The quick start is two sentences and one line. WinUtil must be run as Administrator because it performs system-wide changes. Open PowerShell or Terminal as admin, then run the stable branch command: ```ps1 irm https://christitus.com/win | iex ``` A development branch exists at `https://christitus.com/windev`, and the README marks the stable one as recommended. Getting an admin shell is the only other setup step, either by right-clicking Start and choosing Windows PowerShell (Admin) or Terminal (Admin), or by pressing the Windows key, typing PowerShell or Terminal, and using Ctrl+Shift+Enter. The consequence is worth stating plainly. `irm` downloads and `iex` executes, in one pipeline, with no file on disk, no version pin and no checksum, running as Administrator. Whatever the server returns at the moment you run it is what executes with full system rights. That is the delivery model, not a flaw in the code, and it is the reason the next section matters. ## The whole script is in the repository, which is the real answer If the install is opaque, the source is not. The repository carries `windev.ps1` at the root, which is the script the development URL serves, along with `Compile.ps1` and `sign.bat`. The presence of a signing step is the standard mitigation for the piping problem: the artefact is compiled and signed, so a signed build can be checked before it runs rather than trusted because a URL resolved. The rest of the tree describes a real project rather than a single file. There is `config/`, which is where the presets live, `functions/`, `scripts/`, `tools/` and `docs/`, a `pester/` directory for the Pester test framework that is the standard way to test PowerShell, and a `lint/` directory. There is also an `xaml/` directory, which is the strongest hint about the shape of the tool, since XAML is how a Windows desktop interface is declared. The consequence is that you can answer the safety question without trusting anything. Clone the repository, read `windev.ps1`, and compare it against what the URL served. Most people will not do that, which is the real state of affairs, but the option exists and the project has paid for it in build tooling. ## Presets are named by adjective and defined in a JSON file Automation is supported, and this is how the project exposes it: ```powershell & ([ScriptBlock]::Create((irm https://christitus.com/win))) -Preset Standard ``` Three presets are offered. `Standard` is described as balanced defaults for most users, `Minimal` as minimal changes to suit every user, and `Advanced` as deep tweaks for power users. Those three descriptions are the entire documentation of what the presets do, and they are adjectives rather than actions. Nothing in the table tells you which services are disabled, which scheduled tasks are removed, or what changes to Windows Update behaviour. The README does not pretend otherwise, because it points you at the definition instead: to view exactly what each preset does, see `config/preset.json` in the repository. The consequence is a documentation pattern that is honest but easy to skim past. A reader who reads only the table will believe `Minimal` is a safe default because of its name. The actual contents are a JSON file, and `Minimal` promising to suit every user is not a claim the preset can make about anyone's machine. ## Four verbs are named, and the list of changes is not The project describes itself as a curated compilation of Windows system tasks that streamline installs, debloat with tweaks, troubleshoot with config, and configure Windows updates, and it says to run it fresh on every new Windows install. Those four verbs, installs, tweaks, config and Windows updates, are the whole scope statement. What the README never supplies is the inventory. There is no list of the programs it offers to install, no enumeration of the tweaks, and no description of what the config step changes. For a tool whose entire purpose is modifying a system, that omission is the most consequential thing in the file, and it is not a matter of brevity, because the detail demonstrably exists in `config/preset.json` and in the documentation site. The consequence is that you cannot assess the risk from the README alone. The word debloat in particular is doing a lot of work with no definition attached, and you should read the preset file before selecting one rather than after. What the README does state without hedging is the part that matters most operationally: Administrator rights, because the changes are system-wide. ## Version numbers are dates, and the newest tag is a pre-release The releases are named by date. The three most recent are 26.09.29, published 2026-09-29 and labelled Pre-Release, 26.08.19 from 2026-08-19 labelled Release, and 26.08.04 from 2026-08-04, also a Release. The last push to the repository was 2026-09-19, which is before the newest tag. Two things follow. First, the stable URL and the newest tag are not the same thing, so a version number tells you when a build was cut rather than what is in it, and there is no changelog in the repository to tell you what changed. Second, the pre-release label on the most recent build means the tip of the project is not what the recommended command is meant to give you, though nothing in the README explains how the stable URL selects between them. The consequence for an organisation is that you cannot pin by version at the URL. If you need reproducibility, take a commit from the repository and run that, because a date-named tag on a moving URL is not a version you can assert in a build record. ## The faster implementation is the one you have to pay for The support section is short and has a commercial edge to it. Alongside the request to leave a star, it points at a faster Dotnet implementation for sale. Then the sponsors section lists sixteen accounts funding the project with monthly contributions, and a footnote states that sponsors with a recurring subscription also get access to the .NET alternative. So there are two implementations of the same utility with different performance characteristics, and the MIT-licensed PowerShell one is the slower of the two by the project's own description. The free path is the one you install with `irm | iex`; the faster one is behind a purchase, and behind a recurring subscription for existing sponsors. The consequence is a licensing and support decision disguised as a performance one. Teams that take this into a standard image should decide deliberately which implementation they are standardising on, because the answer changes the cost, the support path and the code you are responsible for. Nothing in the repository compares the two beyond the word faster, so a team that assumes the free script is equivalent is making an assumption the README quietly contradicts. ## Conclusion WinUtil is worth using on a machine you are prepared to rebuild, and its documentation is more honest than the install command suggests. The four things it does are named, the requirement for Administrator is stated up front rather than discovered, the source is in the repository, the build is compiled and signed, and the presets are a JSON file you can read before choosing one. The irreducible risk is the delivery mechanism: a URL piped into iex has no version pin and no hash, so what runs is whatever the server serves at that moment. If your policy forbids that, clone the repository and read `config/preset.json` and `windev.ps1` first, or use the paid .NET implementation. Before running it, check three things: which preset you are picking and what it actually changes, whether your Windows build and the release cadence line up, and whether you have a restore path, because these are system-wide changes on a machine that also holds your work. ## FAQ ### What does WinUtil do? It is a curated compilation of Windows system tasks covering four areas: installing programs, debloating with tweaks, troubleshooting through config, and configuring Windows updates. The README describes it as something to run fresh on every new Windows install, and it must be run as Administrator because it performs system-wide changes. ### Is WinUtil safe? The honest answer is that the default install is a remote script executed with Administrator rights: `irm https://christitus.com/win | iex` downloads and executes in one step with no version pin or checksum. The repository does give you what you need to check it, since the script is committed as `windev.ps1`, the build is compiled and signed via `Compile.ps1` and `sign.bat`, and the presets are defined in `config/preset.json`. The README does not enumerate what the tweaks change, so read that file before selecting a preset. ### Is WinUtil free? The PowerShell version is MIT licensed and free to install. The README also advertises a faster Dotnet implementation for sale, and states that sponsors with a recurring subscription get access to that .NET alternative, alongside sixteen accounts listed as monthly sponsors. ### How do I use WinUtil? Open PowerShell or Terminal as Administrator, either from the Start menu or by pressing the Windows key, typing PowerShell or Terminal and using Ctrl+Shift+Enter. Then run `irm https://christitus.com/win | iex` for the stable branch, or the `windev` URL for the development branch. To apply a preset without choosing from the interface, use `& ([ScriptBlock]::Create((irm https://christitus.com/win))) -Preset Standard`, with `Minimal` and `Advanced` as the other options. ### How do I debloat Windows using WinUtil? Debloating is one of the four categories the utility covers, alongside installs, config and Windows updates, and it is done through the tweaks. The README does not list which services or scheduled tasks are affected, and instead directs you to `config/preset.json` to see exactly what each preset changes, with `Minimal`, `Standard` and `Advanced` offered as the levels. ## Sources - [Official README](https://github.com/ChrisTitusTech/winutil#readme) - [Project repository](https://github.com/ChrisTitusTech/winutil) - [Release notes](https://github.com/ChrisTitusTech/winutil/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/christitustech-winutil