Convertidor JSON a YAML

Cómo funciona

1. Pega JSON: introduce cualquier JSON válido, desde pares clave-valor planos hasta objetos y arrays profundamente anidados.
2. Conversión instantánea: la herramienta transforma el JSON en YAML con la indentación correcta, retira las comillas de las claves de cadena y traduce los tipos null, booleano y numérico.
3. Configura la salida: define el ancho de indentación (2 o 4 espacios) y elige entre el estilo bloque o flujo para las colecciones.
4. Copia el YAML: el resultado está listo para pegarse en archivos de configuración, pipelines CI/CD o manifiestos de Kubernetes.

¿Por qué convertir JSON a YAML?

YAML es el formato de configuración preferido para las herramientas de infraestructura como Kubernetes, Docker Compose, GitHub Actions, Ansible y los charts de Helm, más legible que JSON, admite comentarios y no exige comillas alrededor de cada cadena. Convertir respuestas de API, secciones de package.json o estructuras de datos de JSON a YAML es una tarea frecuente en DevOps y desarrollo back-end. La estructura basada en indentación de YAML es más legible para humanos, mientras que JSON es preferido para las API y la generación programática, este convertidor tiende el puente entre ambos.

Correspondencia de tipos

• Cadenas → sin comillas si es posible, entre comillas si contienen caracteres especiales
• Números → escalares numéricos YAML tal cual
• Booleanos → true / false en YAML
• null → null o ~ en YAML
• Arrays → secuencias en bloque YAML con prefijo -
• Objetos → mapeos YAML con pares clave: valor

¿Qué es la conversión JSON a YAML?

La conversión JSON a YAML traduce un árbol de pares clave-valor de un formato de serialización a otro mientras preserva los datos subyacentes. Ambos formatos describen la misma forma de datos (cadenas, números, booleanos, null, arreglos, objetos), pero JSON usa llaves y corchetes mientras YAML usa indentación y guiones. La misma configuración 'name: app, version: 1, ports: 80, 443' puede expresarse en cualquiera, y los convertidores se mueven entre ellos sin perder significado.

JSON, inventado por Douglas Crockford alrededor de 2001 y estandarizado como RFC 4627 en 2006 y ECMA-404 en 2013, es la lengua franca de las API web. YAML 1.0 (2001), 1.1 (2005) y 1.2 (2009) por Clark Evans, Ingy doet Net y Oren Ben-Kiki fue diseñado como un superconjunto de JSON optimizado para la legibilidad humana, con soporte para comentarios, cadenas multilínea, anclajes y alias. Las herramientas DevOps modernas (Kubernetes, Docker Compose, GitHub Actions, Ansible, Helm) adoptaron YAML por defecto porque las configs son escritas y revisadas por humanos.

Este convertidor empareja ambos formatos uno al lado del otro. Pegue JSON a la izquierda, haga clic en JSON a YAML, y el panel derecho se actualiza con YAML válido en su profundidad de indentación elegida (2 o 4 espacios). El botón inverso ejecuta el mismo proceso al revés. La conversión usa la biblioteca js-yaml (Vitaly Puzrin, 2011) cargada desde jsDelivr, que implementa la especificación YAML 1.2 con suficiente precisión para hacer ida y vuelta de manifiestos Kubernetes, charts Helm y especificaciones OpenAPI.

Lo que hay dentro del convertidor

La interfaz utiliza un diseño de cuadrícula de dos paneles: JSON a la izquierda, YAML a la derecha. En pantallas más estrechas que 768 píxeles, el diseño se apila verticalmente. Sobre los paneles, un selector de indentación le permite elegir 2 o 4 espacios por nivel. La elección activa se resalta, y la indentación se aplica a ambas direcciones de conversión.

Cada panel tiene sus propios botones de acción. El panel JSON ofrece JSON a YAML (convertir) y Borrar. El panel YAML ofrece YAML a JSON (inverso), Copiar (portapapeles) y Descargar .yaml (guardar como archivo con extensión .yaml y codificación UTF-8). El banner de error debajo del convertidor saca a la superficie errores de análisis con el número de línea y un mensaje corto, así puede arreglar entradas inválidas sin salir de la herramienta.

Bajo el capó, la conversión JSON a YAML usa JSON.parse más la función dump de js-yaml. La dirección YAML a JSON usa la función load de js-yaml más JSON.stringify con indentación de 2 espacios. Ambas direcciones son funciones puras de la entrada, no se lleva estado entre conversiones, y refrescar la página lo reinicia todo.

