Resultado de la conversión de JSON a YAML en FormatArcResultado de la conversión de JSON a YAML en FormatArc
Publicado: 2026-03-15Actualizado: 2026-06-02

Convertir JSON a YAML — Kubernetes, Docker Compose, Ansible (navegador y CLI)

Convierte JSON a YAML para manifiestos de Kubernetes, Docker Compose, valores de Helm y playbooks de Ansible. Herramienta en el navegador (sin subir archivos), yq, Python, Node.js, Go. Conserva el orden de las claves, gestiona escalares de bloque, salida multidocumento, entrecomillado de cadenas y el problema de Noruega.

TL;DR — elige un método en 10 segundos

  • Lo necesitas ya, sin instalar nada → FormatArc JSON a YAML (en el navegador, sin subir archivos, valida el JSON, conserva el orden de las claves)
  • CLI / one-liner → yq -P '.' file.json (el estándar de DevOps, -P para estilo de bloque)
  • Script de Python con orden de claves → yaml.dump(data, sort_keys=False, default_flow_style=False, allow_unicode=True)
  • Aplicación Node.js → js-yaml yaml.dump(data, { lineWidth: -1 })
  • Servicio en Go → gopkg.in/yaml.v3 yaml.Marshal
  • Ida y vuelta con Kubernetes → kubectl get ... -o json | jq '...' | yq -P '.'
  • De un array JSON a YAML multidocumento → yq -P '.[]' --split-exp 'true' json.array.json
Método Instalación Conserva el orden de claves Escalares de bloque (|) Salida multidocumento Inserción de comentarios
FormatArc navegador Ninguna Sí Sí No No (los añades después)
yq -P '.' brew install yq Sí Sí Sí (split-exp) No
Python yaml.dump (PyYAML) pip install pyyaml Requiere sort_keys=False Sí Separador --- manual No
Python ruamel.yaml pip install ruamel.yaml Sí Sí Sí Sí (API manual)
Node js-yaml npm install js-yaml Sí Sí Manual No
Go yaml.Marshal go get gopkg.in/yaml.v3 Sí (para yaml.Node) Sí Bucle con Encoder No

Convertir JSON a YAML es trivial a nivel estructural: ambos formatos representan el mismo modelo de datos. Lo difícil es conservar el orden de las claves, decidir cuándo entrecomillar las cadenas, gestionar las cadenas multilínea, dividir arrays JSON en YAML multidocumento y evitar el problema de Noruega en la salida.

¿Por qué convertir JSON a YAML?

JSON y YAML pueden representar las mismas estructuras de datos: mapas, listas, cadenas, números, booleanos y null. Son funcionalmente intercambiables. La razón para preferir uno sobre otro suele reducirse al contexto y a la legibilidad.

Kubernetes y la orquestación de contenedores

Kubernetes acepta tanto JSON como YAML para las definiciones de recursos, pero el ecosistema usa YAML de forma abrumadora. La documentación, los tutoriales, los artículos de blog y las respuestas de Stack Overflow están casi exclusivamente en YAML. Si generas una definición de recurso de forma programática (lo que a menudo produce JSON), convertirla a YAML la hace coherente con todo lo demás en la configuración de tu clúster y más fácil de revisar en los pull requests.

kubectl incluso tiene un modo integrado para esto:

kubectl get deployment web-app -o yaml > deployment.yaml

Pero cuando la fuente de verdad es JSON (la respuesta de un webhook de admission controller, la salida del proveedor de Kubernetes en Terraform, el resultado de la reconciliación de un operador personalizado), se requiere una conversión explícita.

Docker Compose y valores de Helm

Los archivos de Docker Compose son YAML por definición. Si tienes la configuración de un servicio almacenada como JSON (quizás desde una API de gestión de configuración o un control plane de service mesh), necesitas YAML antes de poder usarla como archivo de Compose.

Los archivos de valores de los charts de Helm son YAML. Cuando obtienes valores de una fuente externa como Vault o AWS Parameter Store (que devuelven JSON), conviértelos a YAML antes de pasarlos a helm install -f values.yaml.

Playbooks de Ansible

Los playbooks y los inventarios de Ansible son YAML. La salida de las APIs en la nube, los sistemas CMDB o las bases de datos de activos suele llegar como JSON. La conversión a YAML es el primer paso antes de usarla en los playbooks.

