Convertir JSON a YAML Online
Convierte JSON a YAML legible. Ideal para crear configs de Docker Compose, Kubernetes o GitHub Actions.
name: John Doe age: 30 active: true tags: - developer - javascript address: city: Madrid zip: 28001
Casos de uso
De JSON de API a configuración YAML legible
Crear configs DevOps
Transforma respuestas JSON de APIs de Kubernetes, Docker o herramientas cloud en archivos de configuración YAML editables.
Workflow DevOps
Convierte plantillas JSON de CloudFormation o ARM de Azure a YAML equivalente para mayor legibilidad y mantenimiento.
100% privado
Tu JSON se procesa en tu navegador. Nunca se sube a ningún servidor. Sin registro ni límites de uso.
YAML limpio
Indentación de 2 espacios, tipos correctamente representados, listo para pegar en docker-compose.yml o un manifiesto de Kubernetes.
Cómo funciona
Tres pasos, sin complicaciones
Pega tu JSON
Pega cualquier JSON válido: respuesta de API, configuración, datos estructurados. Se acepta JSON con o sin formato.
Conversión a YAML limpio
El JSON se convierte a YAML con indentación de 2 espacios, siguiendo las convenciones de los proyectos DevOps más populares.
Copia y usa el YAML
Copia el YAML resultante para usarlo como base de tu docker-compose.yml, manifiesto de Kubernetes o cualquier config YAML.
Preguntas frecuentes
¿Tienes dudas?
YAML supera a JSON en legibilidad para configuraciones largas y jerárquicas. Las principales ventajas de YAML son: soporte para comentarios (imprescindible en archivos de configuración documentados), sintaxis más concisa (sin llaves ni comillas en la mayoría de casos), mejor representación de strings multilínea (scripts, comandos, texto), y lectura más natural de listas. JSON es superior cuando el destino es una API o un programa que lo procesa automáticamente: el parsing es más rápido, la especificación es más simple y estricta, y hay menos ambigüedad. La regla práctica en DevOps es: YAML para archivos que los humanos editan directamente, JSON para datos que intercambian sistemas.
El conversor genera YAML estructuralmente equivalente al JSON de entrada, sin comentarios (JSON no tiene comentarios, por lo que no hay información que transferir). Sin embargo, el YAML generado es un punto de partida excelente: puedes abrirlo en cualquier editor y añadir comentarios manualmente con # antes o después de cualquier línea. En herramientas como docker-compose.yml y los manifiestos de Kubernetes, los comentarios son fundamentales para documentar el propósito de cada configuración.
JSON es considerablemente más rápido de parsear que YAML. El parsing de JSON es O(n) con constantes muy bajas: parsers como simdjson (usado en Node.js desde la versión 17) procesan hasta 3 GB/s en hardware moderno. YAML requiere un parser más complejo (maneja anclas, alias, tipos explícitos, varios estilos de string) y es típicamente 10-50x más lento que JSON para el mismo volumen de datos. Para archivos de configuración pequeños (docker-compose.yml de unos KB), la diferencia es imperceptible. Para APIs que intercambian millones de mensajes por segundo, JSON es la elección correcta. La elección de YAML en herramientas DevOps es una decisión de ergonomía para los humanos que editan esos archivos.
El conversor usa 2 espacios de indentación, que es la convención adoptada por la práctica totalidad del ecosistema DevOps: Kubernetes (kubectl genera YAML con 2 espacios), Helm, GitHub Actions, GitLab CI, Ansible y Docker Compose. Algunos proyectos usan 4 espacios (habitual en proyectos de Python donde la convención PEP 8 de 4 espacios influye en los desarrolladores), pero 2 espacios es el estándar de facto en la comunidad DevOps.
La conversión de tipos es directa: los números JSON (enteros y flotantes) se representan como escalares YAML sin comillas; los booleanos JSON (true/false) se representan como true/false en YAML; null JSON se representa como null o ~ en YAML; los strings se representan sin comillas cuando no hay ambigüedad, o entre comillas simples o dobles cuando el valor podría interpretarse como otro tipo (por ejemplo, el string '42' necesita comillas para no convertirse en número, y 'true' necesita comillas para no convertirse en booleano).
Convertir JSON a YAML: de respuestas de API a configuraciones DevOps legibles
La conversión de JSON a YAML es una operación habitual en flujos de trabajo DevOps modernos. Las APIs de Kubernetes (la API REST de Kubernetes devuelve recursos en JSON por defecto), AWS CloudFormation, Azure Resource Manager, Google Cloud Deployment Manager y la mayoría de herramientas de infraestructura como código tienen interfaces JSON nativas, pero sus usuarios prefieren trabajar con archivos de configuración en YAML por su mayor legibilidad. kubectl, la herramienta de línea de comandos de Kubernetes, convierte automáticamente entre YAML y JSON: cuando ejecutas kubectl get deployment mi-app -o yaml, Kubernetes devuelve el objeto JSON de la API y kubectl lo convierte a YAML para mostrarlo al usuario. La conversión inversa (JSON a YAML) es útil cuando quieres crear un manifiesto YAML a partir de una respuesta de API, cuando migras configuraciones entre herramientas, o cuando quieres documentar una configuración existente añadiendo comentarios YAML.
YAML (especificación 1.2, publicada en yaml.org en julio de 2009) es un superconjunto de JSON, lo que garantiza que la conversión de JSON a YAML es siempre posible sin pérdida de información. La conversión inversa (YAML a JSON) solo pierde los comentarios, que JSON no puede representar. Las ventajas de YAML para configuraciones humanas son bien documentadas: la ausencia de llaves y corchetes reduce el ruido visual en un 30-40% para configuraciones típicas; los comentarios permiten documentar el propósito de cada parámetro directamente en el archivo; los strings multilínea (especialmente con el bloque literal |) permiten incluir scripts shell, consultas SQL o contenido de archivos directamente en la configuración sin escapar caracteres especiales.
En el ecosistema de Kubernetes, la elección entre YAML y JSON está bien establecida: los archivos que los desarrolladores crean y mantienen en repositorios git son YAML; los datos que kubectl envía al API server son JSON (kubectl convierte YAML a JSON internamente antes de hacer la llamada HTTP); las respuestas del API server son JSON; y las herramientas de automatización (Helm, Kustomize, Argo CD, Flux) trabajan con YAML como entrada y JSON como protocolo interno. Esta separación entre el formato humano (YAML) y el formato de protocolo (JSON) es un patrón que también siguen GitHub Actions (los workflows son YAML, la API de GitHub es JSON), GitLab CI, Ansible (playbooks en YAML, datos de inventario dinámico en JSON), y Terraform (HCL es la alternativa de HashiCorp, pero también acepta JSON nativo en archivos .tf.json).