TOML vs JSON vs YAML: ¿qué formato de config elegir?

Esta es la versión corta de TOML vs JSON vs YAML: JSON es el formato por defecto para el intercambio entre máquinas que todos los lenguajes saben parsear, YAML es el formato amigable para humanos que hace funcionar Kubernetes y los pipelines de CI, y TOML es el formato explícito y tipado creado para la configuración de herramientas y aplicaciones, como Cargo.toml y pyproject.toml. Ningún formato gana en todos los frentes. El formato de archivo de configuración correcto depende de tres cosas: quién lo edita, si necesitas comentarios y qué tan estrictos deben ser los tipos.

Una regla rápida. Si una máquina lo escribe y una máquina lo lee, opta por JSON. Si una persona edita a mano una infraestructura profundamente anidada todos los días, YAML se gana su complejidad. Si quieres una configuración evidente y tipada que sea difícil de arruinar, TOML es la opción más segura. Estos formatos no compiten entre sí. Ocupan carriles distintos: JSON para las máquinas, YAML para DevOps, TOML para la configuración de herramientas. El resto de esta guía lo respalda con ejemplos lado a lado, las diferencias que de verdad provocan errores y una matriz de decisión que puedes aplicar en tu próximo proyecto.

La respuesta en 30 segundos

Si solo tienes medio minuto, esta tabla es la comparación de formatos de archivo de configuración que buscabas.

	JSON	YAML	TOML