Legibilidad y edición

YAML es más amigable para las personas en los archivos de configuración. Elimina el ruido visual de las llaves, los corchetes y las comas. Compara:

JSON:

{
  "server": {
    "host": "0.0.0.0",
    "port": 8080,
    "workers": 4,
    "logging": {
      "level": "info",
      "format": "json"
    }
  }
}

YAML:

server:
  host: 0.0.0.0
  port: 8080
  workers: 4
  logging:
    level: info
    format: json

La versión en YAML tiene menos caracteres, menos puntuación, y la estructura jerárquica se comunica mediante la indentación. Para los archivos que las personas leen y editan con regularidad, esto importa.

Añadir comentarios

JSON no admite comentarios. YAML sí. Si necesitas anotar un archivo de configuración (explicar por qué un valor se ajusta de cierta manera, documentar los valores permitidos o dejar notas para tu equipo), YAML te permite hacerlo directamente:

server:
  host: 0.0.0.0
  port: 8080
  # Aumenta los workers en producción; 4 está bien para staging
  workers: 4

Convertir JSON a YAML suele ser el primer paso antes de añadir este tipo de anotaciones. Los comentarios en sí no pueden venir del JSON: JSON no tiene sintaxis de comentarios. Consulta Cómo añadir comentarios a JSON para conocer soluciones alternativas si necesitas mantener la fuente como JSON.

Cuándo necesitas JSON a YAML: 4 escenarios concretos

Escenario 1: API de Kubernetes a manifiesto en Git

La API de Kubernetes devuelve JSON. Quieres confirmar el deployment en tu repositorio GitOps como YAML:

kubectl get deployment web-app -o json | yq -P '.' > deployment.yaml
git add deployment.yaml && git commit -m "Capture web-app current state"

Escenario 2: Valores de Helm desde Vault

Vault devuelve los secretos como JSON. Helm espera archivos de valores en YAML:

vault read -format=json secret/prod/app | jq '.data.data' | yq -P '.' > values.yaml
helm upgrade --install app ./chart -f values.yaml

Escenario 3: Docker Compose desde la API de un control plane

El control plane de un service mesh devuelve las definiciones de servicios como JSON. Docker Compose necesita YAML:

curl -s https://control-plane/services | jq '.' | yq -P '.' > docker-compose.yml
docker compose up -d

Escenario 4: Inventario de Ansible desde un CMDB

La mayoría de los CMDB (Device42, ServiceNow, NetBox) devuelven JSON a través de REST. Los inventarios de Ansible son YAML:

curl -s https://cmdb/hosts | jq '.hosts' | yq -P '.' > inventory.yaml
ansible-playbook -i inventory.yaml site.yaml

En los cuatro escenarios, la conversión es un solo paso del pipeline y es fácil de automatizar mediante scripts.

Conversores en el navegador frente a la nube: por qué subir archivos de configuración es arriesgado

Muchos conversores online de JSON a YAML afirman tener "procesamiento del lado del cliente", pero en realidad envían tus datos por POST a su servidor. Para los archivos de configuración esto es peligroso, porque las configuraciones a menudo contienen:

  • Tokens de API y credenciales en bloques secret:
  • Cadenas de conexión a bases de datos con contraseñas
  • Claves de acceso a proveedores en la nube (roles IAM, JSON de cuentas de servicio)
  • Nombres de host internos y la disposición de la infraestructura
  • Claves de cifrado y certificados TLS

Aunque el servicio afirme no registrar lo que subes, una sola configuración errónea de su lado filtra tus secretos. El enfoque seguro es la conversión en el navegador, que de verdad nunca envía datos a un servidor.

Esto no es hipotético. En noviembre de 2025, la firma de seguridad watchTowr informó de que JSONFormatter y CodeBeautify, dos de los sitios de formato y conversión online más populares, tenían años de envíos de usuarios guardados y navegables públicamente a través de su función "Recent Links". Los investigadores recopilaron más de 80.000 entradas (más de 5 GB), incluidas credenciales de Active Directory, claves de acceso a bases de datos y a la nube, claves privadas, secretos de CI/CD, tokens JWT y de API, credenciales de pasarelas de pago y exportaciones completas de AWS Secrets Manager, afectando a organizaciones de los sectores gubernamental, bancario, sanitario y aeroespacial (la divulgación de watchTowr). Cualquier cosa que pegues en un conversor que almacene o transmita tu entrada puede quedar expuesta de la misma forma.

