Conversor de JSON a XML

JSON y XML, dos formatos, dos eras

XML (Extensible Markup Language) fue estandarizado por el W3C como Recomendación el 10 de febrero de 1998, la spec W3C XML 1.0, editada por Tim Bray, Jean Paoli y C.M. Sperberg-McQueen. XML surgió de SGML (el más antiguo «Standard Generalised Markup Language», ISO 8879:1986) eliminando las características más complejas y produciendo algo que la web podría usar realísticamente. Durante aproximadamente la primera década del siglo XXI, XML fue el formato presunto para cualquier intercambio de datos estructurados, servicios web SOAP, feeds RSS (RSS 2.0, Dave Winer, 2002), Atom (RFC 4287, 2005), formatos Open XML de Microsoft Office (.docx/.xlsx/.pptx, ISO/IEC 29500:2008), layouts XML de Android, archivos de propiedades Java, configuración en casi todos los frameworks de servidor. Las fortalezas de XML son los espacios de nombres, atributos, contenido mixto (texto y elementos hijos entrelazados) y un rico ecosistema de esquemas (DTD, XML Schema 1.1, Relax NG). Su debilidad es la verbosidad, cada valor lleva una etiqueta de apertura y cierre.

JSON (JavaScript Object Notation) fue especificado por Douglas Crockford en 2001, el sitio json.org y su ensayo original «JSON: The Fat-Free Alternative to XML». JSON es intencionalmente un subconjunto de la sintaxis literal de objetos de JavaScript: objetos, arrays, strings, números, true/false/null. Estandarizado como RFC 4627 en julio de 2006, refinado como RFC 7159 (marzo de 2014) y RFC 8259 (diciembre de 2017, estándar STD 90 actual, también publicado por ECMA como ECMA-404). La toma por JSON de las APIs web a XML ocurrió aproximadamente en 2008-2014, el calendario coincide con el auge de las single-page apps y la era de las APIs móviles. Hoy casi cada API pública se documenta como JSON; XML sobrevive principalmente en integración empresarial, formatos de documento, archivos de configuración y formatos de feeds. Los dos formatos siguen en uso activo porque codifican bien cosas diferentes: JSON es adecuado para datos estructurados con tipos simples y forma predecible; XML es adecuado para documentos con contenido mixto, atributos, espacios de nombres y esquemas rigurosos.

Cuándo realmente necesitas convertir JSON a XML

• Llamar a un servicio web SOAP desde un cliente solo-JSON. SOAP es XML por diseño (el sobre SOAP, la descripción de servicio WSDL, los esquemas XSD). Si tienes datos en forma JSON y necesitas construir un cuerpo de petición SOAP, JSON-a-XML es el puente. Común en integración empresarial cuando microservicios modernos necesitan hablar con endpoints SOAP legacy (banca, gobierno, seguros, sistemas de intercambio sanitario).
• Generar documentos Office Open XML a partir de datos JSON. Los formatos .docx, .xlsx y .pptx son archivos ZIP de archivos XML. Para generar o modificar programáticamente documentos Office a partir de datos respaldados por JSON, la conversión JSON-a-XML ocurre en la frontera entre la capa de datos de tu aplicación y la biblioteca de generación de documentos.
• Producir un feed RSS o Atom a partir de contenido JSON. Blogs, sitios de noticias y plataformas de podcasts emiten feeds RSS/Atom para sindicación. Si tu CMS almacena los artículos como JSON, el paso de generación de feeds convierte las entradas JSON al formato XML que el ecosistema de lectores de feeds espera.
• Generar archivos de configuración XML para aplicaciones legacy. Muchas aplicaciones empresariales más antiguas (servidores de aplicación Java, archivos de configuración .NET, contexto de aplicación Spring XML) consumen su configuración como XML. El tooling moderno de infraestructura-como-código suele trabajar en YAML o JSON, así que una conversión JSON-a-XML se sitúa en el pipeline de despliegue.
• Alimentar una transformación XSLT. XSLT (XSL Transformations, especificación de Michael Kay, Recomendación W3C) es el lenguaje estándar de transformación XML y consume entrada XML. Si tus datos parten de JSON y tu motor de reporting está basado en XSLT, la conversión ocurre en la frontera de entrada.
• Generar archivos de recursos Android. Los strings.xml, colors.xml, dimens.xml y archivos de layout de Android son XML. Las pipelines de localización que almacenan las cadenas en JSON para facilidad de edición convierten a XML en tiempo de build.