Comentarios	No	Sí (#)	Sí (#)
Tipos de datos	Explícitos, mínimos	Implícitos (inferidos por la forma)	Explícitos, ricos
Fechas nativas	No	Depende de la versión	Sí (cuatro tipos)
Estilo de anidamiento	Llaves {}	Indentación	Encabezados [section]
Sensible a la indentación	No	Sí (tabuladores prohibidos)	No
Cadenas multilínea	No (solo \n)	Sí (| y >)	Sí (""")
Comas finales	Prohibidas	N/A	Permitidas en arreglos
Superconjunto de JSON	—	Sí (1.2)	No
Mejor para	APIs, intercambio de datos	K8s, CI, Ansible	Config de herramientas Rust/Python

De esa tabla se desprenden tres veredictos de una línea:

• Elige JSON cuando el archivo lo producen y consumen programas: payloads de API, package.json, tsconfig.json, cualquier cosa que cruce la frontera de un sistema.
• Elige YAML cuando los humanos editan a mano configuraciones profundas y anidadas y el ecosistema ya lo espera: manifiestos de Kubernetes, GitHub Actions, Docker Compose, playbooks de Ansible.
• Elige TOML cuando quieres una configuración clara y tipada para una herramienta o aplicación, mayormente plana con unas pocas secciones, editada por colaboradores de distinto nivel: Cargo.toml, pyproject.toml, Hugo, Netlify.

Conviene entender por qué se sostienen esos veredictos, porque en las razones se esconden los errores que cuestan tiempo.

La misma configuración, de tres maneras

Nada explica la diferencia más rápido que una misma configuración escrita tres veces. Aquí tienes una pequeña configuración de servicio: un nombre y una versión, un par de flags de nivel superior, una lista de características y un bloque de base de datos anidado.

JSON:

{
  "name": "acme-api",
  "version": "2.4.0",
  "debug": false,
  "released": "2026-07-02",
  "features": ["auth", "metrics", "tracing"],
  "database": {
    "host": "db.internal",
    "port": 5432,
    "max_connections": 100
  }
}

YAML:

name: acme-api
version: "2.4.0"
debug: false
released: "2026-07-02"
features:
  - auth
  - metrics
  - tracing
database:
  host: db.internal
  port: 5432
  max_connections: 100

TOML:

name = "acme-api"
version = "2.4.0"
debug = false
released = "2026-07-02"
features = ["auth", "metrics", "tracing"]

[database]
host = "db.internal"
port = 5432
max_connections = 100

Los tres describen datos idénticos. Fíjate en dónde tropieza tu vista. JSON acumula la mayor cantidad de puntuación: cada clave va entre comillas dobles, cada nivel añade llaves y una sola coma final perdida es un error de sintaxis. YAML elimina casi todo eso, así que la estructura surge solo de la indentación, lo cual se lee de maravilla hasta que se cuela un tabulador. TOML queda en medio: comillas solo en las cadenas, pares key = value y un encabezado [database] que nombra el bloque anidado como lo haría un viejo archivo INI. Observa que el campo released es una cadena entre comillas en los tres casos, de modo que aquí los datos quedan idénticos. Eso es deliberado, porque las fechas son justo donde estos formatos dejan de coincidir, que es lo siguiente que vale la pena entender.

JSON: el formato por defecto para el intercambio entre máquinas

JSON es el formato al que recurres sin pensarlo, y por lo general ese instinto acierta. Todo lenguaje popular incluye un parser, toda API HTTP lo habla y su gramática es lo bastante pequeña como para retenerla en la cabeza. Es estricto e inequívoco: una cadena es una cadena, 5432 es un número, true es un booleano y hay exactamente una forma de escribir cada cosa. Esa rigidez es lo que hace que JSON sea seguro para enviarlo entre sistemas que nunca se han visto. Cuando un servicio Node envía JSON a un servicio Go, ambos coinciden en el significado byte por byte.

Esa misma rigidez explica por qué JSON domina en su propio terreno. package.json, tsconfig.json y composer.json son JSON porque las herramientas los generan y reescriben constantemente, y la configuración escrita por máquinas necesita un formato estricto para máquinas. Para los payloads de API y las colas de mensajes sencillamente no hay razón para elegir otra cosa.

Las debilidades de JSON aparecen todas en cuanto un humano tiene que editarlo a mano. No hay comentarios. No hay comas finales, así que reordenar una lista implica arreglar las comas. No hay cadenas multilínea, solo escapes \n. Cada clave necesita comillas dobles. Y no hay tipo de fecha, así que 2026-07-02 tiene que vivir como una cadena entre comillas y parsearse por convención. Para un archivo de configuración que mantiene una persona, esas carencias suman fricción.

El problema de que «JSON no tiene comentarios»

La función de JSON más solicitada es justo la que Douglas Crockford dejó fuera a propósito: los comentarios. Su razonamiento era que los comentarios animaban a la gente a colar directivas de parseo dentro de los archivos de configuración, rompiendo la interoperabilidad. Pienses lo que pienses de esa decisión, no puedes anotar un JSON plano, lo cual resulta doloroso para cualquier cosa que mantengan humanos. La solución práctica es un superconjunto. JSON5 añade comentarios, comas finales, claves sin comillas y comillas simples; JSONC (JSON with Comments) es la variante más ligera que VS Code usa para su configuración. Ambos conservan la forma de JSON a la vez que lo hacen editable. Si necesitas comentarios pero quieres quedarte dentro de la familia JSON, lee nuestra guía de formato JSON5 y JSONC para saber cuándo usar cada uno y cómo mantener contentas a las herramientas.

YAML: el estándar de DevOps amigable para humanos

YAML se optimiza para el humano frente al teclado. Admite comentarios, su disposición basada en indentación mantiene limpias las estructuras profundamente anidadas y las anclas te permiten definir un bloque una vez y reutilizarlo con un alias en lugar de copiar y pegar:

defaults: &defaults
  timeout: 30
  retries: 3

staging:
  <<: *defaults
  host: staging.internal

production:
  <<: *defaults
  host: prod.internal

El ancla &defaults nombra un bloque, y <<: *defaults lo fusiona en ambos entornos, de modo que un cambio en el timeout compartido ocurre en un solo lugar. Ni JSON ni TOML tienen nada parecido. Esa legibilidad es la razón por la que YAML se convirtió en la lingua franca de las operaciones: los manifiestos de Kubernetes, los flujos de trabajo de GitHub Actions, los archivos de Docker Compose y los playbooks de Ansible son todos YAML. Cuando tu configuración tiene cinco niveles de profundidad y un humano la ajusta a diario, la escasa puntuación de YAML es un alivio genuino.

El costo es complejidad y sorpresas. La especificación de YAML 1.2 es extensa y el cumplimiento total es raro, así que distintos parsers discrepan en los bordes. La indentación es significativa, los tabuladores están prohibidos por completo y un espacio mal alineado puede cambiar el significado o impedir el parseo. El borde más afilado es el tipado implícito: YAML adivina el tipo de un escalar sin comillas a partir de su forma, y se equivoca lo bastante seguido como para tener un apodo.

El problema de Noruega en un párrafo

Escribe country: NO en YAML y muchos parsers te devuelven el booleano false, no la cadena "NO", porque YAML 1.1, que la mayoría de las herramientas de Kubernetes todavía siguen, trata NO, YES, ON, OFF, Y y N como booleanos. El código de país de Noruega se convierte en false, en silencio, sin ningún error. El mismo tipado implícito convierte 0755 en un número octal y 1.20 en 1.2. La solución es aburrida pero fiable: pon entre comillas las cadenas que podrían confundirse con otra cosa. Este disparo al pie es lo bastante célebre como para merecer su propio análisis a fondo, con caídas reales y la historia de YAML 1.1 frente a 1.2, en nuestra guía del problema de Noruega en YAML. Para este artículo, la conclusión es sencilla: la comodidad de YAML y su peligro provienen de la misma característica.

YAML gana cuando la gente edita configuraciones profundamente anidadas todos los días y el ecosistema que la rodea ya lo exige. Si estás escribiendo un chart de Helm, estás escribiendo YAML, y está bien.

TOML: configuración explícita creada para herramientas

TOML (Tom’s Obvious, Minimal Language, creado por Tom Preston-Werner) fue diseñado para ser el formato de configuración que los usuarios de YAML habrían deseado tener: legible, pero sin adivinanzas. Su rasgo distintivo es la explicitud. Los tipos son inequívocos, así que port = 5432 siempre es un entero y name = "acme" siempre es una cadena, sin inferencia basada en la forma con la que tropezar. La sintaxis de TOML toma prestado el encabezado [section] de los archivos INI, lo que hace que el nivel superior de una configuración sea fácil de recorrer con la vista, y no es sensible a la indentación, así que los espacios en blanco nunca cambian el significado. La especificación de TOML 1.0.0 es pequeña y estable, lo cual es una ventaja: hay menos que recordar mal.

La capacidad estrella de TOML son los tipos nativos de fecha y hora, que ni JSON ni el YAML plano manejan con limpieza. Tiene cuatro: fecha-hora con desfase y zona horaria (1979-05-27T07:32:00Z), fecha-hora local sin ella, fecha local (1979-05-27, solo un día del calendario) y hora local (07:32:00). Eso significa que una fecha de despliegue sigue siendo una fecha real en lugar de una cadena que tienes que volver a parsear.

Tres piezas de la sintaxis de TOML hacen casi todo el trabajo. Un encabezado [section] abre una tabla; un encabezado con puntos como [tool.ruff] anida una tabla dentro de otra sin indentación extra; y una tabla en línea { version = "1.0", features = ["derive"] } empaqueta un objeto pequeño en una sola línea. Las secciones repetidas usan un encabezado doble, el arreglo de tablas:

[[servers]]
name = "alpha"
ip = "10.0.0.1"

[[servers]]
name = "beta"
ip = "10.0.0.2"

Ese bloque se convierte en un arreglo JSON de dos objetos bajo la clave servers. Se lee bien para una lista plana, que es exactamente lo que necesita la mayoría de la configuración de herramientas.

Las debilidades son reales pero acotadas. TOML no tiene tipo null, así que un valor ausente es sencillamente una clave omitida. El anidamiento profundo se vuelve verboso, porque cada nivel de una estructura anidada repetida repite el encabezado [[path]] completo, lo cual acaba siendo más ruidoso que el equivalente en YAML. Y TOML es más joven y menos universal que JSON o YAML, así que no toda herramienta lo habla. TOML brilla para la configuración que es mayormente plana con un puñado de secciones etiquetadas, lo que describe a la inmensa mayoría de la configuración de herramientas.

¿Por qué TOML para Rust y Python?

El auge de TOML sigue el rastro de dos ecosistemas que lo adoptaron como estándar. El gestor de paquetes de Rust, Cargo, usa Cargo.toml para cada crate, así que todo desarrollador de Rust lee y escribe TOML desde el primer día. Python lo siguió: PEP 518 introdujo pyproject.toml para declarar los requisitos de compilación, y PEP 621 estandarizó los metadatos del proyecto (nombre, versión, dependencias y secciones [tool.*]) en ese mismo archivo, reemplazando una dispersión de setup.py, setup.cfg y configuraciones por herramienta. Más allá de esos dos, Hugo, Netlify, Poetry y Foundry usan TOML por defecto. El hilo común es la configuración de herramientas que los colaboradores editan a mano y que se beneficia de ser evidente en lugar de ingeniosa.

Cara a cara: las diferencias que de verdad muerden

Las tablas de características son ordenadas. Los errores no lo son. Estas son las diferencias concretas que causan problemas reales, cada una con un pequeño ejemplo que puedes pasar por cualquier parser.

Comentarios

JSON no tiene sintaxis de comentarios en absoluto. TOML y YAML usan # hasta el final de la línea.

# TOML: un comentario al inicio
port = 5432  # y uno al final

# YAML: estilo de comentario idéntico
port: 5432   # comentario al final

En cuanto pegas un // o un # en JSON estricto, el parseo falla. Esto no es cosmético. Una configuración que mantiene un humano sin comentarios acumula conocimiento tribal que vive solo en la cabeza de alguien.

Tipos de datos y fechas

Los tipos de JSON son explícitos pero escasos, sin tipo de fecha. Los tipos de TOML son explícitos y ricos. Los de YAML son implícitos y, como vimos arriba, de vez en cuando erróneos. Las fechas son la división más clara. TOML expresa los cuatro tipos de forma nativa:

odt = 1979-05-27T07:32:00Z   # fecha-hora con desfase (tiene zona horaria)
ldt = 1979-05-27T07:32:00    # fecha-hora local (sin zona horaria)
ld  = 1979-05-27             # fecha local (un día del calendario)
lt  = 07:32:00               # hora local

Convierte ese TOML a JSON y cada valor se vuelve una cadena que conserva su significado: una fecha local sigue siendo "1979-05-27" en vez de inflarse en una falsa marca de tiempo a medianoche. Nuestro convertidor de TOML a JSON preserva ese tipo de fecha con exactitud, algo que muchos convertidores ingenuos hacen mal. YAML, por su parte, puede o no tratar 1979-05-27 como una fecha según el parser y la versión del esquema, que es precisamente la ambigüedad que no quieres en la configuración de producción.

Profundidad de anidamiento

Cuanto más se anida tu configuración, más divergen los formatos. Toma un pequeño árbol al estilo de Docker Compose:

services:
  web:
    build:
      context: .
      args:
        NODE_ENV: production
    ports:
      - "8080:8080"

YAML expresa la profundidad con pura indentación y se mantiene compacto. La misma estructura en TOML te obliga a deletrear la ruta completa en cada encabezado y a mover los valores escalares por delante de las tablas hijas:

[services.web]
ports = ["8080:8080"]

[services.web.build]
context = "."

[services.web.build.args]
NODE_ENV = "production"

JSON lleva el árbol en llaves anidadas, lo cual es inequívoco pero cargado de puntuación. Para configuraciones poco profundas los tres se sienten similares; pasados los tres o cuatro niveles, YAML es visiblemente más esbelto y TOML visiblemente más repetitivo. Esa única diferencia explica por qué Kubernetes eligió YAML y Cargo eligió TOML.

Sensibilidad a la indentación

Solo a YAML le importan los espacios en blanco. En JSON y TOML puedes indentar como quieras, o nada en absoluto, y el significado es idéntico. En YAML, la indentación es la estructura, y los tabuladores son ilegales, así que un editor que inserta un tabulador o un bloque pegado a la profundidad equivocada cambia el documento en silencio o se niega a cargar. Un elemento de lista indentado un espacio de más puede engancharse a la clave padre equivocada sin ningún error, lo cual es un fallo enloquecedor de detectar a simple vista porque el archivo sigue pareciendo razonable. Si tus colaboradores usan editores y ajustes distintos, ese es un impuesto permanente que YAML cobra y los otros dos no, y es una razón de peso para ejecutar un linter en CI sobre cualquier configuración YAML grande.

Cadenas multilínea

JSON no puede contener un salto de línea literal dentro de una cadena; lo escapas como \n. YAML y TOML sí tienen cadenas multilínea reales.

{ "note": "line one\nline two" }

note: |
  line one
  line two

note = """
line one
line two
"""

El | de YAML conserva los saltos de línea (un bloque > los pliega en espacios en su lugar), y el """ de TOML se comporta de forma similar, recortando el salto de línea que sigue inmediatamente a las comillas de apertura. Para scripts embebidos, SQL o texto de ayuda, esto por sí solo puede decidir el formato.

Comas finales y rigidez

JSON es el más estricto de los tres. Una coma final después del último elemento de un arreglo es un error de sintaxis:

# TOML válido: la coma final está bien
ports = [
  8001,
  8002,
]

La misma coma final después de 8002 en JSON no se puede parsear, por eso añadir una línea a un arreglo JSON tan a menudo implica también arreglar la coma de la línea de arriba. TOML permite la coma final, y la sintaxis de lista de YAML, con un guion por línea, esquiva la cuestión por completo. La rigidez es una virtud para el intercambio entre máquinas y una molestia para la edición a mano, que es el mismo compromiso visto desde el otro lado. Esta es también la fricción que JSON5 y JSONC se propusieron eliminar específicamente para JSON.

Enteros grandes y el techo de 2^53

Los tres formatos pueden escribir un entero de 64 bits como texto. El problema empieza cuando ese valor pasa por JavaScript, porque los números JSON del navegador son dobles IEEE-754 y solo pueden representar enteros con exactitud hasta 2^53 − 1 (9007199254740991). Un ID de Snowflake o una marca de tiempo en nanosegundos es mayor que eso, así que un viaje de ida y vuelta por una herramienta basada en JS lo redondea y corrompe el valor:

snowflake = 1420070400000000000   # exacto en el texto TOML

{ "snowflake": "1420070400000000000" }

La solución fiable en todos los formatos es almacenar esos valores como cadenas entre comillas, para que ningún parser numérico los toque nunca. Esto no es un defecto de ningún formato en particular; es una limitación del runtime que hace la conversión. Nuestros convertidores te avisan cuando un entero cruza esa línea en lugar de corromperlo en silencio.

Cómo elegir: matriz de decisión y diagrama de flujo

Cuando toca decidir qué formato de configuración usar, recorre las preguntas en orden y detente en el primer sí rotundo.

1. ¿El archivo lo escriben y leen principalmente programas, o el ecosistema ya impone un formato? Si es así, usa JSON. Un payload de API es JSON. Un archivo junto a package.json es JSON. No pelees contra las herramientas.
2. ¿Los humanos editan a mano configuraciones profundas y anidadas a diario, dentro de un stack que lo espera (Kubernetes, CI, Ansible)? Si es así, usa YAML y adopta una convención de comillas para esquivar el problema de Noruega.
3. ¿Es configuración de una herramienta o aplicación, mayormente plana con unas pocas secciones, editada por colaboradores de distinto nivel, donde lo tipado y evidente vence a lo escueto? Si es así, usa TOML.

Si dos respuestas empatan, desempata con este mapa de ejes:

Requisito	Mejor opción	Por qué
Comentarios en el archivo	TOML o YAML	JSON no tiene
Valores nativos de fecha/hora	TOML	Cuatro tipos de fecha explícitos
Anidamiento muy profundo	YAML	La indentación se mantiene compacta
Cero sorpresas con los espacios	JSON o TOML	No es sensible a la indentación
Atado a un archivo del ecosistema	JSON	package.json, tsconfig.json
Ediciones humanas, pocas secciones	TOML	Tipos explícitos, encabezados tipo INI
Intercambio máquina a máquina	JSON	Universal, estricto, rápido
La inferencia de tipos nunca debe adivinar	JSON o TOML	YAML infiere de forma implícita

La mayoría de los proyectos terminan usando más de uno. Un repositorio puede tener un package.json en JSON que nunca toca a mano, un pyproject.toml en TOML para sus herramientas de Python, flujos de trabajo en YAML dentro de .github y un archivo .env para los secretos locales que no sigue ninguna de estas gramáticas. Esa mezcla es normal, y ese es el punto: cada archivo vive en el formato que le conviene a quien lo edita. Si la capa .env forma parte de tu configuración, nuestra guía del formato de archivo .env explica dónde encaja junto a la configuración JSON y cómo convertir entre ambos.

Convertir entre TOML, JSON y YAML

Terminas convirtiendo entre estos formatos más a menudo de lo que esperarías. Un job de CI lee un pyproject.toml escrito a mano y lo necesita como JSON para alimentar un panel de dependencias. Una migración lleva una app de una configuración YAML a TOML para lograr un tipado más estricto. Una revisión de código es más fácil cuando comparas la forma JSON de dos archivos en lugar de sus originales sensibles a los espacios. Cada dirección tiene una trampa que conviene conocer antes de pegar.

De TOML a JSON. El riesgo principal son las fechas. Una fecha local como 1979-05-27 debería seguir siendo una fecha del calendario, no convertirse en una marca de tiempo UTC a medianoche que inventa una hora y una zona horaria. Los comentarios también se pierden, ya que JSON no puede contenerlos. El convertidor de TOML a JSON preserva cada tipo de fecha con fidelidad para que los viajes de ida y vuelta no pierdan información.

De JSON a TOML. TOML es más estricto con la estructura, así que dos cosas pueden bloquear una conversión. El nivel superior debe ser un objeto, porque un documento TOML siempre es una tabla en su raíz; un arreglo o escalar suelto no tiene a dónde ir. Y TOML no tiene null, así que un valor de objeto nulo se descarta (con una advertencia que enumera qué claves), mientras que un null dentro de un arreglo no tiene ninguna representación TOML válida. El convertidor de JSON a TOML expone ambos casos de forma explícita en lugar de producir una salida rota.

JSON y YAML, en ambos sentidos. Aquí lo que hay que vigilar es el problema de Noruega: un NO o un 0755 sin comillas puede cambiar de tipo al cruzar la frontera. El convertidor de JSON a YAML y el convertidor de YAML a JSON se encargan de las comillas para que una cadena siga siendo una cadena.

Después de cualquier conversión, vale la pena validar el resultado. Pasar la salida por el Formateador JSON confirma que el JSON esté bien formado y con una indentación coherente antes de que lo confirmes o lo envíes aguas abajo. Y como los archivos de configuración llevan secretos (tokens de registro, credenciales de base de datos, claves de despliegue), todas estas herramientas se ejecutan por completo en tu navegador: no se sube nada, así que un Cargo.toml con un token de registro privado o un archivo de valores con credenciales nunca sale de tu máquina.

Preguntas frecuentes

¿Es TOML mejor que YAML?

Ninguno es mejor de forma universal; la elección entre TOML y YAML se reduce a la forma. TOML es más difícil de arruinar gracias a los tipos explícitos y a que no tiene trampas de indentación, así que gana para la configuración de herramientas mayormente plana. YAML expresa el anidamiento profundo de forma más compacta, así que gana para la infraestructura grande y por capas como Kubernetes.

¿Debo usar JSON o YAML para los archivos de configuración?

Para la configuración que edita un humano, prefiere YAML: permite comentarios y se lee con limpieza, cosa que JSON no hace. Para la configuración que los programas generan y consumen, prefiere JSON: es estricto, rápido y universal. La línea divisoria es quién hace la edición, un humano o una máquina.

¿Por qué JSON no permite comentarios?

El creador de JSON, Douglas Crockford, quitó los comentarios a propósito. Le preocupaba que la gente incrustara directivas de parseo en ellos y rompiera la interoperabilidad entre parsers. Si necesitas comentarios en un archivo con forma de JSON, usa JSON5 o JSONC, que los devuelven sin cambiar la estructura central.

¿Qué es el problema de Noruega en YAML?

Es que YAML 1.1 trata ciertas palabras sin comillas como booleanos, así que country: NO se vuelve false en lugar de la cadena "NO". YES, ON y OFF se comportan igual. Ponerle comillas al valor lo evita; consulta la guía dedicada enlazada arriba para la historia completa.

¿TOML admite comentarios?

Sí. TOML usa # para los comentarios, tanto en su propia línea como al final de un valor, exactamente como YAML. Ten en cuenta que los comentarios se pierden cuando conviertes TOML a JSON, ya que JSON no tiene sintaxis de comentarios para contenerlos.

¿Puede TOML representar todo lo que JSON puede?

Casi. La brecha entre JSON y TOML es pequeña pero real: TOML no tiene tipo null, así que los null de JSON se descartan o se rechazan al convertir, y un documento TOML debe ser una tabla en el nivel superior, de modo que un arreglo o escalar JSON suelto no puede convertirse sin envolverlo antes bajo una clave.

¿Es YAML un superconjunto de JSON?

Desde YAML 1.2, sí: cualquier documento JSON válido también es YAML válido, así que un parser de YAML puede leer JSON directamente. Es un dato útil, pero no te apoyes en él como frontera de seguridad, porque los parsers de YAML añaden características (como las anclas) que JSON no tiene.

¿Qué formato de configuración es el más rápido de parsear?

JSON suele ser el más rápido, con los parsers más maduros y optimizados en todos los lenguajes. YAML es el más lento y complejo de parsear por su extensa especificación y su tipado implícito. TOML queda en medio, más cerca de JSON en velocidad que de YAML.