Para verificarlo: abre el conversor, abre DevTools, ve a Network, desactiva la red y pega tu JSON. Si la herramienta sigue funcionando, es del lado del navegador. Si se cuelga o da error, está basada en la nube.

La herramienta JSON a YAML de FormatArc sigue funcionando con la red desactivada. También lo hace yq en local. Y cualquier script de Python, Node o Go en tu portátil.

Para los Secrets de Kubernetes, los valores de Helm que contienen tokens de API o cualquier configuración con credenciales, usa siempre un conversor local.

Para conocer un método completo que permite verificar si un conversor online es seguro antes de pegar nada, consulta ¿Son seguros los conversores de JSON online?.

Método 1: herramienta de FormatArc en el navegador (sin subir archivos)

La herramienta JSON a YAML convierte tu JSON a YAML con el formato correcto en segundos, completamente en tu navegador.

  1. Abre el conversor de JSON a YAML.
  2. Pega tu JSON en el panel izquierdo.
  3. Haz clic en Convertir.

Resultado de la conversión de JSON a YAMLResultado de la conversión de JSON a YAML

La herramienta valida tu JSON antes de convertirlo, así que si hay un error de sintaxis (una coma que falta, una llave de más, claves sin entrecomillar) informa del problema con un número de línea. Esto la hace útil como validador de JSON incluso cuando no necesitas la salida en YAML. Consulta Solución de errores de parseo de JSON para conocer los problemas de sintaxis de JSON más habituales.

Como la conversión se ejecuta en tu navegador, puedes pegar credenciales, configuraciones internas o cualquier otro dato sensible sin que se transmita a ningún sitio.

La salida usa una indentación de 2 espacios (el estándar de Kubernetes), conserva el orden de las claves del JSON de entrada y usa el estilo de bloque por defecto (de modo que se ve como YAML normal, no como el estilo de flujo con llaves).

Método 2: yq (el estándar de DevOps)

yq gestiona la conversión de JSON a YAML con la misma limpieza que la dirección inversa:

# Conversión básica
yq -P '.' input.json > output.yaml

# Por tubería desde stdin
cat config.json | yq -P '.' > output.yaml

# Bonito (estilo de bloque); sin -P, la salida puede usar estilo de flujo
yq -P '.' input.json

# Define la indentación (por defecto 2)
yq -P -I=4 '.' input.json

# Extrae un subárbol y conviértelo
yq -P '.spec.template' deployment.json

# Salida multidocumento desde un array JSON
yq -P '.[]' --split-exp 'true' kubernetes-list.json

El flag -P es la forma corta de --prettyPrint, que fuerza el estilo de bloque de YAML. Sin él, yq puede generar el estilo de flujo (que se parece a JSON con menos comillas) para las estructuras anidadas.

Instalación:

# macOS
brew install yq

# Linux (binario)
sudo wget -qO /usr/local/bin/yq https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64
sudo chmod +x /usr/local/bin/yq

# Docker
docker run --rm -i mikefarah/yq -P '.' < input.json > output.yaml

yq con jq para filtrar durante la conversión

# Extrae solo spec.template de un deployment y conviértelo a YAML
jq '.spec.template' deployment.json | yq -P '.'

# O hazlo todo en yq
yq -P '.spec.template' deployment.json

Método 3: Python (yaml.dump y ruamel.yaml)

Uso básico de PyYAML

import json
import yaml

with open("config.json") as f:
    data = json.load(f)

with open("config.yaml", "w") as f:
    yaml.dump(
        data,
        f,
        default_flow_style=False,   # block style (the usual YAML look)
        allow_unicode=True,          # do not escape Unicode characters
        sort_keys=False,             # preserve original key order
    )

Las tres opciones que importan:

  • default_flow_style=False: produce YAML normal, no la forma compacta {a: 1, b: 2}
  • allow_unicode=True: mantiene tal cual el japonés, el latín acentuado y los emoji en lugar de los escapes \uXXXX
  • sort_keys=False: conserva el orden de entrada del JSON (esencial para Kubernetes, donde apiVersion debe ir antes que kind)

One-liner

python3 -c 'import sys, json, yaml; yaml.dump(json.load(sys.stdin), sys.stdout, default_flow_style=False, allow_unicode=True, sort_keys=False)' < input.json > output.yaml

ruamel.yaml para ida y vuelta con comentarios

Si necesitas añadir comentarios al YAML generado o conservar un formato específico:

from ruamel.yaml import YAML
import json

yaml_writer = YAML()
yaml_writer.default_flow_style = False
yaml_writer.preserve_quotes = True
yaml_writer.indent(mapping=2, sequence=4, offset=2)

with open("config.json") as fin:
    data = json.load(fin)

# Add comments programmatically
data.yaml_set_comment_before_after_key("server", before="Web server configuration")

with open("config.yaml", "w") as fout:
    yaml_writer.dump(data, fout)

ruamel.yaml es la elección correcta cuando importan los comentarios: JSON no tiene comentarios, así que cualquier anotación debe añadirse durante o después de la conversión.

Método 4: Node.js (js-yaml)

const fs = require("fs");
const yaml = require("js-yaml");

const data = JSON.parse(fs.readFileSync("config.json", "utf8"));
const ymlText = yaml.dump(data, {
  lineWidth: -1,    // never wrap long lines
  noRefs: true,     // do not emit YAML anchors / aliases
  sortKeys: false,  // preserve input order
  quotingType: '"', // prefer double quotes when quoting is needed
});

fs.writeFileSync("config.yaml", ymlText);

lineWidth: -1 evita que js-yaml ajuste las líneas largas, lo que puede provocar saltos de línea inesperados en las URLs y otros valores largos. noRefs: true desactiva la generación de anclas, algo útil cuando el consumidor es kubectl u otra herramienta que no admite anclas de YAML.

Método 5: Go (gopkg.in/yaml.v3)

package main

import (
    "encoding/json"
    "fmt"
    "os"

    "gopkg.in/yaml.v3"
)

func main() {
    data, _ := os.ReadFile("config.json")
    var obj interface{}
    json.Unmarshal(data, &obj)
    out, _ := yaml.Marshal(obj)
    fmt.Print(string(out))
}

Para conservar el orden de las claves en Go, usa yaml.Node directamente en lugar de interface{}: json.Unmarshal sobre map[string]interface{} no conserva el orden (los mapas de Go se aleatorizan a propósito). Para los manifiestos de Kubernetes, donde el orden importa, esto es un problema:

// Use yaml.Node for explicit ordering
var node yaml.Node
yaml.Unmarshal(data, &node)
out, _ := yaml.Marshal(&node)

Como alternativa, dado que el encoding/json de Go ordena las claves de los mapas alfabéticamente, usa una biblioteca de terceros como github.com/iancoleman/orderedmap para conservar el orden de inserción.

Ejemplo de Deployment de Kubernetes: ida y vuelta de JSON a YAML

Un ejemplo completo del mundo real. Empieza con una definición de deployment en JSON:

{
  "apiVersion": "apps/v1",
  "kind": "Deployment",
  "metadata": {
    "name": "web-app",
    "labels": { "app": "web", "tier": "frontend" }
  },
  "spec": {
    "replicas": 3,
    "selector": { "matchLabels": { "app": "web" } },
    "template": {
      "metadata": { "labels": { "app": "web" } },
      "spec": {
        "containers": [{
          "name": "nginx",
          "image": "nginx:1.25",
          "ports": [{ "containerPort": 80 }],
          "env": [
            { "name": "LOG_LEVEL", "value": "info" }
          ]
        }]
      }
    }
  }
}

Conviértelo con yq:

yq -P '.' deployment.json

Salida:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web
    tier: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.25
          ports:
            - containerPort: 80
          env:
            - name: LOG_LEVEL
              value: info

Observa que apiVersion se mantiene antes que kind, antes que metadata: el orden de las claves se conserva. Con PyYAML y sort_keys=True (el valor por defecto), la salida sería alfabética y kubectl apply seguiría funcionando, pero el diff frente al ejemplo original de Kubernetes se vuelve más difícil de revisar.

Aplícalo: kubectl apply -f deployment.yaml.

Entrecomillado de cadenas en YAML: cuándo "8080" se convierte en 8080

YAML tiene reglas complejas sobre cuándo las cadenas necesitan comillas. Los conversores de JSON a YAML aplican estas reglas a la salida, lo que puede provocar cambios de tipo inesperados.

Los números como cadenas pierden las comillas

Si tu JSON tiene "8080" como cadena (porque la API lo devolvió así), los conversores pueden quitarle las comillas en YAML y convertirlo en un número:

JSON:

{ "port": "8080" }

Después de la conversión (algunas herramientas):

port: "8080"   # good: preserved as string

O bien:

port: 8080     # bad: became a number

yq v4 conserva el tipo original (la cadena sigue siendo cadena). PyYAML con la configuración por defecto también lo conserva. js-yaml lo conserva. El riesgo es mayor con código de conversión escrito a mano que usa heurísticas.

Para forzar el entrecomillado en PyYAML, envuelve los valores:

class QuotedString(str): pass

def represent_quoted(dumper, data):
    return dumper.represent_scalar("tag:yaml.org,2002:str", str(data), style='"')

yaml.add_representer(QuotedString, represent_quoted)

Cadenas que parecen booleanos

{ "active": "yes" }

Después de la conversión (con el esquema de YAML 1.1):

active: yes    # interpreted as boolean true on the next round trip

Un buen conversor las entrecomilla:

active: "yes"

Si controlas el JSON de origen, prefiere true / false / null (los tipos nativos de JSON) en lugar de cadenas como "yes" / "no": así evitas por completo el problema de Noruega.

Cadenas que empiezan con caracteres especiales

