How to Change Directory in PowerShell: Basics of Changing Directories

You already know cd changes directories. But PowerShell's navigation system goes way deeper than a simple command. Knowing the full toolkit saves you from the silent errors and path-resolution traps that waste hours of real debugging time.

The Basics: Using Set-Location and the cd Alias

The core command for moving around is Set-Location. In interactive terminal sessions, stick to the cd alias. It is shorter, familiar, and gets the job done instantly. In your .ps1 scripts, use Set-Location explicitly to maintain clean and readable code.

PowerShell gives you four different ways to execute the exact same command:

Absolute vs. Relative Paths in PowerShell

Understanding where your path begins is critical before hitting Enter.

An absolute path starts directly from the drive root. It works no matter where you currently are in the filesystem:

cd C:\Users\YourName\Documents

A relative path starts from your current location. It moves you up or down the existing directory tree:

cd Documents (Moves into the Documents folder from your current active folder)

cd .\Documents (The exact same action, just more explicit)

cd .. (Moves up exactly one level)

cd ..\.. (Moves up exactly two levels)

PowerShell also supports the ~ shortcut for your home directory:

cd ~ (Jumps to C:\\Users\\YourName)

Use the tilde (~) interactively. In scripts, prefer the $env:USERPROFILE variable. It leaves zero ambiguity about the destination.

How to Handle Paths with Spaces (The Quote Rule)

Unquoted paths with spaces break silently. PowerShell reads the space as an argument separator, causing the command to fail or target the wrong directory entirely.

cd C:\Program Files (BREAKS. PowerShell reads C:\\Program as the target path)

cd "C:\Program Files" (Works perfectly)

cd 'C:\Program Files\My App' (Also works)

Both double and single quotes work for plain paths. The critical difference appears when using variables. Single quotes treat everything literally, meaning environment variables inside them will not expand.

How to Check Your Current Location

Losing track of your active directory is easy during long sessions. Use these commands to find your exact location:

Get-Location (Returns your current path)

pwd (The standard alias, identical result)

Here is a pro tip most people miss: the -PassThru flag. Normally, Set-Location returns absolutely nothing upon success. With -PassThru, it immediately outputs where you landed.

Set-Location C:\Projects -PassThru

This is incredibly useful in scripts when you want to confirm navigation succeeded before executing destructive commands like Remove-Item.

Navigating Like a Pro: Push-Location and Pop-Location

Push-Location and Pop-Location (aliases: pushd / popd) are the only safe ways to handle temporary directory changes inside scripts.

Push saves your current location onto a hidden stack and moves you somewhere new. Pop returns you exactly to the original directory.

Push-Location C:\Temp\BuildOutput   # Save current state and move
Get-ChildItem
Remove-Item *.log
Pop-Location                        # Jump back to the original path

This method is far more reliable than saving a path into a manual variable, especially when a complex script has multiple exit points or error catches. For scripts with independent task contexts, you can even use named stacks with the -StackName parameter to keep multiple locations organized.

Going Back to the Previous Directory (cd -)

This feature exists natively in PowerShell, yet almost nobody knows about it.

If you are using PowerShell 6.2 or newer, cd - takes you straight back to your previous directory, just like Bash on Linux.

cd C:\Projects\WebApp

cd C:\Windows\System32

cd - (Takes you back to C:\\Projects\\WebApp)

PowerShell tracks your last 20 locations automatically in the background. No extra setup needed.

Version Check: This does NOT work in legacy Windows PowerShell 5.1. It will silently fail or throw an error. If you are still on 5.1, this feature alone is a compelling reason to upgrade to PowerShell 7.

Using Environment Variables to Change Directories

System environment variables are the safest way to navigate across different machines where user names and drive letters might change.

The Single-Quote Trap: cd '$env:APPDATA' (WRONG. Looks for a literal folder named $env:APPDATA)

cd "$env:APPDATA" (CORRECT. Double quotes expand the variable properly)

Switching Drives and the cd C: Gotcha

Switching between drives is straightforward. You can type D: to switch to the D drive, or cd E:\Data to switch and navigate in one single step.

But there is a major trap waiting here. Typing cd C: does NOT take you to the root of the C drive.

PowerShell remembers the last location you visited on every individual drive. Executing cd C: simply returns you there. That destination could be a deeply nested subfolder from three hours ago. In automated deployment scripts that jump between drives, this specific behavior has quietly broken path resolution more than once.

Always be explicit:

cd C:\ (Always goes straight to the root)

UNC Paths: Yes, PowerShell Supports Them

Unlike the old cmd.exe, PowerShell fully supports direct UNC path navigation without requiring you to map a temporary network drive.

Set-Location \\server01\SharedDocs

cd \\192.168.1.50\backups

Once you land in the network share, standard commands like Get-ChildItem work exactly as if it were a local SSD. Standard network share formats are highly reliable, though edge cases like WSL paths (\\wsl$\) can sometimes show inconsistencies.

Troubleshooting Common Set-Location Errors

Even experienced administrators run into terminal roadblocks. Here are the most common errors and their exact fixes.

Cannot find path 'X' because it does not exist

The path is either typed wrong or completely missing. Always validate the destination first inside scripts.

if (Test-Path "C:\MyFolder") {
    Set-Location "C:\MyFolder"
} else {
    Write-Error "Path not found"
}

Access to the path is denied

This is a strict permission block. You need to run the PowerShell session as an Administrator, or check the folder's Access Control List (ACL) using the Get-Acl cmdlet.

Script navigates correctly but .NET calls use the wrong directory

This is the most subtle, frustrating PowerShell-specific problem you will encounter.

PowerShell's working location and [System.Environment]::CurrentDirectory are entirely separate entities. Native executables and .NET APIs rely on the CurrentDirectory, not your PowerShell session's active location. If your automation script calls external tools, you must explicitly set both.

Set-Location C:\MyProject
[System.Environment]::CurrentDirectory = "C:\MyProject"

Beyond Filesystem: Registry, Certs, and Environment Variables

This is where PowerShell's navigation model genuinely separates itself from traditional command prompts. Set-Location works on any active PowerShell provider, not just your hard drive.

Windows Registry:

cd HKLM:\SOFTWARE\Microsoft

Once you are inside the HKLM:\ drive, the exact same Get-Item, Set-Item, and Remove-Item commands you use for basic files work flawlessly on complex registry keys. No separate registry API is needed.

Certificate Store:

cd Cert:\CurrentUser\My

Navigating here allows you to list your personal certificates instantly with Get-ChildItem. It is the absolute fastest way to audit expired certificates without waiting for the slow MMC graphical interface to load.

Environment Variables:

cd Env:\

Typing Get-ChildItem here lists every single environment variable as an interactive item. You can inspect specific variables with Get-Item Env:\PATH or change them on the fly.

To see every hidden navigation tree available on your system, run Get-PSProvider. The unified model - using the exact same commands and syntax across the filesystem, registry, and certificates - is what makes PowerShell automation so powerful once you internalize the rules.