Think you know Windows environment variables? Think again.
They stop hardcoded paths from breaking your scripts and make tools portable across accounts.
This cheat-sheet lists the common names—PATH, TEMP, APPDATA, USERPROFILE, SYSTEMROOT—and explains what each one does and when to edit it.
You’ll get quick viewing and editing tips for cmd, PowerShell, and the GUI, plus PATH best practices and common gotchas.
Read on to avoid a broken PATH and make scripts that work on any Windows machine.
Comprehensive Overview of Windows Environment Variables
Windows environment variables are predefined system values that store paths, configuration settings, and user info. They save you from hardcoding absolute paths in scripts and applications, which makes code portable across different machines and user accounts. Reference %APPDATA% instead of C:\Users\YourName\AppData\Roaming, and your script works for any user without modification.
Both Windows 10 and Windows 11 support the same set of environment variables. Identical syntax, identical access methods. Variables fall into two categories: system variables (shared by all users, need administrator privileges to modify) and user variables (specific to whoever’s logged in). The operating system keeps separate storage for each type, displayed in two sections when you open the Environment Variables dialog.
| Variable Name | Purpose |
|---|---|
| PATH | Directories searched for executable files when commands are run |
| TEMP | Primary temporary directory for applications and installers |
| TMP | Secondary temporary directory (usually identical to TEMP) |
| APPDATA | Roaming application data folder for the current user |
| LOCALAPPDATA | Local (non-roaming) application data folder |
| USERPROFILE | Path to the current user’s profile directory |
| SYSTEMROOT | Windows installation directory (typically C:\Windows) |
| WINDIR | Alternative reference to the Windows directory |
| COMPUTERNAME | Network name of the local machine |
| USERNAME | Name of the currently logged-in user account |
System variables stay consistent across all accounts on a machine. User variables can differ for each login. Changes to system variables require elevation (Run as Administrator), but editing your own user variables doesn’t. Some modifications take effect immediately in new command windows, others need you to sign out or reboot to propagate everywhere.
Windows Environment Variables List for Daily Use
This extended reference covers additional variables you’ll encounter regularly when building scripts, troubleshooting installation issues, or diagnosing system configuration problems.
PATHEXT stores file extensions Windows recognizes as executable (.COM, .EXE, .BAT, .CMD, .VBS, .JS, .PS1), so you can run commands without typing the full extension.
ALLUSERSPROFILE points to the shared application data directory accessible by all users, typically C:\ProgramData on modern Windows versions.
ProgramFiles is the default installation directory for 64-bit applications on x64 systems (C:\Program Files).
ProgramFiles(x86) is the default installation directory for 32-bit applications on 64-bit Windows (C:\Program Files (x86)).
CommonProgramFiles holds shared files directory for 64-bit programs (C:\Program Files\Common Files).
OS contains the operating system identification string, typically “Windows_NT” on all NT-based Windows releases.
PROCESSOR_ARCHITECTURE tells you the CPU architecture type (AMD64 for 64-bit Intel/AMD, x86 for 32-bit, ARM64 for ARM processors).
NUMBEROFPROCESSORS gives you the count of logical processors available to the operating system. Useful for multi-threaded script optimization.
COMSPEC is the full path to the command interpreter executable, usually C:\Windows\System32\cmd.exe.
HOMEDRIVE is the drive letter containing the current user’s profile, typically C:.
HOMEPATH is the relative path to the user’s profile directory from HOMEDRIVE (for example, \Users\YourName).
TMP is an alternative temporary directory variable, functionally identical to TEMP in most configurations.
These variables maintain backward compatibility across Windows 11, Windows 10, Windows 8.1, Windows 7, and Windows Vista. Older systems like Windows XP and Windows 2000 support most of these with minor differences in default paths and naming conventions, but the core functionality stays consistent for scripts targeting modern environments.
Methods to View the Windows Environment Variables List
Three primary methods let you inspect the complete set of environment variables on your system. Command Prompt, PowerShell, and the graphical System Properties interface. Each approach offers different output formats and filtering capabilities suited to different workflows.
Viewing via Command Prompt
Press Win+R to open the Run dialog, type “cmd” and hit Enter to launch the command prompt. Type set and press Enter to display all environment variables in name=value format, one per line. The output scrolls quickly for a full listing, so you can pipe it to more (set | more) or redirect to a file (set > variables.txt).
To view a specific variable, use the echo command with percent signs wrapping the variable name. For example, echo %PATH% displays the current PATH value. Command Prompt also supports basic filtering: set USER shows only variables whose names start with “USER”, returning USERNAME, USERPROFILE, and related entries.
Viewing via PowerShell
Open PowerShell by pressing Win+R, typing “powershell”, and hitting Enter. Run Get-ChildItem Env: to list all environment variables in a formatted table with Name and Value columns. PowerShell’s table output wraps long values across multiple lines and aligns columns for readability, making it easier to scan than cmd’s raw text.
PowerShell supports several aliases that produce identical results. gci Env:, dir Env:, and ls Env: all invoke Get-ChildItem on the Env: drive. You can filter output by piping to Where-Object or Sort-Object, and you can reference individual variables using $Env:VARIABLENAME syntax (for example, $Env:TEMP). On Windows XP, you must install .NET Framework 2.0 SP2 followed by Windows PowerShell 1.0. Modern Windows releases (Vista and later) include PowerShell by default.
Viewing via Windows GUI
Press Win+R, type “sysdm.cpl”, and hit Enter to open System Properties directly to the Computer Name tab. Click the Advanced tab, then click the Environment Variables button at the bottom. The resulting dialog splits variables into two sections: User variables for the current account appear in the top list, and System variables shared by all users appear in the bottom list.
Each section displays variable names in the left column and their values in the right column. You can scroll through both lists independently. Double-clicking any entry opens an edit dialog showing the full value. This method requires no command-line knowledge and provides the clearest separation between user-level and system-level configuration.
Editing and Managing Windows Environment Variables
User-level variables affect only the currently logged-in account and can be modified without special permissions. System-level variables apply to all users and require administrator privileges to change. Understanding this distinction prevents confusion when a variable you set doesn’t appear for other accounts or when you receive “access denied” errors attempting system-wide edits.
The GUI provides the most straightforward editing interface. Open the Environment Variables dialog (Win+R, sysdm.cpl, Advanced, Environment Variables), select either the User or System section depending on scope, and use the New, Edit, or Delete buttons to manage entries.
The workflow for safe variable management follows this sequence:
Click New to create a new variable, entering the name (without percent signs) and value in the dialog fields.
Select an existing variable and click Edit to modify its value, which opens a dialog showing the current setting.
Select a variable and click Delete to remove it entirely. This action can’t be undone from the GUI.
Click OK in the Environment Variables dialog, then OK again in System Properties to commit all changes.
Sign out and back in (or reboot for system variables) if changes don’t appear immediately in new command windows.
Command Prompt’s set command creates session-only variables that disappear when you close the window. Running set MY_VAR=TestValue defines MY_VAR for the current cmd session but doesn’t persist it to the registry. This approach works for temporary overrides during testing but never survives a reboot or new shell launch.
PowerShell offers both temporary and permanent variable management. Use $Env:MY_VAR = "TestValue" for session-only changes identical to cmd’s behavior. For persistent user-level variables, run [System.Environment]::SetEnvironmentVariable("MY_VAR","TestValue","User"), and for system-level variables (requires elevated PowerShell), use [System.Environment]::SetEnvironmentVariable("MY_VAR","TestValue","Machine"). These changes write directly to the registry and survive reboots.
Windows PATH Variable Details and Best Practices
The PATH variable tells Windows which directories to search when you type a command without specifying its full location. When you run python from any directory, the system walks through each PATH entry in order until it finds python.exe. Developers depend on PATH to make tools available system-wide without copying executables into System32 or other protected directories.
Incorrect PATH edits can break essential commands like ipconfig, ping, and even cmd itself if critical system directories are removed. Always back up your current PATH value before making changes. Copy the entire string to a text file or use echo %PATH% > path_backup.txt from cmd. Many installers automatically append their directories to PATH, which can lead to duplicate entries or conflicting versions of the same tool (for example, multiple Python installations).
| PATH Entry Example | Description |
|---|---|
| C:\Windows\System32 | Core Windows command-line utilities and system executables |
| C:\Windows | Base Windows directory, legacy executable location |
| C:\Program Files\Common Files | Shared binaries used by multiple applications |
| C:\Users\YourName\AppData\Local\Programs\Python\Python311 | Python installation directory containing python.exe |
| C:\Program Files\Java\jdk-17\bin | Java Development Kit binaries (javac, java, jar) |
| C:\Program Files\Git\cmd | Git command-line tools accessible from any directory |
Path hijacking occurs when a malicious executable is placed in a directory that appears earlier in PATH than the legitimate tool. If an attacker writes a fake python.exe into C:\Windows (which appears before your real Python directory), running python executes the malicious version. Keep PATH entries minimal, prioritize system directories at the beginning, and audit PATH regularly to remove entries from uninstalled software. Always append new directories using a semicolon separator rather than replacing the entire PATH value, which preserves existing functionality while adding your new tool.
Troubleshooting Issues With Windows Environment Variables
Common environment variable problems stem from scope confusion, permission errors, or stale values that haven’t refreshed in active sessions.
Missing PATH entries. A newly installed tool isn’t recognized as a command. Solution: verify the installation added its directory to PATH by checking the Environment Variables dialog. If missing, manually add the path and restart your terminal.
Incorrect path syntax. Extra spaces, missing semicolons, or quotes around individual entries cause parsing failures. Solution: edit PATH and ensure each directory is separated by a single semicolon with no trailing semicolon at the end.
Access denied when editing system variables. Attempting to modify Machine-level variables without elevation. Solution: close the Environment Variables dialog, right-click Command Prompt or PowerShell, select Run as Administrator, then reopen sysdm.cpl from the elevated session.
Changes not appearing in open windows. Variables updated in the registry don’t propagate to shells launched before the edit. Solution: close all cmd and PowerShell windows and open new ones. Some system variables require a full sign-out or reboot.
Variable not refreshing after edit. Explorer and other GUI applications cache environment values at startup. Solution: sign out and back in, or reboot for system-level changes to reach all running processes.
Script references wrong user variable. A script hardcodes a path that works for one account but fails for others. Solution: replace absolute paths with %USERPROFILE% or %APPDATA% so the script adapts to any user.
Corrupted PATH variable. Accidentally deleted or overwrote PATH instead of appending. Solution: restore from your backup text file. If none exists, rebuild PATH by re-adding C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem and any custom tool directories.
Conflicting software paths. Two versions of the same tool installed in different directories. The wrong one runs. Solution: reorder PATH entries so the preferred installation directory appears first, or uninstall the unwanted version.
Editing Machine-level (system) variables always requires administrative rights, triggered either by launching sysdm.cpl from an elevated shell or confirming a UAC prompt when saving changes. User-level variables can be modified by the account owner without elevation. When troubleshooting persistence issues, remember that set in cmd and $Env: assignments in PowerShell create temporary values that vanish when the session ends. Use the GUI or PowerShell’s SetEnvironmentVariable method for permanent changes.
Final Words
You can now list, edit, and troubleshoot environment variables in Windows 10/11 using CMD, PowerShell, or the GUI.
We covered the core names (PATH, APPDATA, USERNAME, SYSTEMROOT), how user vs system scopes behave, safe PATH editing, and quick fixes for common errors.
Use the step-by-step view/edit methods, confirm changes, and reboot when required. When something fails, check permissions, session scope, and syntax first.
Keep this windows environment variables list as a quick reference; it’ll save you time on missing paths and permission gotchas. You’ve got this.
FAQ
Q: How do I get the environment variable list in Windows?
A: You get the environment variable list in Windows by using Command Prompt (run set), PowerShell (Get-ChildItem Env:), or the GUI (Win+R → sysdm.cpl → Advanced → Environment Variables) to view user and system entries.
Q: What are the environment variables in Windows?
A: The environment variables in Windows are key-value pairs Windows and apps use for paths and config; common ones include PATH, TEMP, APPDATA, LOCALAPPDATA, USERPROFILE, SYSTEMROOT, COMPUTERNAME, and USERNAME.