A cmdlet (pronounced command-let) is a lightweight, compiled command in PowerShell, implemented as a .NET class and named in a standard Verb-Noun form such as Get-Process or Set-Service. Unlike traditional console programs, a cmdlet receives and emits structured .NET objects, which lets commands be chained in a pipeline without parsing text.
In PowerShell & command line administration on Windows, cmdlets are the basic building blocks from which scripts, automation and remote management are composed. They run inside the PowerShell host process rather than as separate executables, and they share a common framework for parameters, error handling, help and confirmation prompts.
How a cmdlet works internally
A cmdlet is a class that derives from the Cmdlet or PSCmdlet base class and carries a Cmdlet attribute declaring its verb and noun. PowerShell discovers the class when its binary module is imported, binds the parameters supplied by the user and then calls a fixed sequence of methods.
| Method | When it runs | Typical use |
|---|---|---|
| BeginProcessing | Once, before pipeline input arrives | Open connections, validate setup |
| ProcessRecord | Once for each pipeline object | Core work on every input item |
| EndProcessing | Once, after all input | Summaries, cleanup, final output |
| StopProcessing | When the user presses Ctrl+C | Cancel long operations safely |
Output is produced with WriteObject, which sends objects down the pipeline as soon as they are ready. This streaming behavior means that a command like Get-ChildItem -Recurse | Select-Object -First 5 can stop early instead of waiting for a full directory scan.
Naming, parameters and common parameters
Every cmdlet follows the Verb-Noun convention, and the verb should come from the list of approved verbs returned by Get-Verb. This consistency makes commands discoverable: an administrator who knows Get-Service can reasonably guess Stop-Service and Start-Service.
Parameters are declared as class properties with a Parameter attribute that sets whether they are mandatory, positional or accept pipeline input. In addition, every cmdlet automatically supports the common parameters, which give all commands a uniform control surface.
| Parameter | Effect | Example use |
|---|---|---|
| -WhatIf | Shows what would happen without making changes | Preview a bulk deletion |
| -Confirm | Asks before each change | Interactive safety on servers |
| -ErrorAction | Sets the response to errors, such as Stop or SilentlyContinue | Turn errors into terminating ones for try/catch |
| -Verbose | Prints detailed progress messages | Troubleshooting a script |
| -OutVariable | Stores output in a variable while passing it on | Reuse results later in the pipeline |
The -WhatIf and -Confirm parameters are available only when the cmdlet declares SupportsShouldProcess. Well-written cmdlets that change system state always do, which is why -WhatIf is a recommended first step before running destructive commands.
Pipeline binding and error handling
The pipeline is where cmdlets differ most from classic commands. PowerShell binds pipeline objects to parameters in two ways: ByValue, when the incoming object’s type matches the parameter type, and ByPropertyName, when the object has a property whose name matches the parameter.
For example, Get-Service -Name spooler | Stop-Service works because Stop-Service accepts ServiceController objects by value. Importing a CSV file with a column called Name and piping it into a cmdlet that has a Name parameter works through binding by property name, without any loop. Trace-Command -Name ParameterBinding shows exactly how binding was resolved when something unexpected happens.
Cmdlets also report problems through structured channels rather than printed messages. A cmdlet calls WriteError for a non-terminating error, which records the failure for one input item and lets the pipeline continue with the next, or ThrowTerminatingError when it cannot proceed at all. Each error is an ErrorRecord object with a category, a target object and an identifier, so a script can inspect the $Error collection or catch specific failures instead of matching message text. Combined with -ErrorAction Stop, this makes cmdlet-based scripts far more predictable than scripts that wrap console programs and test their exit codes.
Cmdlets compared with other command types
PowerShell runs several kinds of commands, and Get-Command reports each one’s CommandType. Understanding the differences explains why some commands return objects and others return text.
| Command type | Implementation | Output | Example |
|---|---|---|---|
| Cmdlet | Compiled .NET class in a binary module | Objects | Get-Process |
| Advanced function | PowerShell script with CmdletBinding | Objects | Functions in a script module |
| Alias | Alternative name for another command | Same as target | ls, dir, gci |
| Application | External executable | Text streams | ipconfig.exe, robocopy.exe |
| ExternalScript | A .ps1 file | Whatever the script outputs | Deploy.ps1 |
Advanced functions are often called script cmdlets because they gain the same common parameters and binding behavior. The practical difference is performance and distribution: compiled cmdlets are faster for heavy processing, while functions are easier to write and modify. When names collide, PowerShell resolves them by command precedence: aliases first, then functions, then cmdlets, then external applications.
Finding and using cmdlets effectively
The number of available cmdlets depends on the installed modules and the PowerShell edition, so discovery commands matter more than memorization. Windows PowerShell 5.1 runs on .NET Framework, while PowerShell 7 is cross-platform and some older modules work in it only through a compatibility layer.
| Command | What it answers |
|---|---|
| Get-Command -Noun Service | Which cmdlets work with services |
| Get-Help Stop-Service -Examples | How a cmdlet is used in practice |
| Get-Member | Which properties and methods the output objects have |
| Get-Module -ListAvailable | Which modules and cmdlets can be loaded |
- Avoid aliases in scripts: they are convenient interactively but reduce readability and may differ between platforms.
- Filter early: use a cmdlet’s own -Filter parameter instead of piping everything into Where-Object.
- Do not parse formatted output: Format-Table produces display objects, so it should be the last command in a pipeline.
The simple explanation
A cmdlet is a single, small command in PowerShell that does one job, such as listing running programs or stopping a service. Its name always says what it does: a verb and a noun, like Get-Process.
The clever part is what it hands to the next command. Instead of plain text, it passes neatly labeled information, like a form with filled-in fields. The next command can read exactly the field it needs. The key takeaway is that cmdlets fit together like building blocks.
How it is used in practice
A system administrator must find every Windows service on 40 servers that is set to start automatically but is currently stopped, and restart it. With classic tools this would require parsing text from each server.
With cmdlets, one pipeline does the job: Get-Service runs on each server through PowerShell remoting, Where-Object keeps services whose StartType is Automatic and whose Status is Stopped, and Start-Service receives those objects directly. She first adds -WhatIf to see the planned changes, reviews the list of 17 services and then runs the command for real. The task that used to take an afternoon is finished in minutes and can be saved as a reusable script.