Convertir entre JSON y YAML

convierte JSON a YAML (y viceversa) preservando la estructura, con indentación configurable. Práctico para migrar una configuración entre archivos .json y .yaml

¿Para qué sirve este convertidor JSON / YAML?

Esta herramienta transforma un documento YAML en JSON y a la inversa, preservando la estructura de los datos (objetos, tablas, tipos escalares). La conversión JSON a YAML, o YAML a JSON, es una operación habitual en desarrollo: se genera un fichero OpenAPI YAML a partir de una spec JSON, se convierte la salida de una API REST a YAML para confirmarla en un repositorio de configuración, se traduce un manifest Kubernetes YAML a JSON para pasarlo a kubectl --dry-run=client -o json, o se alinea un workflow GitHub Actions con un esquema JSON. En sentido amplio, es el puente entre el mundo del intercambio de datos (JSON) y el de la configuración editable a mano (YAML).

YAML vs JSON: comparación directa

JSON y YAML abordan necesidades cercanas pero casos de uso distintos. La tabla siguiente resume las diferencias técnicas principales, útiles para elegir entre ambos según el contexto.

Criterio JSON YAML
Legibilidad humana Media (llaves, comillas por todas partes) Alta (indentación, poca puntuación)
Verbosidad Más verboso Más conciso
Comentarios No admitidos Admitidos (# commentaire)
Multidocumentos en un solo fichero No Sí, mediante el separador ---
Anchors y aliases (reutilización) No Sí (&anchor y *anchor)
Sistema de tipos Estricto (string, number, bool, null, array, object) Coerción implícita (yes, no, null, fechas, escalares interpretados)
Rendimiento de parsing Muy rápido, parsers nativos en todas partes Más lento, gramática mucho más amplia
Adopción para las API REST Estándar de hecho Rara
Adopción para la configuración Rara (salvo package.json, tsconfig.json) Estándar de hecho (Kubernetes, CI/CD, Ansible)

¿Cuándo utilizar JSON?

JSON se impone en cuanto un programa habla con otro programa. Sus casos de uso típicos:

  • APIs REST y GraphQL: payloads de petición y de respuesta.
  • Intercambio de datos entre microservicios y colas de mensajes.
  • Código JavaScript nativo: JSON.parse y JSON.stringify sin dependencia.
  • Almacenamiento del lado del navegador: localStorage, sessionStorage, IndexedDB.
  • Peticiones AJAX y fetch.
  • Variantes binarias u orientadas a flujo: BSON (MongoDB), JSON Lines (logs, datasets ML), MessagePack.
  • Configuración de herramientas JS / TS: package.json, tsconfig.json, composer.json.

¿Cuándo utilizar YAML?

YAML se impone en cuanto un humano edita el fichero con regularidad. Sus casos de uso típicos:

  • Docker Compose (docker-compose.yml) y perfiles de stack.
  • Manifests de Kubernetes (Deployment, Service, Ingress, Helm charts).
  • Playbooks de Ansible e inventarios.
  • Pipelines CI/CD: GitHub Actions, GitLab CI, CircleCI, Bitbucket Pipelines.
  • Especificaciones OpenAPI / Swagger y AsyncAPI.
  • Configuración aplicativa anotada (Symfony, Spring Boot, Rails) donde los comentarios son útiles.
  • Ficheros editados con frecuencia a mano, donde la concisión y la legibilidad priman sobre la velocidad de parsing.

Errores habituales en YAML

YAML es más permisivo que JSON, lo que lo convierte en un formato potente pero traicionero. Los errores más frecuentes:

  • Indentación: las tabulaciones están prohibidas por la especificación, solo los espacios son válidos. Mezclar ambos o cambiar el número de espacios en un mismo bloque rompe el parsing.
  • Coerción automática de los escalares: yes, no, on, off, true, false, null, None, ~ se parsean como booleanos o como null. Ejemplo trampa: un código postal 01234 sin entrecomillar se convierte en el entero 1234, y un nombre de país NO (Noruega) se convierte en false. Entrecomille siempre las cadenas ambiguas.
  • Strings multilínea: | (block literal) conserva los saltos de línea tal cual, mientras que > (folded) sustituye los saltos de línea por espacios. Los indicadores de chomping - y + ajustan el comportamiento sobre el salto final.
  • YAML 1.1 vs 1.2: la 1.1 (todavía muy extendida, por ejemplo mediante PyYAML por defecto) trata yes/no/on/off como booleanos, lo que la 1.2 ha eliminado. Los comportamientos también difieren en los números en base 8.
  • Fechas implícitas: 2024-01-15 sin comillas es interpretado como un objeto fecha por algunos parsers, no como una cadena.

Ejemplos en paralelo

El mismo documento, expresado en JSON y, después, en YAML. Configuración sencilla de una aplicación con sus dependencias y su entorno:

Versión JSON

{
    "name": "cdrn-app",
    "version": "1.14.2",
    "environment": "production",
    "dependencies": {
        "php": "^8.3",
        "symfony/framework-bundle": "^7.0",
        "doctrine/orm": "^3.0"
    },
    "features": ["cache", "mailer", "queue"],
    "debug": false
}

Versión YAML equivalente

# Configuration de l'application
name: cdrn-app
version: 1.14.2
environment: production
dependencies:
    php: '^8.3'
    symfony/framework-bundle: '^7.0'
    doctrine/orm: '^3.0'
features:
    - cache
    - mailer
    - queue
debug: false

La versión YAML es aproximadamente un 25 % más corta en caracteres, admite un comentario al inicio y se lee como una lista de propiedades sin ruido sintáctico.

Cómo utilizar el convertidor

Pasos para convertir sus datos:

  1. Pegue su documento fuente (JSON o YAML) en el campo de entrada.
  2. Seleccione el sentido de conversión deseado (JSON a YAML, o YAML a JSON).
  3. Haga clic en el botón de conversión: el resultado formateado aparece en la zona de salida.
  4. Compruebe el resultado y, después, utilice el botón de copia para recuperarlo en su portapapeles.

La conversión se realiza localmente en su navegador o a través de una ruta de servidor dedicada según el tooling: ningún dato sensible se conserva.

Preguntas frecuentes

¿JSON o YAML para mis ficheros de configuración?

Si el ecosistema impone un formato (Kubernetes en YAML, package.json en JSON), siga la convención. Si no, prefiera YAML para las configuraciones largas y anotadas que edita a mano, y JSON para las configuraciones generadas por un programa o consumidas por código. La presencia de comentarios útiles suele ser el argumento decisivo a favor de YAML.

¿Cómo conservar los comentarios en un round-trip YAML a JSON a YAML?

No es posible. JSON no admite comentarios: en cuanto se convierte YAML en JSON, los comentarios se pierden definitivamente. Para preservar los comentarios en ediciones programáticas, utilice un parser que conserve la puesta en forma, como ruamel.yaml en Python en modo round-trip, o evite por completo el paso por JSON.

¿Por qué mi fichero YAML se parsea correctamente en local pero falla en producción?

Causas frecuentes: versiones de parser distintas (YAML 1.1 vs 1.2), tabulaciones introducidas por un editor, valores sin entrecomillar que parecen booleanos (NO, off) o números (01234), codificación del fichero (UTF-8 BOM mal gestionado). Entrecomille sistemáticamente las cadenas ambiguas y fije la versión del parser en su proyecto.

¿Es JSON un subconjunto de YAML?

Desde YAML 1.2, sí en la práctica: todo documento JSON válido es un documento YAML 1.2 válido. Lo contrario es falso: un documento YAML que utiliza comentarios, anchors, fechas implícitas o varios documentos en un fichero no puede expresarse directamente en JSON sin pérdida de información.

¿Qué alternativas a JSON y YAML conviene conocer?

TOML: popular para la configuración (Cargo, pyproject.toml), buen compromiso entre legibilidad y tipado explícito. INI: muy sencillo, pero sin estructura anidada estándar. XML: verboso, pero sigue siendo pertinente para SOAP y algunas configuraciones Java legacy. HCL: utilizado por Terraform. JSON5 y JSONC: extensiones de JSON que autorizan comentarios y comas finales.

¿Cuál es el peso de YAML vs JSON?

A estructura equivalente, YAML suele ser entre un 15 y un 30 % más corto en octetos, gracias a la ausencia de comillas alrededor de las claves y de la mayoría de las cadenas, y a la ausencia de llaves. En el wire (transporte HTTP), JSON minificado sigue siendo comparable, pero YAML se mantiene más compacto en versión legible. En cuanto al rendimiento puro en parsing, JSON es varias veces más rápido, lo que justifica su uso para las API con mucho tráfico.

Ejemplo de solicitud

curl -X POST https://cdrn.fr/api/v1/tools/json-yaml-converter/execute \
  -H "Content-Type: application/json" \
  -d '{"json":"...","space_tabulation":1}'

Esquema de entrada

Campo Tipo Obligatorio Por defecto
json text
space_tabulation integer

Puntos de acceso

  • GET https://cdrn.fr/api/v1/tools - lista todas las herramientas disponibles
  • GET https://cdrn.fr/api/v1/tools/json-yaml-converter - recupera el esquema de esta herramienta
  • POST https://cdrn.fr/api/v1/tools/json-yaml-converter/execute - ejecuta esta herramienta con un payload JSON