El mapeo de conversión, dónde sobrevive la información y dónde se pierde

JSON y XML tienen primitivas estructurales diferentes, así que cualquier conversión debe tomar decisiones. El mapeo JSON-a-XML estándar que la mayoría de los conversores (este incluido) siguen:

• Los objetos JSON se convierten en elementos XML. Cada clave se convierte en un elemento hijo con la clave como nombre de etiqueta. {"name": "Alice"} se convierte en <name>Alice</name>.
• Los arrays JSON se convierten en elementos hijos repetidos. {"items": [1, 2, 3]} se convierte en tres hijos <item>1</item><item>2</item><item>3</item> dentro del envoltorio <items>. (Diferentes conversores usan diferentes convenciones para el nombre del elemento de array; algunos usan el nombre del padre en singular, otros usan un <item> fijo.)
• Strings, números, booleanos se convierten en contenido textual del elemento. La información de tipo no se preserva, XML trata todo el texto como datos de carácter, así que un viaje de ida y vuelta XML → parse → serializar de vuelta a JSON emitiría los números como cadenas entrecomilladas a menos que el consumidor aplique inferencia de tipos.
• null se convierte en un elemento vacío auto-cerrante. {"middle_name": null} se convierte en <middle_name/>. Algunos conversores usan xsi:nil="true" en su lugar.
• El elemento raíz envuelve todo. JSON permite un array o escalar de nivel superior; XML requiere exactamente un elemento raíz. El envoltorio <root> (configurable aquí) es la solución convencional.

Información perdida en la conversión: la distinción de JSON entre números y strings, la distinción de JSON entre true/false y strings «true»/«false», la distinción de JSON entre array y objeto (cuando un array se convierte en elementos repetidos no puedes saber solo a partir del XML si la fuente tenía un array de un elemento o un valor único). Información potencialmente ganada pero no usada por conversores simples: atributos XML (un objeto JSON podría mapear las claves a atributos en lugar de elementos hijos), espacios de nombres XML (JSON no tiene nada equivalente), secciones CDATA (para incrustar texto con caracteres especiales XML). Para una conversión JSON-a-XML segura para ida y vuelta que preserve la información de tipo, la convención BadgerFish o la convención Parker codifican los tipos JSON como atributos XML con espacios de nombres, esta herramienta produce la forma más simple y legible en lugar de la forma segura para ida y vuelta.

Las restricciones de nombre de etiqueta XML que las claves JSON no tienen

Las claves de objeto JSON son cadenas arbitrarias, cualquier Unicode está permitido. Los nombres de elementos XML están mucho más restringidos: deben empezar con una letra o un guion bajo (no un dígito, guion ni punto), pueden contener letras, dígitos, guiones, guiones bajos y puntos (sin espacios, sin la mayoría de la puntuación), distinguen mayúsculas y minúsculas, y no pueden empezar con el prefijo reservado xml en ninguna combinación de mayúsculas/minúsculas. Las claves JSON con espacios ("first name": "Alice"), claves que empiezan con dígitos ("3rd_choice"), o claves con caracteres especiales ("@type", "$value") no pueden usarse como nombres de elementos XML directamente. La mayoría de los conversores (este incluido) deforman silenciosamente los caracteres inválidos, reemplazan espacios por guiones bajos, anteponen un guion bajo a las claves que empiezan con dígitos, eliminan la mayoría de la puntuación. Sé consciente de esto al hacer ida y vuelta: un documento JSON con claves no-seguras-para-XML no hará un viaje de ida y vuelta idénticamente a través de XML.

Donde XML aún reina en 2026

