How to Change Directory in PowerShell: Basics of Changing Directories

We all use cd without thinking twice. But under the hood, PowerShell handles paths and directories a lot differently than an old-school shell. Picking up the nuances here will save you from those subtle, hairline-fracture bugs that end up eating an entire afternoon of troubleshooting.

• Standard jump: cd C:\path\to\folder
• Paths with spaces: cd "C:\Program Files" (wrap them in quotes, every time)
• Jump back one spot: cd - (needs PowerShell 6.2+)
• See where you are: Get-Location

The Basics: Using Set-Location and the cd Alias

At the center of it all is the Set-Location cmdlet. When you're just kicking around in an interactive console, stick with cd - it's familiar, muscle memory takes over, and it saves keystrokes. When you switch over to writing .ps1 scripts, though, spell out Set-Location. Future you (and anyone doing code review) will appreciate the clarity.

PowerShell gives you four different ways to do the exact same thing:

Absolute vs. Relative Paths in PowerShell

Before you hit Enter, you always want to know where your command is anchoring itself.

An absolute path pins directly to the root of the drive. It doesn't care where you're currently standing:

cd C:\Users\YourName\Documents

A relative path starts from wherever your terminal happens to be right now, walking up or down from that vantage point:

cd Documents (Steps into Documents from your active directory)

cd .\Documents (Does the exact same thing, just a little more explicit)

cd .. (Hops up one parent folder)

cd ..\.. (Hops up two folders)

PowerShell also honors the Unix-style ~ shortcut for jumping straight home:

cd ~ (Puts you right in C:\Users\YourName)

Use ~ whenever you're typing by hand. In scripts, write out $env:USERPROFILE instead so there's zero guesswork about where the script lands across different environments.

How to Handle Paths with Spaces (The Quote Rule)

If a path has spaces and you leave off quotes, things fall apart fast. PowerShell treats spaces as argument delimiters, meaning it chops your path in half and either throws an error or tries to target the wrong folder entirely.

