¿Cuál es el formato más usado hoy?

JSON domina en la web, sin duda, es el formato por defecto en APIs REST y configuración frontend. YAML reina en DevOps e infraestructura, sobre todo en pipelines de CI y definiciones de contenedores. XML se mantiene en entornos empresariales y en formatos con estructura documental compleja. TOML creció mucho en el ecosistema de herramientas de desarrollo. CSV sigue siendo el estándar para datos tabulares.

¿Puedo convertir entre formatos?

Sí, en la mayoría de los casos. JSON, YAML y TOML tienen modelos de datos parecidos y la conversión entre ellos es casi directa. XML es más complejo por los atributos y el contenido mixto, pero hay mapeos comunes. CSV solo representa tablas, así que convertir a jerárquico o de jerárquico a CSV exige decisiones sobre cómo aplanar la estructura.

¿Por qué YAML es tan problemático?

Tiene una especificación mucho más grande de lo que parece. Algunas palabras clave ("yes", "no", "on", "off") se interpretan como booleanos, los números con ceros a la izquierda pueden leerse como octales, y la indentación con espacios o tabs provoca errores silenciosos. Las versiones más recientes (YAML 1.2) corrigieron parte de estos puntos, pero hay que estar atento al modo estricto del parser.

¿JSON5 y JSONC resuelven la falta de comentarios de JSON?

Sí, son variantes de JSON que añaden comentarios y algo de flexibilidad extra (comas finales, claves sin comillas). No son estándares universales, pero sí están soportados en entornos concretos como editores de código. Para el intercambio entre sistemas, quédate con JSON puro para garantizar compatibilidad.

¿Cuándo debo elegir TOML en vez de YAML?

TOML es mejor cuando quieres sintaxis limpia para configuración sin las trampas de la indentación significativa. Para archivos de configuración de proyecto con estructura media, TOML suele ser menos propenso a errores. YAML es mejor para estructuras muy profundas o cuando necesitas referencias internas y funcionalidades avanzadas.

Comparación de Formatos de Datos. JSON, YAML, XML, TOML, INI, CSV

Tabla comparativa

Formato	Comentarios	Verbosidad	Tipos	Legible por humanos	Uso típico
JSON .json	No	Media	Básicos	Media	APIs web, configuración frontend
YAML .yaml / .yml	Sí	Baja	Básicos	Alta	Pipelines de CI/CD, infraestructura como código
XML .xml	Sí	Alta	Solo texto	Baja	Sistemas empresariales, documentos, SOAP
TOML .toml	Sí	Media	Rico	Alta	Configuración de aplicaciones, herramientas de desarrollo
INI .ini / .conf	Sí	Baja	Solo texto	Alta	Configuración simple, archivos heredados
CSV .csv	No	Baja	Tabular	Media	Hojas de cálculo, exportación de datos tabulares

Detalle por formato

JSON.json

JavaScript Object Notation

Formato derivado de la sintaxis de objetos de JavaScript. Se convirtió en la lengua franca del intercambio de datos en la web por su simplicidad y soporte nativo en cualquier lenguaje moderno.

Ejemplo

{
  "server": {
    "host": "localhost",
    "port": 8080,
    "debug": false,
    "tags": ["web", "api"]
  }
}

Pros

+Soportado de forma nativa por prácticamente todos los lenguajes
+Sintaxis simple y predecible
+Parsing rápido y barato
+Estructura jerárquica clara

Contras

−No admite comentarios, lo que limita su utilidad en archivos editados a mano
−Poco tolerante a errores de sintaxis (una coma de más y falla el parseo)
−Verboso para configuraciones largas por las comillas y llaves obligatorias

Cuándo usar

Peticiones y respuestas de APIs REST, almacenamiento de datos estructurados, comunicación entre servicios. Siempre que la legibilidad humana sea secundaria a la interoperabilidad.

YAML.yaml / .yml

YAML Ain't Markup Language

Formato pensado para ser legible por humanos, con sintaxis basada en indentación en lugar de llaves. Es un superconjunto de JSON.

Ejemplo

server:
  host: localhost
  port: 8080
  debug: false
  tags:
    - web
    - api

Pros

+Muy legible, sin ruido visual de llaves ni comillas
+Admite comentarios y referencias internas
+Excelente para archivos editados manualmente
+Estructuras complejas con poca sintaxis

Contras

−La indentación significativa es fuente habitual de errores (tabs vs espacios)
−Especificación grande, con casos extremos sorprendentes ("yes" y "no" interpretados como booleanos)
−Parseo más lento y dependiente de bibliotecas externas en algunos lenguajes

Cuándo usar

Pipelines de CI/CD, definiciones de contenedores, configuración de orquestadores y cualquier archivo de configuración extenso que se beneficie de comentarios y estructura clara.

XML.xml

Extensible Markup Language

Formato basado en etiquetas con raíces en SGML. Durante años fue el estándar del intercambio de datos estructurados antes de que JSON tomara el relevo.

Ejemplo

<server>
  <host>localhost</host>
  <port>8080</port>
  <debug>false</debug>
  <tags>
    <tag>web</tag>
    <tag>api</tag>
  </tags>
</server>

Pros

+Esquemas formales maduros (XSD, DTD) para validación estricta
+Buen soporte de metadatos mediante atributos y espacios de nombres
+Ecosistema potente de transformaciones con XSLT y consultas con XPath
+Ideal para documentos con contenido mixto (texto y estructura)

Contras

−Muy verboso, las etiquetas de apertura y cierre duplican el volumen
−La distinción entre atributos y elementos es arbitraria y divide opiniones
−Más difícil de leer y escribir a mano que las alternativas modernas

Cuándo usar

Integraciones con sistemas heredados o empresariales, documentos con estructura compleja, formatos donde la validación rigurosa por esquema es obligatoria (facturación electrónica, archivos de oficina).

TOML.toml

Tom's Obvious Minimal Language

Formato relativamente reciente, diseñado para ser obvio y no ambiguo. Combina secciones al estilo INI con tipos de datos ricos y soporte para estructuras anidadas.

Ejemplo

[server]
host = "localhost"
port = 8080
debug = false
tags = ["web", "api"]

Pros

+Especificación corta y sin casos ambiguos
+Tipos nativos para fechas, números y arrays
+Admite comentarios y secciones con nombre
+Equilibrio entre legibilidad y parseo fiable

Contras

−Menos universal, fuera de los ecosistemas que lo adoptaron resulta exótico
−Las estructuras muy anidadas se vuelven más verbosas que en YAML
−Comunidad aún en crecimiento, menos herramientas auxiliares

Cuándo usar

Archivos de configuración de proyectos modernos, manifiestos de paquetes, cualquier caso donde quieras una sintaxis limpia sin las trampas de indentación de YAML.

INI.ini / .conf

Initialization File

Uno de los formatos más antiguos que siguen en uso. Estructura por secciones entre corchetes y pares clave valor. No existe una especificación formal única, lo que genera variantes incompatibles.

Ejemplo

[server]
host = localhost
port = 8080
debug = false
tags = web,api

Pros

+Extremadamente simple de leer y escribir
+Trivial de parsear, incluso con código propio
+Soportado por muchos sistemas operativos y herramientas
+Admite comentarios y secciones

Contras

−Sin estándar formal, cada implementación tiene variaciones
−No admite jerarquías profundas más allá de una sección
−Todos los valores son cadenas, la conversión de tipos queda en manos de la aplicación
−Sin soporte nativo para listas estructuradas

Cuándo usar

Configuración plana de herramientas pequeñas, archivos de usuario en sistemas Windows y Linux, casos donde la simplicidad vale más que las funcionalidades.

CSV.csv

Comma-Separated Values