XML no está en retirada en 2026, solo se ha asentado en nichos específicos. Formatos de documento: Office Open XML (Microsoft Office), OpenDocument (LibreOffice), ebooks EPUB, SVG (Recomendación W3C 4 de septiembre de 2001), MathML, XHTML. Configuración: servidores de aplicación Java, contextos Spring XML, POM de Maven, recursos XML de Android, archivos app.config y web.config de .NET. Feeds: RSS 2.0, Atom 1.0 (RFC 4287), feeds de podcasts (las extensiones RSS de iTunes). Intercambio sanitario y gubernamental: HL7 v3, FHIR (que ahora ofrece JSON como alternativa pero la forma XML sigue en uso intensivo), DocBook, NewsML, ISO 20022 bancaria. Organismos de estándares: casi todo ejemplo de especificación IETF y W3C usa XML. La verbosidad de XML es una característica en esos dominios: es autodescriptivo, validar contra un esquema está bien establecido, y las transformaciones XSLT entre dialectos XML son una caja de herramientas madura. El formato no se va a ningún lado; la conversión JSON-a-XML es el puente entre el tooling de datos moderno y estos sistemas XML-nativos establecidos.

Privacidad: conversión solo en el navegador

El JSON pegado en un conversor a menudo contiene datos de producción reales, respuestas de API con identificadores de usuario, IDs internos de entidad que revelan la taxonomía empresarial, valores de configuración que incluyen URLs de endpoints y feature flags, tokens, contenido borrador no publicado todavía. Los conversores del lado del servidor toman una copia de cada entrada en sus logs. Este conversor parsea tu JSON con el JSON.parse() integrado del navegador, recorre el árbol de objetos resultante en JavaScript y emite XML como una cadena, todo dentro de tu pestaña del navegador. Verifica en la pestaña Red de DevTools mientras haces clic en Convert (no se dispara ninguna petición), o pon la página sin conexión (modo avión) tras cargarla y el conversor sigue funcionando. Seguro para respuestas de API de producción, configuración interna, contenido borrador, o cualquier JSON que no quisieras ver copiado en el disco duro de un extraño.

Preguntas frecuentes

¿Cómo se convierten los arrays JSON?

Cada elemento del array se convierte en un elemento hijo separado. {"colors": ["red", "blue"]} se convierte en <colors><item>red</item><item>blue</item></colors>. El nombre de elemento convencional para entradas de array sin nombre es <item>. Si tu consumidor aguas abajo espera una convención diferente (p. ej., forma singular del nombre del padre como <color>), tendrás que post-procesar el XML o usar un conversor diferente que soporte el nombrado personalizado de elementos de array.

¿Funciona con archivos JSON grandes?

Sí, como todo se ejecuta en tu navegador, el techo práctico es la memoria disponible de tu dispositivo. Decenas de miles de líneas de JSON se convierten en mucho menos de un segundo en un portátil moderno. Entradas muy grandes (multi-MB) pueden congelar brevemente la pestaña mientras el parser recorre el árbol. Para conversión por lotes de grandes datasets, un script usando un conversor del lado del servidor (xml2js en Node, dicttoxml en Python) es más apropiado.

¿Se sube mi JSON a un servidor?

No. La conversión se ejecuta enteramente en tu navegador, el JSON pegado nunca sale de tu dispositivo. Verifica en la pestaña Red de DevTools mientras haces clic en Convert (no se dispara ninguna petición), o pon la página sin conexión (modo avión) tras cargarla. Seguro para respuestas de API de producción, configuración interna, o cualquier dato que no quisieras compartir externamente.

¿Puedo hacer que algunas claves JSON se conviertan en atributos XML en lugar de elementos hijos?

Este conversor emite todas las claves JSON como elementos hijos, no como atributos. La convención que algunos conversores usan (claves prefijadas con @ se convierten en atributos ("@id": 5 → id="5" en el padre)) es la convención BadgerFish. Si tu consumidor aguas abajo requiere ciertos valores como atributos, necesitarás un conversor personalizado que entienda la convención, o editar a mano el XML resultante.

¿Qué pasa con las claves JSON que contienen espacios o caracteres XML inválidos?

Los nombres de elementos XML tienen reglas más estrictas que las claves JSON: deben empezar con una letra o guion bajo, no pueden contener espacios y no permiten la mayoría de la puntuación. Las claves con caracteres inválidos se sanitizan, los espacios se vuelven guiones bajos, los dígitos iniciales reciben un prefijo de guion bajo, los caracteres especiales se eliminan. Esto significa que un viaje de ida y vuelta JSON → XML → JSON puede no producir los nombres de claves originales exactamente. Si tus datos tienen claves inusuales, inspecciona la salida para asegurarte de que la deformación no rompió nada importante.

Herramientas relacionadas