Conversor de JSON a XML
¿Qué es la conversión de JSON a XML?
JSON to XML convierte datos JSON estructurados en marcado XML para que la información pueda moverse entre sistemas que esperan formatos de intercambio distintos. JSON usa objetos, arrays, números, cadenas, booleanos y null, mientras que XML usa elementos, atributos, nodos de texto y espacios de nombres. Por eso la conversión no siempre es uno a uno: nombres de arrays, mapeo de atributos, valores vacíos, caracteres especiales y orden deben representarse con criterio. La herramienta es útil en integraciones cercanas a SOAP, sistemas empresariales antiguos, migración de datos, payloads de prueba y documentación. En producción debe validarse contra XSD, contrato API o formato del socio.
Cómo usar
Cómo usar
- Pega o introduce datos JSON en el panel izquierdo
- Si lo deseas, personaliza el nombre del elemento raíz
- Selecciona el tamaño de sangría (2 espacios, 4 espacios o Tab)
- El XML convertido se muestra a la derecha con resaltado de sintaxis
- Haz clic en Copy o Download para guardar el resultado
Verificaciones de conversión
- Revisa los arrays, valores nulos y campos similares a atributos después de la conversión; JSON y XML no modelan los datos de la misma manera.
- Elige un nombre de elemento raíz estable antes de copiar el XML en una solicitud de API, archivo de configuración o fixture de prueba.
Casos de uso
Principio técnico
JSON (RFC 8259, derivado de los literales de objeto de JavaScript) y XML (W3C XML 1.0, originalmente de 1998) son ambos formatos de serialización con estructura de árbol, pero sus gramáticas difieren. JSON tiene objetos (mapas de clave/valor con claves de tipo cadena), arrays (listas ordenadas) y seis tipos escalares (cadena, número, booleano, null y los tipos estructurales). XML tiene elementos (pares de etiqueta de apertura/cierre que encierran texto o elementos hijos), atributos (pares de nombre/valor en la etiqueta de apertura), nodos de texto, comentarios, instrucciones de procesamiento y secciones CDATA. La conversión es una transformación estructural sin respuesta canónica: toda convención existente (BadgerFish, JSONML, codificación SOAP/RPC, esquema plano de OOXML, formato linkbase de XBRL) es una regla distinta para la misma entrada. La decisión de 'atributo frente a elemento hijo' es la ambigüedad central. Los únicos metadatos de JSON residen en el nombre de la clave, por lo que un objeto JSON como `{"id": "42", "name": "Alice", "admin": true}` no indica qué claves son 'metadatos' y cuáles son 'datos'. Tres convenciones comunes: (1) la predeterminada de la página: los escalares se convierten en contenido de texto, mientras que la clave JSON original de un conjunto de atributos anidados (reconocido por ser un objeto no-array cuyos únicos valores son escalares) se convierte en un atributo XML con prefijo `@` (convención BadgerFish). (2) JSONML: cada objeto JSON se convierte en un elemento con la clave 'tag' como nombre del elemento, la clave 'attr' como mapa de atributos y las entradas hijas como hijos. (3) oData / Atom: los objetos JSON se convierten en elementos y los arrays se insertan en línea con un elemento contenedor. Cada regla es demostrablemente correcta para algún consumidor downstream y demostrablemente incorrecta para otro, razón por la cual ningún convertidor a XML ha sido universalmente aceptado. Los arrays son la segunda ambigüedad. Los arrays JSON son listas ordenadas; XML no tiene un tipo nativo de array. Las tres soluciones estándar: (a) repetir elementos hijos (la predeterminada de la página, convención OOXML/SOAP): `[1, 2, 3]` → `<root><item>1</item><item>2</item><item>3</item></root>`. (b) Envolver en un contenedor: `<root><items><item>1</item>...</items></root>`. (c) Codificar el array como una cadena delimitada y documentar el delimitador (CSV en XML, solo cuando el consumidor lo analiza). Cada una es correcta para un XSD downstream diferente; el paso de conversión necesita saber cuál emitir. Los nombres de elementos XML deben ser tokens QName válidos (XML 1.0 §2.3 / XML Namespaces 1.0 §3): comenzar con una letra, guion bajo o dos puntos, seguido de letras, dígitos, guiones, guiones bajos, puntos o dos puntos. JSON permite claves como '123' o 'first name' que violan esto: el convertidor debe renombrarlas (slugificar a first_name, prefijar con _) o fallar. El contenido de cadena de JSON también necesita escape de entidades en el texto de elementos y valores de atributos: `&` → `&`, `<` → `<`, `>` → `>` (solo obligatorio en texto en XML antiguo, pero siempre seguro), `"` → `"` y `'` → `'` en atributos, y cualquier carácter fuera del rango de la codificación como `&#xHHHH;`. Las cinco entidades integradas más las referencias numéricas a caracteres son obligatorias en XML; las entidades con nombre adicionales de HTML (` `, `©`) no están definidas en XML plano y necesitan un DOCTYPE explícito si se usan. El documento de salida también necesita un prólogo y declaraciones de namespace: `<?xml version="1.0" encoding="UTF-8"?>` primero, luego las declaraciones xmlns. Si el sistema objetivo usa namespaces (SOAP usa `http://www.w3.org/2003/05/soap-envelope`, XSLT usa `http://www.w3.org/1999/XSL/Transform`), los mapeos de prefijos se añaden como atributos `xmlns:prefix="uri"` en un elemento raíz. JSON no tiene concepto de namespace, por lo que la elección de qué URI usar es específica del proyecto. Para valores vacíos, null en JSON se expresa normalmente como `<key xsi:nil="true"/>` (convención de XML Schema) o `<key></key>` (convención de elemento vacío). El convertidor elige una; la respuesta correcta depende de la validación XSD del consumidor. Para la dirección inversa (XML → JSON), las mismas ambigüedades a la inversa: los atributos se mapean a una clave `@attributes` en BadgerFish, CDATA se mapea a una clave `$` o `#text`, los elementos de contenido mixto (texto + elementos hijos intercalados) no tienen una representación JSON limpia y normalmente se emiten como una concatenación de cadenas. Los convertidores del mundo real siempre exponen opciones de 'clave de atributo', 'clave de texto', 'envoltorio de array': no hay forma de evitarlo.
- JSON (RFC 8259) y XML (W3C XML 1.0, 1998) son ambos formatos de serialización con estructura de árbol; la conversión es una transformación estructural sin respuesta canónica, por lo que múltiples convenciones (BadgerFish, JSONML, SOAP, OOXML) coexisten para la misma entrada.
- Atributo frente a elemento hijo: los escalares por defecto son contenido de texto; los objetos de conjunto de atributos anidados (solo valores escalares) se convierten en atributos con prefijo @ (BadgerFish). JSONML usa claves 'tag' / 'attr'. oData / Atom usa elementos contenedores.
- Arrays: la predeterminada de la página repite elementos hijos (convención OOXML/SOAP). Alternativas: envolver en un elemento contenedor o codificar como una cadena delimitada. El orden del array JSON se preserva en la salida XML.
- Reglas de nombres de elementos XML: deben comenzar con una letra, guion bajo o dos puntos, seguido de letras/dígitos/guiones/guiones bajos/puntos/dos puntos (XML 1.0 §2.3). Las claves JSON como '123' o 'first name' son nombres XML inválidos y deben slugificarse o rechazarse.
- Escape de entidades: `&` → `&`, `<` → `<`, `>` → `>`, `"` → `"`, `'` → `'`, cualquier otro carácter de codificación como `&#xHHHH;`. Las 5 entidades integradas son obligatorias; los extras de HTML como ` ` necesitan un DOCTYPE explícito.
- Prólogo del documento: `<?xml version="1.0" encoding="UTF-8"?>` es la primera línea estándar. Las declaraciones xmlns en el elemento raíz declaran prefijos de namespace; JSON no tiene concepto de namespace, por lo que el convertidor elige por proyecto.
- null en JSON → XML: bien `<key xsi:nil="true"/>` (convención de XML Schema) o `<key></key>` (elemento vacío). La elección debe coincidir con el XSD del consumidor, de lo contrario la validación falla.
- La dirección inversa XML → JSON tiene las mismas ambigüedades: las secciones CDATA se convierten en claves `$` o `#text` (BadgerFish), los elementos de contenido mixto (texto + elementos hijos intercalados) no tienen una forma JSON limpia y normalmente se concatenan en una cadena.
Ejemplos
Objeto -> Elemento
{"name": "Alice"}
->
<root>
<name>Alice</name>
</root>Array -> Elementos
[1, 2, 3]
->
<root>
<item>1</item>
<item>2</item>
<item>3</item>
</root>Estructura anidada
{"user": {"name": "Alice", "age": 25}}
->
<root>
<user>
<name>Alice</name>
<age>25</age>
</user>
</root>Preguntas frecuentes
¿Cómo mapea el conversor JSON a XML?
Cada objeto JSON se convierte en un elemento XML. Las claves del objeto se convierten en nombres de elementos hijos; los valores primitivos se convierten en texto del elemento. Los arrays repiten el elemento padre varias veces. Los caracteres especiales en el texto se escapan (& → &, < → <).
¿Por qué la conversión JSON a XML no siempre es sin pérdidas?
JSON tiene tipos explícitos number/boolean/null; XML solo tiene texto. JSON permite claves con espacios o caracteres especiales; los nombres de elementos XML no. Los arrays en el nivel superior no tienen un equivalente XML obvio. La página usa heurísticas (elemento envoltorio 'root', claves inválidas saneadas) para salvar estas diferencias.
¿Cómo se representan los valores de array en XML?
Cada elemento del array se convierte en un elemento hermano con el mismo nombre. [{a:1},{a:2}] → <items><item><a>1</a></item><item><a>2</a></item></items>. La envoltura es configurable; algunas páginas te permiten elegir el nombre del elemento singular explícitamente.
¿Y las claves JSON que no son nombres XML válidos?
Los nombres de elementos XML no pueden empezar por un dígito, contener espacios ni incluir ciertos símbolos. La página los sanea reemplazando caracteres inválidos por guiones bajos o envolviéndolos en CDATA. El resultado es XML válido, pero el ida y vuelta no es exacto.
¿Se conservan los null y los booleanos de JSON?
null se convierte en un elemento vacío o se omite el elemento, según los ajustes. true/false se convierten en el texto literal 'true' o 'false'. No hay un estándar XML para estos tipos: los parsers posteriores deben aplicar su propia interpretación de tipos.
¿Puedo añadir atributos XML?
JSON no tiene un concepto de atributo, así que el generador emite todo como elementos por defecto. Algunos conversores usan un prefijo de clave especial (por ejemplo, '@id') para indicar atributos: revisa las opciones de la página si la salida de atributos importa para tu esquema XML.
¿La conversión es local?
Sí. El análisis JSON y la generación XML ocurren en tu navegador. Las entradas no se suben.