Export-Csv -NoTypeInformation: remove the #TYPE line from CSV files

In Windows PowerShell 5.1, Export-Csv and ConvertTo-Csv write a first line such as #TYPE System.Management.Automation.PSCustomObject before the header. Excel and most CSV readers show it as data. Add -NoTypeInformation:

Get-Process | Select-Object Name, Id, CPU | Export-Csv processes.csv -NoTypeInformation

PowerShell 6 and later do not write the type line by default (-NoTypeInformation is still accepted and does nothing); use -IncludeTypeInformation there if you want it.

See the difference

$rows = [pscustomobject]@{ Name = 'alpha'; Size = 1 }, [pscustomobject]@{ Name = 'beta'; Size = 2 }
$rows | Export-Csv default.csv
'--- Export-Csv (Windows PowerShell 5.1):'
Get-Content default.csv
$rows | Export-Csv clean.csv -NoTypeInformation
'--- Export-Csv -NoTypeInformation:'
Get-Content clean.csv
'--- default encoding in 5.1 with a non-ASCII value:'
[pscustomobject]@{ City = 'Zürich' } | Export-Csv city.csv -NoTypeInformation
(Get-Content city.csv)[1]

--- Export-Csv (Windows PowerShell 5.1):
#TYPE System.Management.Automation.PSCustomObject
"Name","Size"
"alpha","1"
"beta","2"
--- Export-Csv -NoTypeInformation:
"Name","Size"
"alpha","1"
"beta","2"
--- default encoding in 5.1 with a non-ASCII value:
"Z?rich"

Other Export-Csv parameters that matter

When to use it

Add -NoTypeInformation to every Export-Csv and ConvertTo-Csv call in scripts that may run in Windows PowerShell 5.1: reports for Excel, files loaded into a database, data sent to another system. The #TYPE line is a PowerShell convention that no other CSV reader understands, so it becomes a bogus first row or breaks header detection. Because PowerShell 6 and later accept the switch and ignore it, writing it is safe on every version; the short alias -NTI works too.

Nested values do not survive

CSV is flat. Each property is converted to a string, so an array or an object becomes its .NET type name. Flatten it with a calculated property first:

$o = [pscustomobject]@{ Name = 'web01'; Tags = @('prod', 'eu') }
'--- array property as is:'
$o | ConvertTo-Csv -NoTypeInformation
'--- joined with a calculated property:'
$o | Select-Object Name, @{ n = 'Tags'; e = { $_.Tags -join ';' } } | ConvertTo-Csv -NoTypeInformation

--- array property as is:
"Name","Tags"
"web01","System.Object[]"
--- joined with a calculated property:
"Name","Tags"
"web01","prod;eu"

For data with nesting, export JSON instead and set a sufficient ConvertTo-Json -Depth.

Pitfalls

• Format cmdlets before export. Format-Table and Format-List produce formatting records; exporting them writes columns such as ClassId2e4f51ef21dd47e99d3c952918aff9cd. Use Select-Object.
• Columns come from the first object. Export-Csv writes the header from the properties of the first object. Later objects with extra properties lose them, so select the same property list for every object.
• Append with different columns. -Append fails with "Cannot append CSV content to the following file" when a new object lacks one of the existing columns; -Force writes it anyway, leaving that column empty and dropping properties that have no column.
• Encoding. In 5.1 the default encoding replaces non-ASCII characters with ?, as the first example shows. Pass -Encoding UTF8 for names with accents; in PowerShell 7 the default is already UTF-8 without a BOM. Excel may need the BOM to detect UTF-8, which is why 5.1's UTF8 value is often what Excel users want.

FAQ