PowerShell to XML Converter
Paste PowerShell objects or hashtables. Get clean XML back.
What this tool does
If you have ever needed to ship a PowerShell config into an XML file — for a DSC resource, an MSBuild task, an app.config template, or a SoapUI fixture — you already know the drill. You end up either running ConvertTo-Xml and trimming the ugly <Object Type="..."> wrappers by hand, or reaching for Export-CliXml and getting back a CLIXML payload no one outside of PowerShell knows how to read. Paste the PowerShell here and you get back well-formed XML that a normal XML parser will accept — no <Property Name="..."> noise, no CLIXML type tags, just the data.
It understands the shapes PowerShell code actually uses. A PSCustomObject becomes an element with child elements named after each property. A hashtable @{ Name = "Ava" } behaves the same way. An array created with @(...) turns into a container element with one child per item. Nested [PSCustomObject] values inside a parent object come through as nested elements, not stringified blobs. Booleans ($true, $false) and numbers keep their native types in the output; $null becomes an empty self-closing element so the shape stays predictable rather than silently dropping the field.
Some quirks of the language are handled the way a human would expect. Double-quoted strings come through without interpolation markers like $var expanded — we preserve what you pasted literally. Here-strings (@" ... "@) are treated as multi-line text content. Dates written as [datetime]"2026-04-21" are emitted as ISO-8601 strings. Property names that contain dashes get a safe element name (PowerShell lets you write "User-Agent" = "..." in a hashtable, which is illegal as a raw XML tag — we convert it so the output still parses). The shape stays faithful to the input; the XML stays usable.
How to use it
Three steps. Works the same whether you paste one hashtable or a whole configuration script.
Paste your PowerShell (or try the sample)
Drop your script into the left editor. A single [PSCustomObject]@{...}, a nested hashtable, an @(...) array of objects, or a full config block — all fine. Click Load Sample if you want a realistic Order payload to play with first.
You do not need to strip comments, remove param() blocks, or clean the script up beforehand. Paste what you have. We will read only the object literals and ignore the rest.
Hit Convert
Click the green Convert button. The tool walks the PowerShell structure, preserves every property and array item, and builds the XML in one pass. You will see a short loading indicator while it runs.
Copy the XML
The right panel fills with indented XML that any standards-compliant parser will accept. Drop it into your DSC configuration, your MSBuild file, or wherever else you need it.
When this actually comes in handy
Authoring DSC configuration payloads
You have a PowerShell hashtable that describes a node configuration and you need an XML version of it for a non-DSC consumer or for documentation. Paste, convert, done — no more babysitting ConvertTo-Xml output.
Azure DevOps pipeline variable files
Pipelines sometimes expect a variable group as XML. Paste the PowerShell hashtable you already maintain, get back XML that drops straight into <code>variables.xml</code> — no hand-editing.
Exporting Windows event-log payloads
When you build an event record in PowerShell as a PSCustomObject and need to feed it to a logging pipeline that ingests XML, this saves you from writing a custom serializer. The nested shape comes through unchanged.
app.config / web.config seed templates
Turn a PowerShell settings hashtable into a starting-point <code>app.config</code> you can edit by hand. Faster than generating one from scratch and keeps the keys in sync with your scripts.
Common questions
How is this different from running ConvertTo-Xml on my object?
ConvertTo-Xml wraps everything in a generic <Object Type="..."><Property Name="..."> envelope — readable by PowerShell, ugly everywhere else. This tool emits the property names as actual XML elements, so the output looks the way a person would write XML by hand. No <Property Name> indirection, no type attribute clutter.
Does it produce CLIXML like Export-CliXml does?
No — and that is the point. Export-CliXml outputs CLIXML, which is a PowerShell-specific format designed for round-tripping back into PowerShell. If you need to hand the XML to a system that is not PowerShell (a Java service, a config reader, an XSD-validated pipeline), CLIXML is the wrong shape. This tool gives you plain, readable XML instead.
Can I paste a full .ps1 file or just object literals?
Paste whatever you have. If the script contains a single object literal assigned to a variable, that is what comes through. If there are multiple top-level hashtables or PSCustomObjects, each one is emitted as its own element. Function bodies, param() blocks, imports, and Write-Host lines are ignored — only the data shapes matter.
How are $null, $true, $false, and empty arrays handled?
$null becomes an empty self-closing element so the shape stays consistent (instead of the field disappearing). $true and $false become the literal strings true and false. An empty @() becomes an empty container element. That way downstream tooling always sees the same structure even when some fields are unset.
What about hashtable keys that are not valid XML names — dashes, spaces, numbers first?
Keys like "User-Agent" or "2024-Q1" are legal in a PowerShell hashtable but illegal as raw XML element names. We rewrite them to a safe form (keeping the original as an attribute where that makes sense) so the output still parses. If that matters for your consumer, look over the generated tags first.
Is my code stored?
The code is sent to the backend for conversion and is not persisted — we do not log the payload. If the script is genuinely sensitive (production credentials, internal paths), scrub it before pasting, the same way you would with any online tool.
Other tools you may need
PowerShell to XML is one piece of the puzzle. These tools pair well with it: