Cómo elegir entre 8 formatos comunes de configuración: de INI, XML, JSON, YAML y TOML a Markdown

Wed, 22 Apr 2026 21:48:37 +0800

Si escribes código, administras servidores, ajustas opciones de juegos o mantienes toolchains, casi seguro no puedes evitar los archivos de configuración.

Muchas veces, lo que realmente rompe un programa no es el algoritmo ni el framework, sino una línea diminuta de configuración: un espacio faltante, una coma extra o un valor escrito de una forma que el sistema no esperaba. Mirar formatos comunes lado a lado nos devuelve a varias preguntas centrales:

¿Qué formatos son más amables para escribir por humanos?
¿Qué formatos son más amables para parsear por máquinas?
En la era de AI Agents, ¿empezará a cambiar el papel de los archivos de configuración?

Este artículo intenta organizar esa cuestión de forma concisa.

01 Un archivo de configuración es básicamente una negociación entre humanos y máquinas

Hay una forma de decirlo que me parece especialmente precisa: un archivo de configuración es un contrato de comportamiento entre humanos y programas.

Su valor es obvio. No necesitas reescribir lógica de negocio ni recompilar nada. Cambiando unas pocas líneas de texto puedes alterar el comportamiento de un sitio, la lógica de una aplicación, el despliegue o incluso gráficos y opciones ocultas de un juego.

El problema es que este contrato contiene una tensión incorporada.

Desde el lado humano queremos:

algo legible, escribible y estructuralmente claro
preferiblemente con comentarios para entenderlo después
la menor repetición posible, idealmente con reutilización y modularidad
un formato que no explote de inmediato por un pequeño error

Pero desde el lado máquina, la elegancia es irrelevante. Le importan principalmente dos cosas:

el parsing debe ser rápido
las reglas deben ser estrictas, los tipos claros y la ambigüedad mínima

Por eso los formatos de configuración siempre se tensan entre lo human-friendly y lo machine-friendly. Cuanto mejor es un formato para lectura humana, más trabajo suele necesitar la máquina para parsearlo. Cuanto más eficiente es para máquinas, más fácil suele ser que humanos cometan errores al editarlo.

02 INI: simple y directo, pero limitado

Empecemos con INI.

Sus fortalezas son muy directas:

estructura simple
secciones más pares clave-valor fáciles de entender
soporte de comentarios
adecuado para configuración ligera, como ajustes de juegos o entorno básico

Si alguna vez modificaste ajustes de juegos antiguos o parámetros de herramientas a mano, probablemente lo viste.

Pero INI también tiene limitaciones obvias. Su estructura es demasiado plana y no representa naturalmente anidamiento profundo o arrays. Además, normalmente carece de un sistema de tipos estricto, así que muchos valores son básicamente strings y el programa decide cómo interpretarlos.

Eso hace que INI se sienta como una herramienta vieja pero cómoda: excelente para trabajo ligero, fácil de superar cuando el proyecto crece.

Un INI típico:

[server]
host=127.0.0.1
port=8080

[feature]
enable_cache=true

03 XML: riguroso y estable, pero cansado de escribir

El segundo formato importante es XML.

Si mantuviste proyectos Java antiguos o viste archivos enormes llenos de tags de cierre, te resultará familiar.

Sus fortalezas incluyen:

estructura jerárquica clara
soporte de comentarios
reglas estrictas
validación fuerte cuando se combina con un schema

Eso permite a las máquinas conocer tipos, cardinalidad y restricciones estructurales antes de parsear de verdad, dando mucha seguridad.

Pero su coste humano es igual de clásico:

tags verbosos
mucho ruido visual
archivos que crecen rápido
un cierre faltante puede romperlo todo

Por eso XML se siente como un contrato formal sellado. A las máquinas les gusta; los humanos se cansan de mantenerlo. Muchos proyectos nuevos ya no lo eligen primero, pero en sistemas antiguos y entornos con reglas estrictas no ha desaparecido.

La misma configuración en XML:

<config>
  <server>
    <host>127.0.0.1</host>
    <port>8080</port>
  </server>
  <feature>
    <enable_cache>true</enable_cache>
  </feature>
</config>

04 JSON: dominante para intercambio de datos, incómodo para configuración editada a mano

En desarrollo moderno, JSON es casi inevitable.

El juicio clásico es: excelente como formato de intercambio de datos, algo incómodo como configuración mantenida por humanos.

Sus ventajas:

estructuras claras de objetos y arrays
transmisión amigable para red
parsers maduros
encaje fuerte con APIs web y comunicación frontend-backend

Frente a XML, JSON se ve mucho más ligero. La misma estructura suele ser más corta y más fácil de enviar por red.

Pero tiene un defecto grande: JSON estándar no soporta comentarios.

Su sintaxis también es estricta:

las claves deben ir entre comillas dobles
el último elemento no puede tener coma final
un símbolo faltante rompe todo de inmediato

Así que JSON es excelente para APIs e intercambio entre servicios, pero no siempre ideal para configuración que humanos editan, explican y revisan a menudo.

Por ejemplo:

{
  "server": {
    "host": "127.0.0.1",
    "port": 8080
  },
  "feature": {
    "enable_cache": true
  }
}

05 YAML: muy legible, pero la indentación y los tipos implícitos pueden traicionarte

Si trabajaste con Docker, CI/CD, Kubernetes o automatización de despliegues, casi seguro trataste con YAML.

Su mayor atractivo es lo limpio que se ve:

menos llaves y comillas
la indentación expresa jerarquía
soporta comentarios
anchors para reutilización

Desde una primera mirada humana, YAML suele parecer más amable que JSON.

Pero el problema está justo ahí. Oculta mucha complejidad y en uso real produce dos fallos clásicos:

infierno de indentación
conversión implícita de tipos

Los problemas de indentación son fáciles de entender: un espacio extra o faltante puede romper la config. Peor aún, la conversión implícita hace que valores que parecen strings simples puedan interpretarse automáticamente como booleanos u otros tipos.

Por eso tanta gente elogia lo bien que se ve YAML y al mismo tiempo sufre con él. Es realmente bueno para lectura humana, pero las máquinas no lo parsean sin esfuerzo, e incluso distintas librerías pueden discrepar en detalles sutiles.

La misma configuración en YAML:

server:
  host: 127.0.0.1
  port: 8080

feature:
  enable_cache: true

06 TOML: equilibrio entre legibilidad y determinismo

TOML suele presentarse como una respuesta moderna equilibrada.

Su atractivo combina parte de la claridad de INI con parte de la claridad de tipos de JSON:

soporte de comentarios
estructura clara
tipado más fuerte y explícito
manejo más natural de tipos comunes como fecha y hora
muchas menos trampas de conversión implícita que YAML

También se ha vuelto cada vez más común en toolchains modernas, como pyproject.toml en Python.

No es perfecto. En estructuras profundamente anidadas, TOML puede volverse verboso, y la escritura por rutas puede sentirse repetitiva. Pero para config de proyectos pequeños y medianos, herramientas y package management, la experiencia suele ser muy estable.

Si quieres un formato con comentarios, significado claro y bajo dolor de parser, TOML es un candidato fuerte.

Ejemplo común:

[server]
host = "127.0.0.1"
port = 8080

[feature]
enable_cache = true

07 `.conf` y configuración Apache: no es un formato universal, sino un lenguaje de dominio

Vale la pena enfatizar que mucha gente ve .conf y asume que es un formato estándar único. No lo es.

.conf es solo un sufijo de archivo para “configuration”. El contenido depende por completo de las reglas del sistema concreto. Es más una categoría amplia que una sintaxis estándar.

Toma Apache como ejemplo. Su estilo es representativo:

parte parece una lista de directivas de una línea
parte parece bloques etiquetados con comportamiento acotado
encaja naturalmente en el dominio de servidores web

Sus fortalezas son prácticas para operaciones, especialmente al expresar permisos, routing y virtual hosts. La desventaja es que sirve a su propio ecosistema y no tiene mucha portabilidad general.

Eso lo acerca a un lenguaje específico de dominio: excelente dentro del sistema para el que fue diseñado, no algo que tratar como formato universal.

Ejemplo mínimo estilo Apache:

Listen 80

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot "/var/www/html"
</VirtualHost>

08 Protocol Buffers: tipado industrial, pero mayor barrera

Protocol Buffers ya no son realmente “solo escribir una config a mano”. Se parecen más a un sistema formal de definición y serialización de datos.

Sus fortalezas son importantes:

tipado fuerte
schema explícito
buena compatibilidad hacia adelante y atrás
transmisión binaria compacta
procesamiento eficiente por máquinas

Pero los costes también son claros:

hay que definir archivos .proto
se necesitan herramientas y paso de compilación
la barrera es relativamente alta para proyectos pequeños

Así que no son ideales si solo quieres configurar una herramienta pequeña. Pero si construyes sistemas grandes, servicios RPC, sistemas distribuidos o protocolos de datos de larga vida, suelen ser mucho más fiables que formatos ligeros.

Su estilo se acerca a “define primero la estructura y luego genera código”:

syntax = "proto3";

message ServerConfig {
  string host = 1;
  int32 port = 2;
  bool enable_cache = 3;
}

09 En la era de AI Agents, Markdown puede volver a ser formato de configuración

La parte más interesante es poner Markdown dentro de la categoría de “formatos de configuración”.

Desde una perspectiva tradicional, suena extraño, porque Markdown parece más bien documentación. Pero si el objetivo ya no es un parser rígido sino un LLM o AI Agent, el argumento tiene sentido.

¿Por qué?

Porque los programas tradicionales dependen de sintaxis estricta y campos fijos, mientras los modelos grandes entienden mejor significado, estructura y contexto. Para ellos:

los encabezados son jerarquía
las listas son pasos
el texto en negrita es énfasis
el lenguaje natural puede portar reglas

Cuando el objetivo de configuración cambia de “parser rígido” a “agente que entiende significado”, Markdown, como texto estructurado amigable para humanos, puede volverse una configuración más natural.

Esto lleva a un juicio importante: en la era tradicional del software, muchos formatos existían para hacer que humanos se adaptaran a máquinas; en la era AI, las máquinas empiezan a adaptarse a la expresión humana.

Por ejemplo, una configuración de tarea para un agente podría ser:

# Goal

Write a welcome email for a new user.

## Requirements

- Friendly tone
- No more than 150 words
- Mention the product's 3 core features

## Forbidden

- Do not promise features that do not exist
- Do not use exaggerated marketing language

10 Entonces, ¿cómo elegir?

Si comprimimos toda la discusión:

si quieres configuración extremadamente simple, ligera y plana: INI
si quieres estructura fuerte, validación fuerte y compatibilidad legacy: XML
si quieres transmisión de red e intercambio de interfaces: JSON
si quieres alta legibilidad más cloud-native y config de despliegue: YAML
si quieres una experiencia moderna generalista más estable: TOML
si quieres reglas internas específicas de dominio: .conf / DSLs estilo Apache
si quieres diseño industrial de protocolos y evolución a largo plazo: Protocol Buffers
si quieres expresión natural y orquestación de tareas para AI Agents: Markdown

No hay un único mejor formato. Depende de para quién escribes:

humanos que mantienen el sistema
máquinas que parsean a alta velocidad
servicios que se comunican entre sí
o AI Agents que necesitan entender y ejecutar

Conclusión breve

La historia de los archivos de configuración es, en el fondo, la historia de humanos y máquinas renegociando constantemente dónde debe caer el coste de entender.

Antes, los humanos tenían que adaptarse a las máquinas, así que memorizábamos llaves, reglas de indentación, comillas y sintaxis rígida. Ahora que los modelos de lenguaje y sistemas de agentes entienden cada vez mejor la expresión natural, la propia “configuración” empieza a cambiar.

Quizá en el futuro muchos escenarios de configuración ya no giren alrededor de una sintaxis fija, sino de declaraciones estructuradas de intención. Hasta entonces, formatos como JSON, YAML, TOML, INI y XML seguirán coexistiendo, cada uno en el rol que mejor le encaja.

Config Files on KnightLi Blog