Convertir JSON a YAML

PorOleh Soloninactualizado el 25 de septiembre de 2026

Resultado

8 nodos convertidos.

YAML

name: UniTools pais: "NO" version: "1.10" tags:

  - seo
  - calculadoras

anio: 2026

Nodos

Qué ha salido entrecomillado

8 nodos convertidos. 2 valores han salido entrecomillados: «NO», «1.10». Sin las comillas, YAML leería ahí otra cosa que JSON: un booleano, un número o una fecha en lugar de una cadena.

Estado

Convertido. Los valores que YAML leería de otra forma que JSON —no, yes, on, off, números de versión— salen entrecomillados.

El resultado es orientativo y no sustituye a una asesoría profesional.

Convierte JSON en YAML con sangría de 2 o 4 espacios: cuenta los nodos y marca la posición del error.

Un objeto como {"servicio":"api","puertos":[8080,8443],"activo":true} se convierte en cinco líneas: «servicio: api», luego «puertos:» con dos guiones sangrados debajo, y «activo: true». Desaparecen las llaves, los corchetes, las comas y casi todas las comillas; lo que queda sujetando la estructura es la sangría.

El camino de vuelta apenas necesita una herramienta: desde la versión 1.2, YAML es un superconjunto de JSON, así que cualquier JSON válido ya es YAML válido y basta con pegarlo en el analizador. La dirección que sí exige decisiones es esta —cuándo poner comillas a una cadena, cómo escribir un valor con saltos de línea, qué hacer con un objeto vacío— y abajo están explicadas una por una. Si el JSON de entrada no es válido, el estado dice en qué posición se detuvo el analizador y qué hay en ese punto del texto.

Cómo usar la calculadora

Pegue el JSON: en la raíz, lo razonable es un objeto o un array.
Elija la sangría: dos espacios es lo habitual, y cuatro se leen mejor con mucho anidamiento.
Mire en la salida qué valores han salido entrecomillados: ahí YAML habría leído otra cosa que JSON.

Valores que YAML lee de otra forma que JSON

YAML adivina el tipo de un valor por su escritura. Por eso el código de país NO se convierte en el booleano «falso», la versión 1.10 en el número 1,1 y 22:30 en un número en base sesenta. Los datos parecen intactos y no lo están.

La calculadora entrecomilla esos valores y los enumera uno a uno. Quien escribe un YAML a mano no tiene esa lista, y descubre la pérdida cuando falta un cliente noruego en el sistema.

Todas las filas salen de la calculadora de esta página. La última es la contraprueba: una palabra corriente no necesita comillas y no las recibe, porque si no la salida se llenaría de comillas inútiles y nadie miraría las que sí hacen falta.
Valor en el JSON	Sin comillas, YAML leería	Salida de la calculadora
NO	falso (booleano)	"NO"
yes	verdadero	"yes"
off	falso	"off"
1.10	el número 1,1	"1.10"
2026-08-25	una fecha	"2026-08-25"
22:30	el número 1350	"22:30"
null	nada	"null"
Madrid	la cadena Madrid	Madrid

El «problema de Noruega» y otras comillas

El caso famoso: en una lista de países, el código de país de Noruega es NO. Sin comillas, un analizador que siga YAML 1.1 lo lee como el booleano falso y Noruega desaparece del mapa. Lo mismo pasa con yes, on, off y con una Y o una N sueltas. YAML 1.2 redujo los booleanos a true y false, pero bibliotecas muy extendidas siguen aplicando las reglas de 1.1, de modo que estas cadenas salen entrecomilladas.

La otra trampa son los valores que parecen números sin serlo. Una versión escrita 1.10 sin comillas es el número 1.1 y el cero se pierde; 1.2.3 sobrevive porque no es un número, pero 007 se queda en 7 y +34 en 34. En YAML 1.1 una hora como 22:30 llega a leerse en base sesenta, y una fecha como 2026-08-25 deja de ser texto para convertirse en una marca de tiempo. También hay que entrecomillar la cadena vacía y las palabras null, Null y ~ cuando se quieren como texto. Ante la duda, aquí se ponen comillas: sobran a la vista, pero no cambian el dato.

Valores multilínea, vacíos y tabuladores

Un valor con saltos de línea admite tres formas: entre comillas dobles con \n, con la barra vertical, que conserva los saltos tal cual, o con el signo mayor que, que los pliega en espacios. Aquí se usa el bloque literal, sangrado un nivel más que su clave —dos o cuatro espacios, según lo que hayas elegido—, con |- cuando el valor no termina en salto de línea y con | cuando termina en uno, de manera que el texto vuelve idéntico si se convierte de nuevo a JSON. Lo que este conversor no pasa a bloque —un espacio al final de una línea, un retorno de carro, dos saltos finales seguidos, una primera línea ya sangrada— lo escribe entre comillas dobles con \n: se lee peor, pero es exacto. YAML sí tiene recursos de bloque para varios de esos casos, como |+ o el indicador de sangría; las comillas son la vía más segura.

