Today I learned something new in PowerShell.
I have been using PowerShell for a long time, but ConvertFrom-StringData was one of those cmdlets that I never really used before. Funny enough, I had situations in the past where I could have used exactly this.
And this is a good reminder. It does not matter how long we work with a topic or how much experience we have. There is always something new to learn. Sometimes it is not a big framework or a complex concept. Sometimes it is just one small cmdlet that makes a script cleaner and easier to read.
The problem, data is not always an object
PowerShell is great when we work with objects. Objects have properties, and those properties can be filtered, checked, sorted, exported, or passed through the pipeline.
But sometimes the data does not arrive as a PowerShell object. Sometimes it arrives as plain text.
This can happen when data comes from another script, from a text field, from an old tool, from command output, from a database value, or from a system that passes everything as string.
For example, the data can look like this:
$RawData = "@{Profile=PowerUser; Name=Ahmed; StartDate=2026-05-12; Debug=True; Logging=True; SendReport=True}"
At first look, this looks like a PowerShell hashtable. But if this value is stored in a variable as string, PowerShell cannot use it like a hashtable.
This means this will not work as expected:
$RawData.Profile
$RawData.Debug
$RawData.Logging
The reason is simple. $RawData is only text. PowerShell does not know that Profile, Debug, or Logging should be usable values.
Where this can really happen
This is something that can happen more often than expected.
Sometimes a tool gives back data in a simple key value format. Sometimes a value is stored in a SQL table as text. Sometimes a script writes settings into a string. Sometimes a legacy system returns data that is readable for humans, but not directly usable for PowerShell.
The information is there, but before PowerShell can work with it properly, it needs to be parsed into structured data.
The useful part, ConvertFrom-StringData
ConvertFrom-StringData can convert simple Key=Value text into a hashtable.
The important detail is that ConvertFrom-StringData expects one key value pair per line. So if the data is separated by semicolons, we first need to clean it and split it into lines.
$RawData = "@{Profile=PowerUser; Name=Ahmed; StartDate=2026-05-12; Debug=True; Logging=True; SendReport=True}"
$CleanData = $RawData -replace '^@\{','' -replace '\}$',''
$StringData = ($CleanData -split ';' | ForEach-Object {
$_.Trim()
}) -join "`n"
$Data = ConvertFrom-StringData -StringData $StringData
$Data
Now $Data is a hashtable, and the values can be accessed by their names.
$Data.Profile
$Data.Name
$Data.Debug
$Data.Logging
$Data.SendReport
Example output:
PowerUser
Ahmed
True
True
True
Now PowerShell can work with it
After the string is converted, the script becomes much cleaner. Instead of searching inside a long string, PowerShell can check specific values.
if ($Data.Debug -eq "True") {
"Debug mode is enabled"
}
if ($Data.Logging -eq "True") {
"Logging is enabled"
}
if ($Data.SendReport -eq "True") {
"Report will be sent"
}
This is much better than doing something like this:
if ($RawData -like "*Debug=True*") {
"Debug mode is enabled"
}
Searching in a string can work, but it is not clean. It is also easier to break when the string changes. A parsed hashtable is easier to read, easier to use, and easier to maintain.
One important detail
ConvertFrom-StringData returns the values as strings. That means True looks like a Boolean value, but it is still text.
$Data.Debug.GetType().FullName
The output is:
System.String
In many cases this is fine. But if a real Boolean value is needed, it can be converted manually.
$DebugMode = [bool]::Parse($Data.Debug)
When I would use it
I would use ConvertFrom-StringData when the input is simple key value data and not already JSON, XML, or CSV.
It is useful when the data looks like this:
Profile=PowerUser
Name=Ahmed
Debug=True
Logging=True
Or when it can easily be changed into that format.
If the data is JSON, I would use ConvertFrom-Json. If it is CSV, I would use ConvertFrom-Csv or Import-Csv. But for simple Key=Value text, ConvertFrom-StringData is a very clean option.
Conclusion
ConvertFrom-StringData is not a big or complicated cmdlet, but it solves a problem.
Sometimes data is available, but only as raw text. PowerShell cannot work with that text properly until it is parsed. With ConvertFrom-StringData, simple key value strings can be converted into a hashtable, and after that the values can be used like normal PowerShell data.
For me, this was a nice reminder that there is always something new to learn. Even after years with PowerShell, a small cmdlet can appear and make you think, I could have used this before.