Convertidor XML a JSON gratuito
Convierte XML a JSON al instante. Maneja atributos, elementos anidados y nodos de texto. Funciona completamente en tu navegador.
¿Qué es XML?
XML (Extensible Markup Language) es un formato para almacenar y transportar datos. Utiliza etiquetas personalizadas para describir la estructura de los datos, lo que lo hace legible por humanos y ampliamente compatible. A diferencia de JSON, XML puede incluir atributos en los elementos.
¿Por qué convertir XML a JSON?
- Tamaño de archivo más pequeño · JSON es más compacto que XML.
- APIs web · La mayoría de los servicios web modernos usan JSON en lugar de XML.
- Análisis más sencillo · JSON se asigna directamente a objetos JavaScript.
- Integración con sistemas heredados · Convierte datos XML antiguos al formato JSON moderno.
Preguntas frecuentes
¿Cómo se manejan los atributos XML?
Los atributos XML se convierten en propiedades JSON con el prefijo «@». Por ejemplo,
¿Qué hay de los espacios de nombres?
Los prefijos de espacios de nombres XML se mantienen en los nombres de las claves JSON. Las declaraciones de espacios de nombres (xmlns) aparecerán como atributos normales que comienzan con «@xmlns» en la salida.
¿Puedo convertir JSON de vuelta a XML?
Esta herramienta solo convierte XML a JSON. Para la conversión inversa, prueba nuestro convertidor JSON a XML que invierte el proceso usando la misma convención para atributos y nodos de texto.
Dos formatos, separados por tres décadas
XML 1.0 se convirtió en Recomendación del W3C el 10 de febrero de 1998. Los editores originales fueron Tim Bray (Textuality / Netscape), Jean Paoli (Microsoft) y C. M. Sperberg-McQueen (Universidad de Illinois en Chicago); el grupo de trabajo fue presidido por Jon Bosak, de Sun Microsystems. El linaje de XML se remonta a SGML (ISO 8879:1986), el estándar de marcado de documentos que a su vez surgió del GML de IBM en la década de 1970. SGML era potente pero abrumador; el objetivo de diseño de XML era «diseñar una versión 'lite' de SGML», recortando las características opcionales a un perfil que pudiera implementarse en unos pocos miles de líneas de código mientras conservaba Unicode, los espacios de nombres y los documentos ricos en atributos.
JSON (JavaScript Object Notation) fue descubierto, no diseñado. Douglas Crockford y Chip Morningstar enviaron el primer mensaje JSON en abril de 2001 en State Software, derivando el formato de la sintaxis de objetos literales de JavaScript. Crockford registró json.org en 2002 y publicó una especificación de una página. El formato se formalizó por primera vez como RFC 4627 en julio de 2006, se reeditó como RFC 7159 en 2014 y se estabilizó como RFC 8259 / STD 90 en diciembre de 2017, el mismo año en que ECMA-International publicó ECMA-404. La intención de diseño de JSON (según la retrospectiva de Crockford): mínimo, independiente del lenguaje, fácil de generar y analizar, sin número de versión («no hay número de versión») y deliberadamente sin comentarios («eliminé los comentarios porque vi que la gente los usaba para guardar directivas de análisis»).
JSON se apoderó de las API web a finales de la década de 2000, a medida que REST reemplazaba a SOAP y XMLHttpRequest daba paso a JSON sobre fetch. Para 2015, JSON era el formato de respuesta por defecto de casi todas las API públicas; XML sobrevivió en la SOA empresarial de larga cola, en los formatos de documentos (Office Open XML, OpenDocument) y en nichos ligados a estándares.
En qué difieren XML y JSON
| XML | JSON | |
|---|---|---|
| Atributos | De primera clase (<item id="5"/>) | Sin atributos; todo es un par clave/valor |
| Espacios de nombres | Nativos (xmlns:prefix="uri") | Nombres planos; las colisiones de prefijos son problema de la app |
| Comentarios | <!-- … --> | Ninguno según la especificación |
| Contenido mixto | Nativo (<p>text <b>and</b> markup</p>) | Incómodo; necesita arrays o convertir a cadena |
| Esquema | DTD, XSD 1.0 (2001) / 1.1 (2012), RELAX NG, Schematron | JSON Schema (especificación comunitaria, borrador 2020-12) |
| Orden | El orden de los elementos es significativo según la especificación | El orden de las claves de objeto no está garantizado (la mayoría de los analizadores conservan el orden de inserción en la práctica); los arrays están ordenados |
| Números | Cadenas hasta que un esquema les asigna tipo | Doble IEEE 754; sin distinción entero/flotante a nivel de especificación |
| Verbosidad | Alta (cada valor envuelto en etiquetas | Baja) solo puntuación |
Por qué XML→JSON es fundamentalmente con pérdidas
No existe una correspondencia canónica avalada por el W3C de XML a JSON. Todo convertidor tiene que inventar respuestas a preguntas que XML te permite expresar pero para las que JSON no tiene vocabulario nativo. Las decisiones recurrentes:
- Atributos frente a elementos hijos: XML te permite expresar los mismos datos de ambas formas. JSON solo tiene una noción (claves en un objeto), así que el convertidor debe inventar un marcador. Las convenciones comunes: BadgerFish usa
@para los atributos y$para el texto; Parker descarta los atributos por completo (con pérdidas pero simple); JsonML representa los elementos como arrays con etiquetas de tipo (conserva el orden y la estructura); GData / Newtonsoft / xml2js usan un subobjeto@attributesmás una clave#textcuando hace falta. Este convertidor sigue la convención al estilo de GData: los atributos bajo@attributes, el texto de contenido mixto bajo#text, y los hijos repetidos se convierten en arrays. - Elementos hijos repetidos: si el convertidor crea ciegamente una clave por hijo, el segundo hijo sobrescribe el primero. Solución estándar: detectar la repetición y emitir un array. Pero esto significa que la forma del JSON depende de los datos: un
<book>produce una cadena, dos producen un array de cadenas. Algunos consumidores quieren la forma de array incluso para un solo elemento; algunos convertidores exponen un interruptor de «siempre array» para nombres de elemento específicos. - Contenido mixto:
<p>Hello <b>world</b>!</p>entremezcla texto y elementos con un orden significativo. JSON no puede expresar de forma nativa ese entrelazado sin un array de tipos mixtos o una clave centinela#text. Muchos convertidores descartan la prosa entre elementos; los más conservadores la dividen en varias entradas de nodo de texto. - Espacios de nombres:
<soap:Envelope xmlns:soap="…">tiene a la vez un prefijo y una URI de enlace. La mayoría de los convertidores conservan el prefijo como parte de la clave JSON (soap:Envelope) y descartan el enlace, lo cual está bien siempre que el consumidor no necesite resolver el espacio de nombres. - Comentarios e instrucciones de procesamiento: normalmente se descartan silenciosamente, ya que JSON no tiene sintaxis de comentarios.
- Secciones CDATA: se aplanan a cadenas simples; el envoltorio
<![CDATA[…]]>se pierde. - Espacio en blanco: XML tiene
xml:space="preserve"para el espacio en blanco significativo; JSON no tiene equivalente. La mayoría de los convertidores recortan los nodos de texto que solo son espacio en blanco entre elementos.
Cuándo recurrirías a esto
- Consumir servicios SOAP heredados desde un frontend JS moderno. Las respuestas SOAP son XML; convertirlas una vez en el límite permite que el resto de la app trabaje en JSON.
- Procesamiento de fuentes RSS / Atom: ambos son formatos XML; los lectores de noticias y los agregadores modernos suelen querer JSON.
- Mapas de sitio XML (
sitemap.xml): convertirlos a JSON facilita inspeccionarlos y procesarlos mediante programación. - Datos OSM de OpenStreetMap: publicados como XML, frecuentemente se necesitan como JSON para la cartografía del lado del cliente.
- Archivos KML / GPX de Google Earth: formatos de datos geográficos que vienen en XML.
- Entrañas de Office Open XML: los
.docx,.xlsxy.pptxson archivos XML comprimidos; si has extraído uno y quieres inspeccionar su estructura como JSON, este es el paso de conversión. - Manipulación de SVG: el SVG es XML. Convertirlo a JSON facilita recorrer y mutar el árbol en JavaScript antes de volver a serializarlo.
- POM de Maven, archivos de compilación de Ant, configuración de Spring, recursos de Android, plists de Apple, datos financieros XBRL, registros médicos HL7, MusicXML, documentos jurídicos NMX: formatos XML de larga cola que a menudo necesitan JSON para las herramientas posteriores.
Alternativas modernas
- API JSON nativas. Si el servicio de origen ofrece una variante JSON, tómala. Los servicios SOAP normalmente no, pero la mayoría de los equivalentes modernos sí.
- GraphQL. Un lenguaje de consulta que permite al cliente solicitar exactamente la forma JSON que necesita de un esquema tipado.
- Protocol Buffers (Protobuf), MessagePack, CBOR, Avro. Formatos de serialización binaria con esquemas y tamaños de transmisión mucho más pequeños que los de XML o JSON. Comunes dentro de las mallas de microservicios; rara vez se usan en el límite del navegador porque necesitan bibliotecas de decodificación explícitas.
- Quédate en XML. Si los datos están genuinamente orientados a documentos (contenido mixto, estructura tipada profunda, validación de esquema que importa), XML encaja mejor. La fortaleza de JSON son los datos con forma de API; la fidelidad documental no es su especialidad.
Más preguntas
¿Por qué el mismo XML produce una forma JSON diferente en herramientas distintas?
Porque no existe una correspondencia canónica de XML→JSON. Cada convertidor elige una convención (BadgerFish, Parker, JsonML, al estilo de GData) y las formas JSON resultantes difieren en cómo se marcan los atributos, cómo se conserva el contenido mixto y cómo se convierten en arrays los hijos repetidos. Hacer ida y vuelta de XML a través de distintos convertidores produce JSON diferente; hacer ida y vuelta de JSON a XML a través de distintos convertidores puede cambiar la colocación de los atributos e incluso el orden de los elementos. Para la interoperabilidad, documenta la convención que usas y cíñete a ella.
¿Qué pasa con CDATA, los comentarios y las instrucciones de procesamiento?
Las secciones CDATA (<![CDATA[…]]>) se aplanan a contenido de cadena simple: el envoltorio desaparece, pero el texto del interior se conserva literalmente. Los comentarios XML (<!-- … -->) y las instrucciones de procesamiento (<?xml-stylesheet …?>) se descartan, ya que JSON no tiene sintaxis para ninguno. Si necesitas una fidelidad de ida y vuelta que conserve los comentarios, una ida y vuelta solo en XML es el enfoque correcto.
¿Sobrevivirá mi esquema XML (XSD) a la conversión?
No. XSD describe la estructura y los tipos de XML; JSON Schema es el estándar análogo (separado) para JSON. Algunas herramientas avanzadas pueden traducir XSD a JSON Schema, pero es una operación con pérdidas: XSD tiene características (contenido mixto, grupos de sustitución, tipos derivados) que no tienen un equivalente limpio en JSON Schema. Para la validación de documentos que importa, ejecuta XSD contra el XML original, no contra la conversión a JSON.
¿Por qué ganó JSON para las API web?
Por unas pocas razones. JSON se corresponde directamente con los objetos de JavaScript, así que el análisis del lado del navegador está a una llamada de JSON.parse(). El formato es mucho más pequeño: sin etiquetas de cierre, sin declaraciones de espacios de nombres, sin la carga de los esquemas. REST reemplazó a SOAP en la mayoría de las API públicas a finales de la década de 2000, y JSON era la carga útil natural para REST. Las fortalezas de XML (esquemas estrictos, espacios de nombres, contenido mixto) importan para los documentos y los sistemas empresariales heredados, pero rara vez para «dame el objeto de usuario». La web se optimizó para el caso más simple.
¿Se envía algo a un servidor?
No. El XML lo analiza el DOMParser nativo del navegador y luego se recorre recursivamente en JavaScript para construir la salida JSON. El XML pegado nunca sale de la página. La herramienta funciona sin conexión una vez cargada, lo que importa cuando el XML de origen contiene endpoints de API internos, datos de clientes o esquemas propietarios que preferirías no subir a ningún sitio.