PowerShell Get-Item vs Get-ChildItem: Key Differences

Two of the most frequently used file system cmdlets in PowerShell look similar but serve different purposes. Understanding PowerShell Get-Item vs Get-ChildItem prevents a common class of mistakes: using Get-ChildItem when you know the exact path (wasteful), or using Get-Item when you need to list the contents of a folder (returns the folder itself, not its files).

Quick Answer / TL;DR

Get-Item retrieves one specific item at the path you provide. Get-ChildItem lists the contents of a container (folder, registry key, certificate store). Use Get-Item when you know the exact path; use Get-ChildItem to enumerate contents.

Get-Item: Retrieve Specific Item

Get-Item returns the item at the specified path — the file, folder, registry key, or environment variable itself. It does not list contents. If the item does not exist, it throws a terminating error unless you add -ErrorAction SilentlyContinue. The return type depends on the item: FileInfo for files, DirectoryInfo for folders.

# Get a specific file
$file = Get-Item -Path C:\Logs\app.log
$file.Length       # file size in bytes
$file.LastWriteTime

# Get a specific folder (returns the folder itself, not its contents)
$folder = Get-Item -Path C:\Logs
$folder.GetType().Name   # DirectoryInfo

# Check if file exists and get its info
if (Test-Path C:\Config\settings.json) {
    $config = Get-Item C:\Config\settings.json
    Write-Host "Config size: $($config.Length) bytes"
}

Get-ChildItem: List Contents

Get-ChildItem (alias gci, ls, dir) lists the items inside a container: files in a folder, subkeys in a registry key, or certificates in a store. Use -Recurse to include all subdirectories. Use -Filter for efficient OS-level filtering.

# List all files in a folder
Get-ChildItem -Path C:\Logs

# List only .log files (OS-level filtering — fast)
Get-ChildItem -Path C:\Logs -Filter '*.log'

# Recursive listing of all subdirectories
Get-ChildItem -Path C:\Logs -Recurse -File

# List only directories
Get-ChildItem -Path C:\Projects -Directory

Get-Item on Registry Paths

Both cmdlets work with registry paths using PowerShell’s registry drive format. Get-Item retrieves the registry key as an object with a Property collection. Get-ChildItem lists the subkeys under that key.

# Get the registry key object
$key = Get-Item -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'

# Access a value in the key
$key.GetValue('ProductName')     # Windows version string
$key.GetValue('CurrentBuild')    # Build number

# List all subkeys (Get-ChildItem)
Get-ChildItem -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
    Select-Object Name, Property

Get-Item on Environment Variables

The Env: drive exposes environment variables. Get-Item retrieves a specific variable; Get-ChildItem lists all variables. This is more structured than using $env:VAR when you need to enumerate or search environment variables programmatically.

# Get a specific environment variable
$pathVar = Get-Item -Path 'Env:PATH'
$pathVar.Value   # full PATH value
$pathVar.Name    # 'PATH'

# List all environment variables
Get-ChildItem -Path 'Env:' | Sort-Object Name | Format-Table Name, Value -AutoSize

# Find environment variables containing 'JAVA'
Get-ChildItem -Path 'Env:' | Where-Object Name -like '*JAVA*'

Wildcards: Behavior Differences

Both cmdlets accept wildcards, but the behavior differs. Get-Item C:\Logs\*.log returns all files matching the pattern — which looks like Get-ChildItem behavior, but only works one level deep. Get-ChildItem C:\Logs\*.log is equivalent at that level but supports -Recurse for deep searches.

# Get-Item with wildcard — one level only
Get-Item C:\Logs\*.log              # all .log files in C:\Logs

# Get-ChildItem with wildcard — supports recursion
Get-ChildItem C:\Logs -Filter *.log -Recurse   # all .log files in tree

# Wildcard in the middle of path (Get-Item handles this well)
Get-Item C:\Users\*\AppData\Local\Temp    # Temp folder for all users

Which to Use in Scripts

A practical decision guide:

• You know the exact path and need the item’s properties → Get-Item
• You need to list files in a folder → Get-ChildItem
• You need to enumerate subkeys in a registry key → Get-ChildItem
• You need recursive file listing → Get-ChildItem -Recurse
• You need to modify a file (read, copy, delete) and know the path → Get-Item
• You need to process all files matching a pattern → Get-ChildItem -Filter

# Efficient: Get-Item when path is known
$logFile = Get-Item C:\Logs\app.log
$logFile | Copy-Item -Destination C:\Archive\

# Efficient: Get-ChildItem for enumeration
$staleFiles = Get-ChildItem C:\Temp -Recurse -File |
    Where-Object LastWriteTime -lt (Get-Date).AddDays(-30)
$staleFiles | Remove-Item -Force

Common Errors and Fixes

• Get-Item on a folder returns the folder itself not its files. Get-Item C:\Logs returns one DirectoryInfo object representing the folder. To list the files inside, use Get-ChildItem C:\Logs. This trips up many scripts that expect Get-Item on a folder path to return its file contents.
• Wildcard in Get-Item works but looks like Get-ChildItem behavior. Get-Item C:\Logs\*.log returns multiple items matching the pattern, which can look like the enumeration behavior of Get-ChildItem. The difference is that Get-Item wildcards are evaluated by the provider at that path level only; -Recurse is a Get-ChildItem-only feature.

Related Cmdlets / See Also

• PowerShell Get-Childitem
• PowerShell Test-Path

Wrapping Up

Get-Item is for known paths; Get-ChildItem is for enumeration. When you have the full path, Get-Item is faster and semantically clearer. When you need to list, filter, or recurse through a container’s contents, Get-ChildItem is the right tool — with -Filter for efficient pattern matching and -Recurse for deep traversal.