Los caracteres especiales de YAML (*, &, !, {, [, >, |, #, @, \``, un -` inicial) necesitan comillas cuando inician un valor:

{ "tag": "*production*" }

Se convierte en:

tag: "*production*"   # quoted because of leading *

Todos los conversores principales gestionan esto correctamente. El riesgo solo aparece con conversores hechos a mano.

Escalares de bloque: | frente a > para cadenas multilínea

JSON representa las cadenas multilínea con secuencias de escape \n. Al convertirlas a YAML, un buen conversor usa la notación de escalares de bloque:

JSON:

{
  "description": "Line one\nLine two\nLine three"
}

Un conversor tiene tres opciones razonables en YAML:

Bloque literal (|): conserva los saltos de línea exactamente

description: |
  Line one
  Line two
  Line three

Cada salto de línea del origen se convierte en un salto de línea en la cadena de salida. Esto es lo que quieres para los mensajes de log, los bloques PEM de certificados y los fragmentos de código incrustados en la configuración.

Bloque plegado (>): une las líneas con espacios

description: >
  Line one
  Line two
  Line three

Esto produce la cadena Line one Line two Line three (los saltos de línea se convierten en espacios, las líneas en blanco se convierten en un único salto de línea). Es bueno para texto largo que debe mostrarse como un párrafo.

Una sola línea entrecomillada

description: "Line one\nLine two\nLine three"

La secuencia de escape literal \n dentro de una cadena entre comillas dobles. Funciona, pero es difícil de leer para más de 2 o 3 líneas.

yq -P usa por defecto | (literal) para cualquier cadena que contenga saltos de línea. PyYAML usa | cuando default_style=None (el valor por defecto) y la cadena tiene un salto de línea. js-yaml usa | por defecto para las cadenas con saltos de línea.

Para forzar un estilo concreto en PyYAML:

yaml.dump(data, default_style='|')   # all strings as literal blocks
yaml.dump(data, default_style='"')   # all strings double-quoted

Para los ConfigMaps de Kubernetes que contienen scripts multilínea o certificados PEM, | es la elección correcta y es lo que produce kubectl create configmap --from-file.

Orden de las claves: conservar apiVersion, luego kind, luego metadata

Los objetos JSON y los mapeos YAML son, técnicamente y según la especificación, no ordenados. En la práctica, todo el mundo espera las claves en un orden con sentido, sobre todo los recursos de Kubernetes, donde la convención sitúa apiVersion primero, luego kind, luego metadata y luego spec.

La mayoría de los conversores conservan el orden de origen:

  • yq (Go yaml.v3): conserva el orden mediante el yaml.Node interno
  • PyYAML con sort_keys=False: conserva el orden (el valor por defecto es sort_keys=True, que ordena alfabéticamente; defínelo de forma explícita)
  • js-yaml con sortKeys: false: conserva el orden
  • ruamel.yaml: conserva el orden por defecto

Ten cuidado con:

  • El sort_keys=True por defecto de PyYAML: ordena todo alfabéticamente, poniendo apiVersion después de kind y rompiendo la convención
  • El unmarshalling de Go con interface{}: aleatoriza el orden (usa yaml.Node en su lugar)
  • Los conversores hechos a mano que construyen un map[string]string y lo emiten: los mapas de Go son aleatorios a propósito

Si confirmas el YAML en Git, la aleatorización de las claves provoca un enorme ruido en los diffs aunque los datos no hayan cambiado. Verifica siempre que tu conversor conserva el orden antes de adoptarlo para flujos de trabajo GitOps.

De un array JSON a YAML multidocumento

Un patrón habitual: tienes un array JSON de recursos de Kubernetes y quieres un único archivo YAML con varios documentos separados por --- (uno por recurso).

Con yq

yq -P '.[]' --split-exp 'true' kubernetes-list.json

Esto produce:

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
---
apiVersion: v1
kind: Service
metadata:
  name: app-service

Guárdalo en un archivo: yq -P '.[]' --split-exp 'true' kubernetes-list.json > resources.yaml. El archivo ya está listo para kubectl apply -f resources.yaml.

Con Python

import json
import yaml

with open("list.json") as f:
    items = json.load(f)["items"]   # adjust path to your array

with open("resources.yaml", "w") as f:
    yaml.dump_all(
        items,
        f,
        default_flow_style=False,
        allow_unicode=True,
        sort_keys=False,
    )

yaml.dump_all emite varios documentos separados por ---.

Con Node.js

const yaml = require("js-yaml");
const fs = require("fs");

const items = JSON.parse(fs.readFileSync("list.json", "utf8")).items;
const ymlText = items.map(item => yaml.dump(item, { lineWidth: -1 })).join("---\n");

fs.writeFileSync("resources.yaml", ymlText);

La unión manual con ---\n, ya que js-yaml no tiene un dumpAll integrado.

Integración en pipelines de CI/CD

GitHub Actions

name: Convert JSON config to YAML for deployment
on:
  push:
    paths: ["config/*.json"]

jobs:
  convert:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install yq
        run: |
          sudo wget -qO /usr/local/bin/yq https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64
          sudo chmod +x /usr/local/bin/yq
      - name: Convert all configs
        run: |
          for f in config/*.json; do
            yq -P '.' "$f" > "${f%.json}.yaml"
          done
      - name: Validate against Kubernetes
        run: |
          for f in config/*.yaml; do
            kubectl apply --dry-run=client -f "$f"
          done
      - uses: stefanzweifel/git-auto-commit-action@v5
        with:
          commit_message: "Auto-convert configs to YAML"

GitLab CI

generate-yaml:
  image: mikefarah/yq:latest
  stage: build
  script:
    - for f in config/*.json; do yq -P "." "$f" > "${f%.json}.yaml"; done
  artifacts:
    paths:
      - config/*.yaml

Jenkins (declarativo)

pipeline {
  agent any
  stages {
    stage('Convert configs') {
      steps {
        sh 'for f in config/*.json; do yq -P "." "$f" > "${f%.json}.yaml"; done'
      }
    }
    stage('Validate') {
      steps {
        sh 'for f in config/*.yaml; do kubectl apply --dry-run=client -f "$f"; done'
      }
    }
  }
}

El pipeline completo (convertir y validar) añade menos de 5 segundos a las ejecuciones típicas de CI.

Un flujo de trabajo práctico para Kubernetes

Este es el escenario más habitual del mundo real. Usas kubectl para obtener un recurso como JSON, lo modificas, lo guardas como YAML y lo confirmas en Git:

# Get the current deployment as JSON
kubectl get deployment web-app -o json > deployment.json

# Edit (or use jq for automated changes)
jq '.spec.replicas = 5' deployment.json > updated.json

# Convert to YAML for your Git repository
yq -P '.' updated.json > deployment.yaml

# Inspect, commit, push
git diff deployment.yaml
git add deployment.yaml && git commit -m "Scale web-app to 5 replicas"

O en un solo pipeline:

kubectl get deployment web-app -o json | jq '.spec.replicas = 5' | yq -P '.' > deployment.yaml

Para modificaciones rápidas en las que no necesitas scripting, pega el JSON en la herramienta JSON a YAML, copia la salida en YAML y guárdala en tu archivo.

Preguntas frecuentes

¿Por qué el puerto 8080 se convierte en una cadena en mi salida YAML?

No lo hace: YAML trata los números sin comillas como números. Lo que a veces ocurre es lo contrario: una cadena JSON "8080" se emite como un 8080 de YAML sin comillas, convirtiéndose en un número en la siguiente ida y vuelta. Para conservar el tipo cadena, asegúrate de que tu conversor entrecomille los valores ambiguos. Tanto yq v4 como PyYAML moderno gestionan esto correctamente.

¿Puedo conservar los comentarios de YAML a lo largo de una ida y vuelta?

No. JSON no tiene comentarios. Si conviertes JSON a YAML y añades comentarios, esos comentarios se pierden en el momento en que vuelves a convertir a JSON. Mantén el YAML como la fuente de verdad si importan los comentarios y usa las soluciones alternativas para comentarios en JSON en el lado de JSON.

¿Por qué PyYAML ordena mis claves alfabéticamente?

El yaml.dump de PyYAML usa sort_keys=True por defecto. Define sort_keys=False para conservar el orden de entrada. Esto importa para los recursos de Kubernetes, donde la convención sitúa apiVersion primero.

¿Puedo convertir Helm values.json a values.yaml?

Sí. La estructura de los valores es idéntica, solo difiere el formato. Usa yq -P '.' values.json > values.yaml. Verifica el resultado con helm template ./chart -f values.yaml > rendered.yaml para confirmar que los manifiestos coinciden.

¿Por qué mi null de YAML aparece como ~?

YAML tiene varias representaciones para null: null, Null, NULL, ~, o simplemente un valor vacío. Los distintos conversores eligen representaciones diferentes. yq usa null, PyYAML usa nada por defecto (vacío), js-yaml usa null. Todas son equivalentes, solo es cosmético. Para forzar una representación concreta:

yaml.add_representer(type(None), lambda d, _: d.represent_scalar("tag:yaml.org,2002:null", "null"))

¿Se conservan las anclas de JSON en la salida YAML?

JSON no tiene anclas. Si quieres usar anclas de YAML (&anchor / *alias) en la salida, debes añadirlas manualmente después de la conversión o usar un editor compatible con YAML. ruamel.yaml admite la creación programática de anclas si necesitas automatizar esto.

¿Cómo convierto JSON a YAML sin acceso a internet?

Tres opciones locales: instalar yq (binario de Go, un solo archivo, sin dependencias), usar un script de Python con pyyaml o usar un script de Node.js con js-yaml. La herramienta JSON a YAML de FormatArc también funciona sin conexión una vez cargada la página: la conversión en el navegador significa que no se necesita más acceso a la red.

Ir en la dirección contraria

Para convertir YAML de vuelta a JSON (para enviarlo a una API, depurar o alimentar herramientas que solo aceptan JSON), consulta Cómo convertir YAML a JSON. La herramienta YAML a JSON de FormatArc gestiona la dirección inversa con la misma facilidad.

Guías relacionadas

Resumen

Convertir JSON a YAML aparece constantemente en los flujos de trabajo de DevOps, infraestructura como código y gestión de configuración. Cinco métodos cubren todas las situaciones:

  • Sin instalar nada, datos sensibles: FormatArc JSON a YAML, en el navegador, conserva el orden de las claves, errores de JSON con número de línea.
  • CLI / pipelines: yq -P '.', el estándar de DevOps, admite filtrado y salida multidocumento.
  • Aplicaciones Python: yaml.dump(data, sort_keys=False, default_flow_style=False, allow_unicode=True).
  • Aplicaciones Node.js: js-yaml yaml.dump con lineWidth: -1 y sortKeys: false.
  • Servicios Go: gopkg.in/yaml.v3 Marshal, usando yaml.Node para conservar el orden.

Las cuatro preocupaciones críticas en producción: conservar el orden de las claves (esencial para Kubernetes), gestionar las cadenas multilínea con escalares de bloque (|), dividir los arrays JSON en YAML multidocumento cuando el consumidor lo espera, y vigilar las cadenas sin comillas que parecen booleanos o números y que disparan el problema de Noruega en la siguiente ida y vuelta.