Conversor de PowerShell a XML
Pega objetos PowerShell o hashtables. Obtén XML limpio.
Qué hace esta herramienta
Si alguna vez has tenido que meter una configuración de PowerShell en un archivo XML — para un recurso DSC, una tarea de MSBuild, una plantilla app.config o un fixture de SoapUI — ya conoces el drama. Acabas ejecutando ConvertTo-Xml y recortando a mano los feos envoltorios <Object Type="...">, o tirando de Export-CliXml y recibiendo un payload CLIXML que nadie fuera de PowerShell sabe leer. Pega aquí el PowerShell y recibes XML bien formado que cualquier parser XML normal acepta — sin ruido de <Property Name="...">, sin etiquetas CLIXML de tipo, solo los datos.
Entiende las formas que realmente usa el código PowerShell. Un PSCustomObject se convierte en un elemento con elementos hijos nombrados según cada propiedad. Un hashtable @{ Name = "Ava" } se comporta igual. Un array creado con @(...) se convierte en un elemento contenedor con un hijo por cada ítem. Los valores anidados [PSCustomObject] dentro de un objeto padre aparecen como elementos anidados, no como blobs convertidos a string. Los booleanos ($true, $false) y los números mantienen sus tipos nativos en la salida; $null se convierte en un elemento vacío autocerrado para que la forma siga siendo predecible en vez de perder el campo en silencio.
Algunas peculiaridades del lenguaje se manejan como un humano esperaría. Las cadenas entre comillas dobles pasan sin expandir marcadores de interpolación como $var — preservamos lo que pegaste tal cual. Los here-strings (@" ... "@) se tratan como contenido de texto multilínea. Las fechas escritas como [datetime]"2026-04-21" se emiten como cadenas ISO-8601. Los nombres de propiedad con guiones reciben un nombre de elemento seguro (PowerShell te deja escribir "User-Agent" = "..." en un hashtable, que es ilegal como etiqueta XML en crudo — lo convertimos para que la salida siga siendo parseable). La forma se mantiene fiel a la entrada; el XML queda usable.
Cómo usarla
Tres pasos. Funciona igual tanto si pegas un solo hashtable como si pegas un script de configuración completo.
Pega tu PowerShell (o prueba el ejemplo)
Suelta tu script en el editor de la izquierda. Un único [PSCustomObject]@{...}, un hashtable anidado, un array @(...) de objetos, o un bloque de configuración entero — todo vale. Pulsa Cargar ejemplo si quieres un payload realista de un pedido para empezar.
No hace falta que quites comentarios, elimines bloques param() ni limpies el script antes. Pega lo que tengas. Leeremos solo los literales de objeto e ignoraremos el resto.
Pulsa Convertir
Pulsa el botón verde Convertir. La herramienta recorre la estructura PowerShell, preserva cada propiedad y cada ítem del array, y construye el XML en una sola pasada. Verás un breve indicador de carga mientras se ejecuta.
Copia el XML
El panel de la derecha se llena con XML indentado que cualquier parser estándar aceptará. Mételo en tu configuración DSC, en tu archivo MSBuild o donde lo necesites.
Cuándo viene bien de verdad
Escribir payloads de configuración DSC
Tienes un hashtable de PowerShell que describe la configuración de un nodo y necesitas una versión XML para un consumidor no-DSC o para documentación. Pega, convierte, listo — sin tener que peinar la salida de ConvertTo-Xml.
Archivos de variables de pipeline de Azure DevOps
A veces los pipelines esperan un grupo de variables como XML. Pega el hashtable de PowerShell que ya mantienes y recibe XML que entra directo en <code>variables.xml</code> — sin editar a mano.
Exportar payloads del Visor de eventos de Windows
Cuando construyes un registro de evento en PowerShell como un PSCustomObject y tienes que mandarlo a un pipeline de logging que ingiere XML, esto te ahorra escribir un serializador a medida. La forma anidada se mantiene intacta.
Plantillas base de app.config / web.config
Convierte un hashtable de settings de PowerShell en un <code>app.config</code> inicial que puedes editar a mano. Más rápido que escribirlo de cero y mantiene las claves sincronizadas con tus scripts.
Preguntas frecuentes
¿En qué se diferencia esto de ejecutar ConvertTo-Xml sobre mi objeto?
ConvertTo-Xml envuelve todo en un sobre genérico <Object Type="..."><Property Name="..."> — legible desde PowerShell, horrible en cualquier otro sitio. Esta herramienta emite los nombres de las propiedades como elementos XML reales, así que la salida se parece al XML que escribiría una persona a mano. Sin la indirección <Property Name>, sin atributos de tipo estorbando.
¿Produce CLIXML como Export-CliXml?
No — y eso es precisamente el punto. Export-CliXml produce CLIXML, un formato específico de PowerShell pensado para volver a PowerShell. Si tienes que entregar el XML a un sistema que no es PowerShell (un servicio Java, un lector de configuración, un pipeline validado con XSD), CLIXML no sirve. Esta herramienta te da XML plano y legible.
¿Puedo pegar un archivo .ps1 entero o solo literales de objeto?
Pega lo que tengas. Si el script contiene un único literal de objeto asignado a una variable, eso es lo que sale. Si hay varios hashtables o PSCustomObjects de nivel superior, cada uno se emite como su propio elemento. Los cuerpos de funciones, bloques param(), imports y líneas Write-Host se ignoran — solo importan las formas de los datos.
¿Cómo se manejan $null, $true, $false y arrays vacíos?
$null se convierte en un elemento vacío autocerrado para que la forma siga siendo consistente (en vez de que el campo desaparezca). $true y $false se convierten en las cadenas literales true y false. Un @() vacío se convierte en un elemento contenedor vacío. Así las herramientas downstream ven siempre la misma estructura aunque algunos campos estén sin valor.
¿Y las claves de hashtable que no son nombres XML válidos — guiones, espacios, que empiezan por número?
Claves como "User-Agent" o "2024-Q1" son legales en un hashtable de PowerShell pero ilegales como nombres de elemento XML en crudo. Las reescribimos a una forma segura (guardando el original como atributo cuando tiene sentido) para que la salida siga siendo parseable. Si eso importa para tu consumidor, revisa primero las etiquetas generadas.
¿Se guarda mi código?
El código se manda al backend para la conversión y no se persiste — no registramos el payload. Si el script es realmente sensible (credenciales de producción, rutas internas), límpialo antes de pegarlo, igual que harías con cualquier herramienta online.
Otras herramientas que quizá necesites
PowerShell a XML es una pieza del puzle. Estas herramientas combinan bien con ella: