Convertidor XML ⇄ JSON
XML ↔ JSON bidireccional con manejo de atributos, preservación CDATA, BOM, fin de línea e indentación
Entrada
Salida
Convertidor XML ⇄ JSON
XML ↔ JSON bidireccional con manejo de atributos, preservación CDATA, BOM, fin de línea e indentación
Características
- Modo auto-detección olfatea si el texto pegado es XML o JSON y ejecuta la conversión en la dirección opuesta — pegue cualquier lado sin cambiar el modo manualmente
- Dos estrategias de atributo: modo Prefijo emite atributos XML con prefijo configurable (por defecto `@`) como claves JSON hermanas; modo Objeto los recoge en un objeto `$` separado, así texto de elemento y atributos no colisionan
- Manejo CDATA y nodo de texto: con "Tratar CDATA/Texto como #text" activado, el contenido textual de elemento se pliega en una propiedad `#text`; el contenido mixto sobrevive al round-trip JSON; desactivado preserva la distinción estructural
- Conmutador pretty-print con indentación seleccionable (2 / 4 / 8 espacios) para salida JSON y XML — activado para lectura humana, desactivado para transporte compacto
- Control de fin de línea (LF vs CRLF) para compatibilidad Unix vs Windows, más conmutador UTF-8 BOM opcional para sistemas que requieren el byte-order mark
- Prefijo de atributo configurable para coincidir con convenciones aguas abajo: `@` (por defecto), `_`, `xml:` o cualquier otra cadena — mantiene la salida convertida compatible directamente con su pipeline existente
- Copiar y Descargar (`converted.txt`) de un clic para la salida; errores de conversión surgen en línea con el mensaje del parser subyacente — sabe si el XML era malformado o el JSON no era representable como XML
- Puramente del lado cliente: parseo vía DOMParser para XML y JSON.parse para JSON. Sin llamadas de red, funciona sin conexión tras cachear la página
Cómo usar
- Pegue su XML o JSON en el panel Entrada. Con Modo en Auto-detectar, el convertidor olfatea el formato automáticamente.
- Ajuste el conmutador Pretty y el tamaño de Indentación para controlar el formato; conmute Fin de línea entre LF y CRLF según requiera su herramienta aguas abajo.
- Abra Ajustes avanzados para escoger Modo de atributo (Prefijo u Objeto), establecer Prefijo de atributo y conmutar CDATA/Texto-#text.
- Pulse Convertir. El panel Salida muestra el resultado; la conversión corre en su navegador vía DOMParser + JSON.parse.
- Use Copiar para el portapapeles, o Descargar para guardar como `converted.txt`.
- Si el parseo falla, una fila de error en línea muestra el mensaje subyacente — corrija la entrada y vuelva a convertir.
Consejos y buenas prácticas
- Cuando depure una carga XML de un servicio SOAP, Auto-detección + modo atributo Objeto + CDATA-#text da la vista JSON más limpia.
- Establezca Fin de línea a CRLF y habilite el BOM al generar salida destinada a herramientas Windows legacy.
- Cambie el Prefijo de atributo de `@` a `_` si sus consumidores JSON rechazan claves que empiezan por `@` (algunos parsers derivados de YAML lo hacen).
- Si la salida JSON-a-XML pone los elementos en orden incorrecto, reinserte sus claves de nivel superior en el JSON fuente en el orden que quiera emitirlas.
- Combine con JSON Formatter cuando quiera inspeccionar o transformar más el JSON convertido; XML Formatter en el lado XML.
Preguntas frecuentes
¿Cómo cambia el Modo de atributo la salida JSON?
En modo Prefijo, los atributos XML aparecen como claves hermanas con el prefijo configurado — `<user id="42"/>` se vuelve `{ "user": { "@id": "42" } }`. En modo Objeto, los atributos se recogen bajo una única clave `$`, así contenido de elemento y de atributo no comparten espacio de nombres. Elija Prefijo cuando los consumidores esperen claves planas; Objeto cuando necesite round-tripear atributos a XML sin ambigüedad.
¿Para qué es CDATA-como-#text?
XML tiene dos formas de portar texto — `<a>plain</a>` y `<a><![CDATA[plain]]></a>`. Con la opción activada, ambas formas colapsan en una clave `#text` en JSON; contenido mixto como `<p>Hola <b>mundo</b></p>` sobrevive al round-trip. Desactivado preserva la distinción estructural; útil cuando los marcadores CDATA del documento original son semánticamente significativos (ej. scripts embebidos).
¿Por qué importa el conmutador BOM?
Algunas herramientas Windows (Excel, PowerShell antiguo, .NET TextReader sin codificación explícita) esperan un BOM UTF-8 (`EF BB BF`) al inicio para detectar codificación. Herramientas web modernas y pipelines Unix tratan el BOM como ruido normalmente. Active el conmutador para herramienta Windows consciente de BOM, desactive para todo lo demás.
¿Por qué LF vs CRLF?
Herramientas Windows y formatos Microsoft antiguos esperan `\r\n` (CRLF); Unix/Linux/macOS usan `\n` (LF) por defecto. Git suele normalizar ambos, pero artefactos que evitan git (descargas, pegado en Notepad, salidas de build) necesitan la elección explícita. El parser de Auto-detección ignora finales de línea; este control solo afecta la salida.
¿Sobreviven los namespaces a la conversión?
Los nombres de elemento y atributo con prefijo de namespace round-tripean como cadenas literales (ej. `xmlns:soap` se vuelve la clave `@xmlns:soap`). El convertidor no resuelve namespaces contra URIs — si su pipeline aguas abajo necesita resolución, hágalo aparte. El round-trip a XML preserva los prefijos iniciales.
¿Qué pasa con elementos vacíos?
Un elemento XML vacío `<a/>` se vuelve `{ "a": null }` en JSON (o `{ "a": "" }` si era `<a></a>` con texto vacío y CDATA-#text activado). Yendo de JSON a XML, un valor `null` emite un elemento autocerrado. El round-trip es estable mientras no conmute el ajuste CDATA-#text entre las dos direcciones.
¿Por qué mi salida JSON-a-XML tiene claves ordenadas?
Los elementos XML tienen orden definido; los objetos JavaScript preservan el orden de inserción para claves string, así el convertidor escribe los elementos en el orden en que sus claves aparecieron en JSON. Si el JSON vino de un round-trip JSON.parse, el orden coincide con la fuente; construido programáticamente, controle el orden insertando claves en la secuencia deseada.
¿Es seguro convertir documentos grandes en esta pestaña?
Documentos de mediana escala (megabytes) convierten en bien menos de un segundo. Muy grandes (>10 MB) funcionan pero fijan el hilo UI durante el parseo; para esa carga, ejecute la misma lógica en un Web Worker o script de build. El servicio de conversión es el mismo en ambos contextos.