Historia y contexto

Douglas Crockford especifica JSON (2001)

Douglas Crockford documentó la sintaxis JSON en abril de 2001 mientras estaba en State Software, después de darse cuenta de que la sintaxis literal de objeto de JavaScript podría servir como un formato de datos independiente del lenguaje. La especificación era deliberadamente mínima: seis tipos, dos colecciones, sin comentarios, sin esquema. RFC 4627 siguió en 2006 y ECMA-404 en 2013. El minimalismo es exactamente lo que hizo a JSON ubicuo en la web.

YAML 1.0 publicado (2001)

Clark Evans, Ingy doet Net y Oren Ben-Kiki lanzaron YAML 1.0 en mayo de 2001, el mismo año que JSON. El acrónimo era originalmente Yet Another Markup Language pero fue renombrado retroactivamente a YAML Ain't Markup Language para aclarar que YAML apunta a datos de configuración, no a marcado de documentos. La especificación 1.0 era ambiciosa, soportando anclajes, alias, flujos multi-documento, etiquetas personalizadas y comentarios.

YAML 1.1 y el problema de Noruega (2005)

YAML 1.1 (enero de 2005) endureció la especificación pero mantuvo el famoso comportamiento de coerción booleana donde las cadenas yes, no, on, off, y, n, true, false, más sus variantes en mayúsculas, todas se convierten en booleanos. Este es el Problema de Noruega: el código de país ISO sin comillas NO se convierte en el booleano false. El bug mordió a los primeros usuarios de Kubernetes hasta que YAML 1.2 (2009) eliminó los ortografías booleanas alternativas.

YAML 1.2 declara JSON como subconjunto (2009)

YAML 1.2 (octubre de 2009) hizo explícitamente que JSON fuera un subconjunto estricto de YAML, por lo que cualquier documento JSON válido es también un documento YAML válido. Esta fue una gran victoria de diseño: las herramientas que manejaban YAML 1.2 podían analizar JSON gratis, simplificando la implementación de convertidores y validadores. La versión todavía en uso en la mayoría de las herramientas hoy es 1.2 o un perfil compatible con 1.1.

Kubernetes lanza manifiestos YAML (2015)

Kubernetes 1.0, lanzado por Google en julio de 2015, definió los recursos de clúster (Pods, Deployments, Services) usando manifiestos YAML. La elección fue impulsada por la legibilidad para los equipos de operaciones acostumbrados a los editores de texto y al control de versiones. Helm (2016) añadió plantillas encima, GitHub Actions (2018) adoptó YAML para flujos de trabajo, y los playbooks de Ansible (2012 a 2018) cimentaron YAML como el lenguaje de configuración DevOps dominante.

js-yaml se convierte en la biblioteca JavaScript de facto (a partir de 2011)

Vitaly Puzrin publicó js-yaml en 2011 como un puerto JavaScript puro de PyYAML. Las versiones posteriores (2.0 en 2014, 3.0 en 2015, 4.0 en 2021) siguieron la especificación YAML 1.2, agregaron esquemas para optar por no usar funciones peligrosas, y alcanzaron más de 50 millones de descargas npm semanales. La biblioteca es empaquetada por webpack, parcel y esbuild para cualquier trabajo YAML del lado del navegador, y es lo que este convertidor usa bajo el capó.

Flujos de trabajo prácticos

Autoría de manifiestos Kubernetes

Cuando genera un Pod o Deployment via kubectl run --dry-run=client -o json, obtiene JSON. Péguelo aquí, haga clic en JSON a YAML, y tiene un manifiesto listo para hacer commit a git. La conversión preserva las specs anidadas, las variables de entorno y los límites de recursos exactamente como Kubernetes los leerá.

Definiciones de servicio Docker Compose

Un compañero de equipo le envía un fragmento JSON para un nuevo servicio. Péguelo, convierta y deje el YAML en su docker-compose.yml. La indentación de 2 espacios es el predeterminado de Compose, así que deje la opción de indentación en 2.

Flujos de trabajo de GitHub Actions

