Conversor YAML ⇔ JSON
Convierte entre YAML y JSON. Ideal para cambiar el formato de archivos de configuración y editar manifiestos de Kubernetes, Docker Compose, GitHub Actions y OpenAPI.
Formatos compatibles
- Compatible con YAML 1.2 (usa la librería js-yaml)
- Salida JSON formateada y validada
- Multi-documento（
---separados): solo se convierte el primero - Anchors de YAML（
&/*） también compatibles
Copiado
📖 Dónde se suele tropezar
Convierte entre YAML y JSON con js-yaml, que sigue YAML 1.2, con anclas y alias, documentos múltiples y números de línea en los errores de sintaxis. Todo se ejecuta en el navegador. La dificultad de YAML no está en su sintaxis sino en la coerción de tipos que ocurre en silencio y que nunca pediste: un valor que querías como cadena se vuelve número o booleano, y no salta ningún error, así que buscas la causa sólo cuando algo deja de funcionar.
| Caso | Qué ocurre | Qué hacer |
|---|---|---|
| Un valor pensado como cadena se vuelve número o booleano | YAML adivina el tipo de un valor sin comillas por su aspecto. Las roturas habituales: version: 1.10 se vuelve número y equivale a 1.1; zip: 0070 puede leerse en octal; country: NO, que significa Noruega, es false bajo YAML 1.1; y la clave on: de un flujo de GitHub Actions pasa a ser la clave true bajo 1.1. Esta herramienta sigue YAML 1.2, así que NO y on siguen siendo cadenas, pero PyYAML por defecto y Psych de Ruby aún se comportan como 1.1, de modo que el mismo archivo significa cosas distintas según la implementación. |
Ante la duda, entrecomilla. Entrecomilla siempre números de versión, códigos de país, códigos postales, números con cero inicial, yes, no, on, off, true, false, null, ~ y cualquier valor que contenga : o #. Las comillas no son verbosidad: son una declaración de intención. Si en una revisión te preguntan por qué sólo ese valor va entrecomillado, es una buena pregunta, y la respuesta es que has decidido que ese valor es una cadena. Antes de que un archivo de configuración entre en el repositorio, conviértelo una vez a JSON y lee los tipos con tus propios ojos: ver 1.1 en lugar de "1.1" en la salida de esta página es la señal de alarma. |
| Las anclas y los alias se expanden y desaparecen las referencias | Definir &defaults e incorporarlo con <<: *defaults es una forma potente de quitar duplicación en YAML, pero JSON no tiene ese concepto. Convertir, por tanto, expande de verdad cada fusión y produce un JSON con el mismo contenido repetido una y otra vez. Hasta ahí, lo esperable; el problema es al convertir de vuelta: las anclas no se reconstruyen, y un archivo de configuración escrito de forma DRY se convierte en uno largo y completamente explícito. En archivos que se apoyan mucho en definiciones compartidas, como docker-compose.yml o .gitlab-ci.yml, el número de líneas se multiplica. |
No hagas viajes de ida y vuelta con los archivos de configuración. Edita el YAML como fuente de verdad y genera el JSON sólo como salida final para una máquina: que la CI envíe JSON a una API es exactamente ese caso. Si te entregan un YAML al que ya le faltan las anclas, no hay forma mecánica de restaurarlas: localizas la duplicación a ojo y la factorizas de nuevo a mano. Por eso el repositorio debe dejar claro cuál es el archivo autoritativo: si versionas el JSON generado, colócalo bajo algo como generated/ o encabézalo con un comentario de generado automáticamente, no editar, y los accidentes desaparecen. |
| No consigues encontrar el error de sangría | YAML no admite tabuladores como sangría: basta con que se cuele uno por la configuración del editor para que falle sin remedio, y en pantalla no se distingue de los espacios. Peor es la línea a la que apunta el error: un analizador de YAML informa de la línea donde detectó la contradicción estructural, de modo que el fallo real suele estar varias, o varias decenas, de líneas más arriba. En un manifiesto de Kubernetes muy anidado, por eso te dicen que el error está en la línea 120, buscas desde la 118 y no encuentras nada. | Empieza por activar la conversión de tabuladores en espacios en tu editor; poner [*.yml] indent_style = space en .editorconfig protege a todo el equipo. Al perseguir un error, lee hacia arriba desde la línea indicada, buscando el punto donde la sangría se desvía un nivel. Además, la sangría de listas admite dos estilos —el - en la misma columna que el padre o dos espacios más adentro— y ambos son correctos, pero mezclarlos en un archivo es como las personas acaban leyéndolo mal. Meter yamllint en la CI detecta esta clase de problema en el momento de escribirlo, lo que sale muchísimo más barato que descubrirlo en ejecución. |
Cuando analices en el servidor un YAML de origen externo, usa siempre el cargador seguro. yaml.load() de Python puede construir objetos Python arbitrarios, así que darle un documento manipulado lleva a ejecución de código: usa yaml.safe_load(). js-yaml hizo del comportamiento seguro el valor por defecto en la v4, pero los proyectos con versiones antiguas deben indicar safeLoad explícitamente. Esta página se ejecuta en el navegador y equivale al modo seguro, así que aquí no es un problema. Segundo, atención a los documentos múltiples: Kubernetes mete varios recursos en un archivo separados por ---, y JSON no tiene noción de documentos múltiples, así que pasan a ser un array. Olvida restaurar los separadores --- a la vuelta y kubectl apply lo rechaza, quejándose de que un array no es un Kind válido: si tu cadena de trabajo pasa por una conversión, asegúrate de probar este caso.
📖 Cómo usar
-
1
Pega la entradaPega YAML o JSON a la izquierda; la derecha se actualiza.
-
2
Cambia la direcciónElige dirección y sangría.
-
3
Revisa erroresLos errores muestran línea y motivo.
❓ Preguntas frecuentes
¿Soporta anchors y aliases?
¿Multi-documento?
¿Funciona con Docker Compose / K8s?
¿El bug Norway de YAML?
🐛 ¿Encontró un problema con esta herramienta?
Gratis, sin registro. Incluso solo los pasos para reproducir ayudan. Los informes van directamente al operador y se usan para corregir.
¡Gracias por tu reporte!
Tu reporte llegó al operador y se usará para mejorar.