Desarrollo

Formateador de XML

Formatear, validar y comprimir XML.

Qué hace. Esta herramienta indenta XML para hacerlo legible, comprueba si está bien formado y puede volver a comprimirlo. Todo el procesamiento ocurre en tu navegador.

Funciona en tu navegadorNo se sube nadaSin registroFunciona sin conexión

Cómo usar Formateador de XML

Pega tu XML.
Elige formatear o comprimir.
Copia el resultado.

Bien formado y válido son cosas distintas

Esta distinción es el origen de casi toda la confusión con XML.

Un documento está bien formado si cumple las reglas sintácticas de XML: un único elemento raíz, etiquetas correctamente anidadas y cerradas, valores de atributo entrecomillados y caracteres especiales codificados.

Es válido si además se ajusta a un esquema — un XSD o una DTD — que define qué elementos pueden aparecer, en qué orden y con qué tipos de datos.

Esta herramienta comprueba que esté bien formado. Para validar contra un esquema necesitas el esquema.

La diferencia práctica: un documento bien formado se puede leer; uno válido contiene además lo que espera quien lo recibe.

En España esto es muy concreto: la factura electrónica en el ámbito público usa el formato Facturae en XML con firma electrónica, y se remite a través de la plataforma correspondiente. Un archivo bien formado pero que no cumple el esquema se rechaza automáticamente.

Con la extensión de la facturación electrónica al ámbito privado, esa exigencia alcanza a muchas más empresas.

Errores frecuentes

Casi todos los problemas caen en unas pocas categorías.

Caracteres sin codificar: un & suelto en el texto es el clásico, y también un < dentro de contenido textual. Deben escribirse & y <.

Codificación: si la declaración dice UTF-8 pero el archivo está guardado en otra codificación, lo primero que se rompe son las tildes y la ñ. En España es, con diferencia, el fallo más común.

La marca de orden de bytes al inicio del archivo: invisible en el editor, pero muchos analizadores tropiezan con ella porque la declaración XML deja de estar en la posición cero.

Espacios de nombres: se usa un prefijo que no se ha declarado, o se pierde la declaración por defecto al ensamblar fragmentos de distintas fuentes.

Y los espacios en blanco: dentro del contenido de un elemento son significativos en XML. Un formateador que indenta está modificando técnicamente el contenido, lo cual es inocuo en formatos de datos puros pero no en contenido mixto.

Cuándo XML y cuándo otra cosa

Una orientación práctica, porque la pregunta surge a menudo.

XML es fuerte donde la estructura debe estar estrictamente definida y ser verificable de forma automática. Por eso persiste en el ámbito administrativo y en la facturación, donde los formatos tienen que ser estables y vinculantes durante años.

JSON es más compacto y es el estándar en interfaces web, pero no tiene una validación de esquema tan asentada en el uso diario, ni atributos, ni espacios de nombres, ni comentarios.

YAML es más legible para archivos de configuración, a cambio de ser sensible a errores de indentación.

Si conviertes XML a JSON, ten presente lo que se pierde: atributos y elementos se tratan igual, los espacios de nombres desaparecen y el orden de los elementos hermanos no está garantizado en un objeto JSON.

Todo esto se ejecuta localmente en tu navegador, incluso para archivos que no deberían salir de tu equipo.

Preguntas frecuentes

¿Qué diferencia hay entre bien formado y válido?

Bien formado es sintácticamente correcto; válido es además ajustado a un esquema.

¿Por qué se rompen mis tildes?

Porque la codificación declarada no coincide con la real del archivo.

¿Qué es la marca de orden de bytes?

Un carácter invisible al inicio que hace fallar a muchos analizadores.

¿Por qué se usa XML en facturación?

Porque la estructura debe ser verificable automáticamente frente a un esquema obligatorio.

¿Se pierde algo al convertir a JSON?

Sí: espacios de nombres, la distinción atributo/elemento y el orden.

¿Se envían mis datos?

No.