El objeto vacío y la lista vacía no tienen forma de bloque, así que se escriben {} y [] en estilo de flujo. Y la sangría se hace con espacios, nunca con tabuladores: un tabulador al principio de una línea es un error de sintaxis, no una cuestión de gusto. Por eso la única elección disponible es entre dos y cuatro espacios.

Lo que se conserva y lo que se pierde

El orden de las claves se respeta tal como venía, salvo en un caso: el de las claves numéricas. El motor de JavaScript las coloca antes que las demás y en orden ascendente, de modo que un mapa de códigos HTTP escrito 500, 200, 10 sale como 10, 200, 500 y luego el resto, y encima entrecomilladas, porque sin comillas volverían a leerse como números. Con claves de texto no se reordena nada. El contador suma un nodo por cada objeto, cada lista y cada valor escalar, el documento entero incluido: el ejemplo de arriba da seis, no siete, y sirve para comprobar de un vistazo que no se ha quedado nada por el camino.

Los comentarios son la pérdida que conviene tener presente, sobre todo en el sentido contrario: JSON no los admite, así que un YAML comentado que pase por JSON y vuelva llega sin una sola línea de comentario. La otra pérdida ocurre antes de la conversión: si el JSON repite una clave, el analizador se queda solo con la última, y {"a":1,"a":2} sale como «a: 2» sin decir nada. Esta herramienta tampoco genera anclas ni alias, no reutiliza estructuras repetidas, no produce varios documentos separados por --- y no valida contra ningún esquema. Comprueba que el JSON es válido y escribe el YAML equivalente; hasta ahí llega.

Fuentes

Cifras vigentes en 2026. Los resultados son orientativos y no sustituyen el asesoramiento profesional.

Preguntas frecuentes

¿Y en sentido contrario, de YAML a JSON?

Esta herramienta solo va de JSON a YAML. Para el sentido contrario hace falta un analizador de YAML que lea los datos y los escriba como JSON: nombre: Ana pasa a ser {"nombre": "Ana"}. No todo cabe: un YAML con anclas, con fechas, con claves que no son cadenas o con varios documentos no tiene equivalente directo en JSON. Lo que sí vale es lo contrario: desde YAML 1.2, un JSON válido es casi siempre YAML válido.

¿Por qué aparecen comillas en valores que no parecen necesitarlas?

Porque el criterio es no arriesgarse. Cadenas como no, on, off, 1.10, 007, 22:30 o 2026-08-25 cambian de tipo al leerse sin comillas, y no todas las bibliotecas aplican la misma versión del estándar. Unas comillas dobles de más se ven raras y no alteran el valor; un tipo equivocado sí.

¿Sirve la salida para un docker-compose o un flujo de trabajo de GitHub Actions?

La estructura sí: es YAML válido con la sangría que hayas elegido. Lo que la herramienta no hace es comprobar que las claves sean las que espera cada formato —un docker-compose y un flujo de trabajo de GitHub Actions tienen las suyas—, ni devolver los comentarios que suele llevar un archivo de configuración. Valida la entrada y escribe el YAML equivalente; la revisión del contenido corre de tu cuenta.

¿De dónde viene lo del «problema noruego»?

Del código de país NO. En una lista de países que YAML lee sin comillas, ese valor se convierte en el booleano «falso» y Noruega desaparece de la lista sin que salte ningún error. La misma trampa vale para ON (Ontario) y para las respuestas yes y no.

¿Por qué solo va en un sentido?

Porque YAML hace muchas más cosas que JSON: anclas y referencias, etiquetas de tipo, varios documentos en un archivo y tres formas de valor multilínea. Un conversor que entendiera solo una parte funcionaría hasta el primer archivo que se saliera de ella, y por eso aquí no está.

¿Puedo sangrar con tabuladores?

No: YAML prohíbe expresamente el tabulador para la sangría, y es una de las pocas reglas duras del formato. Por eso la calculadora solo ofrece dos y cuatro espacios.

Enlaces útiles

Desarrollo y web Todas las calculadoras

Convertir JSON a YAML

Resultado

También te puede servir

Formateador de JSON

Convertir CSV y JSON

Formateador de SQL

Tamaño de un texto en bytes

Conversor Base64

Generador de enlaces UTM

Enlaces útiles