Cuando estructura un flujo de trabajo desde un generador de plantilla basado en JSON o copia un paso desde una respuesta de API JSON, péguelo aquí y convierta. La salida cae directamente en .github/workflows/*.yml. Tenga en cuenta que GitHub Actions también acepta JSON en algunos campos, pero YAML es la forma canónica.

Playbooks Ansible

Los inventarios Ansible a menudo comienzan su vida como JSON exportado de un CMDB o una base de datos de activos. Pegue, convierta a YAML, y tiene un archivo hosts o un encabezado de playbook que se ajusta al estilo esperado de Ansible. Use indentación de 2 espacios para coincidir con la guía de estilo de la comunidad Ansible.

Valores de chart Helm

Un proveedor entrega configuraciones de muestra JSON para su chart Helm. Convierta a YAML y déjelo en values.yaml. La conversión respeta las claves anidadas (image.repository, image.tag, resources.limits.memory) exactamente como Helm las espera.

Especificaciones OpenAPI 3

Swagger Editor exporta especificaciones OpenAPI tanto en JSON como en YAML. Cuando una herramienta emite JSON pero su equipo usa YAML en el control de versiones (o viceversa), este convertidor es la forma más rápida de cambiar formatos sin lanzar Node, Python o yq.

Trampas comunes

El problema de Noruega (yes, no, on, off como booleanos)

En YAML 1.1, las cadenas yes, no, on, off, y, n, true, false (y sus variantes en mayúsculas) son todas booleanos. Por lo que el código de país ISO sin comillas NO se convierte en el booleano false. js-yaml 4.x usa por defecto YAML 1.2 que solo trata true y false como booleanos, pero los analizadores YAML más antiguos aún pueden tropezar. Entrecomille explícitamente las cadenas ambiguas si mezcla versiones de herramientas.

Los tabuladores no son indentación YAML válida

YAML usa espacios, no tabuladores, para indentación. Si su editor inserta tabuladores por defecto, el YAML convertido fallará en el análisis en Kubernetes, Helm o cualquier cargador YAML estricto. Configure su editor para usar 2 o 4 espacios para archivos .yaml y .yml, o ejecute un linter (yamllint) antes de hacer commit.

Los anclajes y alias no sobreviven a la conversión JSON

YAML soporta anclajes (&name) y alias (*name) para reutilizar valores. Cuando convierte YAML a JSON, los anclajes se expanden en línea porque JSON no tiene característica equivalente. La conversión inversa JSON a YAML no reintroducirá anclajes automáticamente. Si necesita anclajes, escríbalos a mano después de la conversión.

Las cadenas multilínea necesitan indicadores explícitos

Una cadena JSON con nuevas líneas incrustadas (Hello\nWorld) se convierte a YAML usando el escalar de bloque literal (|) o el escalar de bloque plegado (>). js-yaml elige la forma correcta, pero si edita el resultado a mano, recuerde que | preserva nuevas líneas y > las pliega en espacios.

Los números grandes pierden precisión

Los números JavaScript son flotantes IEEE 754 de 64 bits, por lo que los enteros más allá de 2 a la 53 (alrededor de 9 cuatrillones) pierden precisión cuando son analizados por JSON.parse. La conversión a YAML preserva el valor con pérdida, no el original. Si sus datos tienen identificadores estilo BigInt, codifíquelos como cadenas en JSON antes de convertir.

Los comentarios se pierden en YAML a JSON

YAML soporta comentarios #, JSON no. Cuando convierte YAML con comentarios de vuelta a JSON, los comentarios se eliminan porque JSON no tiene sintaxis para ellos. Si hace ida y vuelta de YAML a través de JSON para procesamiento, espere perder cada línea #. Herramientas como yq o ruamel.yaml pueden preservar comentarios, pero el js-yaml conforme a especificación los elimina.

Privacidad y manejo de datos

Toda la conversión se ejecuta en su navegador a través de la biblioteca js-yaml empaquetada en la página. No enviamos su JSON o YAML a un servidor, no registramos entradas, y no ejecutamos análisis sobre el contenido de sus conversiones. El botón Copiar usa la API Clipboard que requiere un gesto de usuario, y el botón Descargar .yaml usa una URL de blob en memoria, así que el archivo nunca hace ida y vuelta a través de ninguna red.

Una vez cargada la página (incluyendo el archivo CDN js-yaml), la herramienta funciona sin conexión. Puede desconectarse de la red y convertir configuración sensible (claves API, URLs de bases de datos, nombres de servicios internos) sin que nada salga de su dispositivo. El archivo js-yaml se sirve desde jsDelivr con un hash Subresource Integrity, por lo que el paquete no puede ser intercambiado silenciosamente.

Cuándo no usar este convertidor

Streaming de megabytes de datos

El convertidor carga toda la entrada en memoria, la analiza y emite el resultado de una sola vez. Para archivos JSON o YAML de múltiples megabytes, use yq o jq en una tubería de shell, o un analizador en streaming en su lenguaje favorito. El navegador no es la herramienta correcta por encima de 5 a 10 megabytes.

Datos binarios en JSON

Si su JSON tiene blobs binarios codificados en Base64 que deben inspeccionarse o modificarse, convertir a YAML no los desempaquetará. YAML soporta binario etiquetado (!!binary) que js-yaml maneja, pero los bytes permanecen en Base64. Use un editor binario dedicado para el trabajo real a nivel de byte.

Validación de esquema

Este convertidor verifica que la entrada sea JSON o YAML válido, pero no valida contra un esquema (JSON Schema, OpenAPI, CRD de Kubernetes, valores Helm). Si necesita saber si un manifiesto Kubernetes es estructuralmente correcto para un clúster 1.28, ejecute kubectl --dry-run=server o una herramienta como kubeval, kubeconform.

Refactorización consciente del esquema

Si necesita renombrar un campo a través de cientos de archivos YAML, o actualizar una versión de API (apps/v1beta1 a apps/v1), use sed, ast-grep o yq con consultas de ruta explícitas. El convertidor solo transforma entre formatos, no edita contenido semántico.

Más preguntas

¿Es JSON más seguro que YAML?

Para seguridad, sí. yaml.load de PyYAML (antes de 5.1) y analizadores permisivos similares podían ejecutar código arbitrario desde entradas YAML no confiables vía objetos Python etiquetados. JSON no tiene tal característica, cada analizador JSON es seguro por diseño. Los analizadores YAML modernos (PyYAML 5.1+, js-yaml desde 4.0) usan por defecto safe-load, así que la brecha se ha reducido, pero JSON sigue siendo el predeterminado más seguro para entrada no confiable.

¿Por qué YAML eligió indentación sobre llaves?

Los autores de YAML querían que las configs se leyeran como esquemas, así que usaron la misma convención que el espacio en blanco significativo de Python. Las llaves y corchetes son YAML válido (estilo de flujo), pero el estilo de bloque con indentación es el predeterminado porque escanea más naturalmente para humanos editando en texto plano. La compensación es que el espacio en blanco se vuelve significativo, lo que atrapa a los editores que recortan automáticamente los espacios al final.

¿Es YAML siempre un superconjunto estricto de JSON?

Desde YAML 1.2 (2009), sí. Cualquier documento JSON válido es también un documento YAML 1.2 válido. YAML 1.1 tenía algunos casos límite (números sexagesimales, el problema de Noruega) donde la relación era más laxa. js-yaml moderno usa 1.2 por defecto, así que la propiedad de superconjunto se sostiene para esta herramienta.

¿Por qué es tan verboso el YAML de Kubernetes?

Los manifiestos Kubernetes tienen una forma de nivel superior fija (apiVersion, kind, metadata, spec) y la spec contiene objetos anidados que reflejan los structs Go internos de la API. La verbosidad es un efecto secundario de mapear una API orientada a objetos a un formato de texto plano. Herramientas como Kustomize, Helm y Pulumi reducen la verbosidad, pero el YAML subyacente es lo que kubectl realmente envía al clúster.

¿Puedo hacer ida y vuelta de JSON a través de YAML sin pérdida de datos?

Para la mayor parte del JSON, sí. Cadenas, números, booleanos, null, arreglos, objetos todos sobreviven. Los casos límite incluyen enteros muy grandes (pérdida de precisión), pares sustitutos Unicode (depende del analizador) y orden de claves (YAML puede reordenar). Si sus claves JSON deben mantener su orden original, use una herramienta que respete el orden de inserción (OrderedDict de Python, json-stable-stringify en JavaScript).

¿Qué hay de TOML y HCL?

TOML (Tom's Obvious Minimal Language, 2013 por Tom Preston-Werner) es usado por Cargo (Rust), pyproject.toml (Python) y otros. HCL (HashiCorp Configuration Language, 2014) es usado por Terraform. Ambos apuntan al caso de uso de configuración pero usan sintaxis diferente. Este convertidor maneja solo JSON y YAML. Para TOML o HCL, use convertidores dedicados o yq con el plugin correcto.