cd C:\Program Files (Fails out. PowerShell thinks you're passing C:\Program as the path)

cd "C:\Program Files" (Clean, works every time)

cd 'C:\Program Files\My App' (Works just as well)

Single and double quotes both work for plain static paths, but there's a catch once variables enter the picture: single quotes are strictly literal. Any environment variable inside single quotes won't evaluate.

How to Check Your Current Location

It’s surprisingly easy to lose your footing during a long terminal session. If you ever need to verify where you are, grab your bearings with these:

Get-Location (Spits out your active directory)

pwd (The classic alias that prints the exact same thing)

Here's a neat trick that flies under the radar: the -PassThru switch. By default, Set-Location is completely silent when it succeeds. Add -PassThru, and it immediately prints where you just arrived.

Set-Location C:\Projects -PassThru

This is gold inside deployment scripts when you want to log or visually confirm that a path change worked before running something destructive like Remove-Item.

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

Push-Location and Pop-Location (or their shorthand cousins pushd and popd) are the cleanest way to take temporary detours inside a script.

Push takes your current path, drops it onto an internal stack, and hops to the new folder. Once your work is finished, Pop pulls that saved path off the stack and drops you right back where you started.

PowerShell

Push-Location C:\Temp\BuildOutput   # Bookmark where we are and jump
Get-ChildItem
Remove-Item *.log
Pop-Location                        # Snap right back to the original spot

This is infinitely safer than stashing paths inside custom variables, especially when scripts have multiple exit points or try/catch blocks. If you have several tasks juggling different folders at once, you can even pass the -StackName parameter to run isolated, named stacks side by side.

Going Back to the Previous Directory (cd -)

This is one of those quality-of-life gems built right into modern PowerShell that remarkably few people use.

As long as you're running PowerShell 6.2 or newer, typing cd - bounces you right back to your previous directory, mirroring the classic Bash behavior.

cd C:\Projects\WebApp

cd C:\Windows\System32

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

Under the hood, PowerShell keeps a rolling history of your last 20 locations automatically. You don't have to configure anything to get it running.

A quick heads-up on versions: This won't work in legacy Windows PowerShell 5.1. It will just fail or complain about the argument. If you're still on 5.1, small conveniences like this are honestly reason enough to make the jump to PowerShell 7.

Using Environment Variables to Change Directories

Relying on environment variables is the smart way to build robust paths, especially when your code runs across different machines with varying usernames or drive configurations.

Watch out for single quotes here: cd '$env:APPDATA' (Won't work. It literally searches for a directory named "$env:APPDATA")

cd "$env:APPDATA" (The right way. Double quotes let PowerShell expand the variable value)

Switching Drives and the cd C: Gotcha

Bouncing across drives is easy enough - you can type D: to switch drives, or run cd E:\Data to switch drive letters and land in a specific folder in one go.

Here's the trap that bites people: typing cd C: doesn't necessarily dump you at the root of the C drive.

PowerShell actually remembers your last active working directory on each separate drive letter. When you enter cd C:, it returns you to wherever you were last working on that drive - which might be a buried subdirectory from earlier this morning. In automated build pipelines that juggle multiple drives, that behavior has tripped up many a script.

If you want the root, be explicit:

cd C:\ (Guarantees you land directly at root every time)

UNC Paths: Yes, PowerShell Supports Them

Unlike the old cmd.exe days where you had to map a network share to an arbitrary drive letter first, PowerShell lets you work directly against raw UNC paths.

Set-Location \\server01\SharedDocs

cd \\192.168.1.50\backups

The moment you land in that share, everything works like normal. Cmdlets like Get-ChildItem behave just as smoothly as they would on your local hard drive. Standard SMB shares are rock solid, though you might occasionally see odd behavior if you're working with certain virtual paths like \\wsl$\.

Troubleshooting Common Set-Location Errors

Even when you've been working in the shell for years, path errors happen. These are the big three you'll run across, along with how to handle them.

Cannot find path 'X' because it does not exist

Usually a typo, or the directory got deleted out from under you. When you're scripting, it's good practice to guard against this before trying to move.

PowerShell

if (Test-Path "C:\MyFolder") {
    Set-Location "C:\MyFolder"
} else {
    Write-Error "Target directory is missing."
}

Access to the path is denied

You're hitting a permissions wall. Either elevate your shell to an administrator session, or inspect what's going on with the folder's Access Control List using Get-Acl.

Script navigates correctly but .NET calls use the wrong directory

This is easily the sneakiest bug you'll encounter when writing PowerShell automation.

PowerShell tracks its own internal working location, which is completely decoupled from [System.Environment]::CurrentDirectory. If your script calls native compiled binaries or dips into underlying .NET methods, they look at CurrentDirectory, not where PowerShell thinks you're sitting. If you're mixing both, manually synchronize them:

PowerShell

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

Beyond Filesystem: Registry, Certs, and Environment Variables

Here’s where PowerShell's design really clicks. Set-Location isn't restricted to folders on a disk; it navigates through any mounted PowerShell provider using the exact same commands.

The Windows Registry:

cd HKLM:\SOFTWARE\Microsoft

Once you hop into HKLM:\, you treat registry keys like regular folders. Standard cmdlets like Get-Item, Set-Item, and Remove-Item work straight on keys and values without needing separate registry tools.

The Certificate Store:

cd Cert:\CurrentUser\My

Step inside the certificate drive and run Get-ChildItem to list installed certs immediately. It beats launching certmgr.msc and clicking through nested MMC snap-in menus every single time.

Environment Variables:

cd Env:\

Drop into Env:\ and run Get-ChildItem to see your environment variables laid out like files. You can check a specific variable with Get-Item Env:\PATH or update them right in place.

If you want to see what else you can traverse this way, run Get-PSProvider. That unified approach - using the same navigation tools for drives, the registry, and certs - is what makes PowerShell genuinely feel like an integrated management engine rather than just another terminal prompt.