Formato para datos tabulares: una fila por registro, valores separados por comas. Existe desde hace décadas y sigue siendo el pan de cada día del intercambio entre hojas de cálculo, bases de datos y herramientas de análisis.

Ejemplo

host,port,debug,tags
localhost,8080,false,"web,api"
example.com,443,true,"web"

Pros

+Universal entre hojas de cálculo, bases de datos y herramientas estadísticas
+Compacto para datos puramente tabulares
+El streaming línea a línea permite archivos enormes
+Editable en cualquier herramienta, de Excel a Vim

Contras

−Sin jerarquía, es solo una tabla plana
−Sin tipos, todo son cadenas sin distinción entre número y texto
−El tratamiento de comillas, comas dentro de valores y saltos de línea es fuente clásica de errores
−Variaciones regionales (coma vs punto y coma como separador)

Cuándo usar

Exportación de informes, importación en hojas de cálculo, datasets para análisis estadístico, cualquier escenario donde los datos son genuinamente tabulares.

Sobre esta herramienta

Comparación directa entre seis formatos de serialización muy usados: JSON, YAML, XML, TOML, INI y CSV. Para cada uno verás sintaxis lado a lado, puntos fuertes, puntos débiles y el contexto donde tiene sentido elegirlo. Útil para decidir el formato de configuración de una aplicación nueva, ponerte al día rápido con un formato que no conocías, o respaldar una decisión técnica con argumentos concretos.

Cómo usar

Lee la tabla comparativa para una visión general de las características de cada formato.
Compara los ejemplos lado a lado. Todos representan el mismo objeto para facilitar la comparación.
Decide según el contexto. Hay formatos mejores para configuración editada a mano y otros mejores para el intercambio entre sistemas.

Preguntas frecuentes

¿Cuál es el formato más usado hoy?: JSON domina en la web, sin duda, es el formato por defecto en APIs REST y configuración frontend. YAML reina en DevOps e infraestructura, sobre todo en pipelines de CI y definiciones de contenedores. XML se mantiene en entornos empresariales y en formatos con estructura documental compleja. TOML creció mucho en el ecosistema de herramientas de desarrollo. CSV sigue siendo el estándar para datos tabulares.
¿Puedo convertir entre formatos?: Sí, en la mayoría de los casos. JSON, YAML y TOML tienen modelos de datos parecidos y la conversión entre ellos es casi directa. XML es más complejo por los atributos y el contenido mixto, pero hay mapeos comunes. CSV solo representa tablas, así que convertir a jerárquico o de jerárquico a CSV exige decisiones sobre cómo aplanar la estructura.
¿Por qué YAML es tan problemático?: Tiene una especificación mucho más grande de lo que parece. Algunas palabras clave ("yes", "no", "on", "off") se interpretan como booleanos, los números con ceros a la izquierda pueden leerse como octales, y la indentación con espacios o tabs provoca errores silenciosos. Las versiones más recientes (YAML 1.2) corrigieron parte de estos puntos, pero hay que estar atento al modo estricto del parser.
¿JSON5 y JSONC resuelven la falta de comentarios de JSON?: Sí, son variantes de JSON que añaden comentarios y algo de flexibilidad extra (comas finales, claves sin comillas). No son estándares universales, pero sí están soportados en entornos concretos como editores de código. Para el intercambio entre sistemas, quédate con JSON puro para garantizar compatibilidad.
¿Cuándo debo elegir TOML en vez de YAML?: TOML es mejor cuando quieres sintaxis limpia para configuración sin las trampas de la indentación significativa. Para archivos de configuración de proyecto con estructura media, TOML suele ser menos propenso a errores. YAML es mejor para estructuras muy profundas o cuando necesitas referencias internas y funcionalidades avanzadas.

JSON vs YAML vs XML vs TOML vs INI vs CSV

Sobre esta herramienta

Cómo usar

Preguntas frecuentes

Herramientas relacionadas