Guía
Cómo convertir JSON a YAML sin perder tipos
Aprende a convertir JSON a YAML conservando cadenas, números, booleanos y null, con ejemplos verificables y límites de compatibilidad.
por Tools in a Tab · Publicado el · Revisado el
Respuesta breve
Convertir JSON a YAML sin perder tipos exige conservar el significado de cada
valor, no solo cambiar llaves por sangría. Un booleano debe seguir siendo
booleano, null no debe convertirse en texto y una cadena como "1.0" debe
continuar siendo una cadena aunque parezca un número.
El conversor JSON a YAML de Tools in a Tab aplica estas reglas localmente: valida la entrada, conserva los tokens numéricos y cita las cadenas que podrían reinterpretarse. Esta guía explica qué hace y qué debes comprobar después.
Ejemplo completo: datos iguales, representación distinta
Partimos de una configuración con objetos, una lista y varios tipos de escalares:
{
"servicio": {
"puerto": 8080,
"activo": true,
"version": "1.0",
"fecha": "2026-08-06",
"etiquetas": ["producción", "privado"],
"limite": null
}
}
La conversión produce:
servicio:
puerto: 8080
activo: true
version: "1.0"
fecha: "2026-08-06"
etiquetas:
- producción
- privado
limite: null
Las llaves y comas desaparecen porque YAML utiliza sangría, dos puntos y
guiones para expresar la estructura. Los tipos no cambian: 8080 sigue siendo
un número, true un booleano, null un valor nulo y los valores entre comillas
continúan siendo texto.
Equivalencia de tipos entre JSON y YAML
| Valor JSON | Salida YAML | Qué se conserva |
|---|---|---|
| Objeto | Mapa | Sus pares de clave y valor |
| Array | Secuencia | El orden de sus elementos |
| Cadena | Escalar de texto | Su contenido y su tipo de texto |
| Número | Entero o decimal | Su token original en esta herramienta |
true o false |
Booleano | El valor lógico |
null |
Nulo | La ausencia explícita de valor |
YAML puede representar más construcciones que JSON, pero una conversión desde JSON solo necesita este subconjunto. No hay comentarios, anchors, aliases ni tags en la entrada que se puedan trasladar al resultado.
El conversor conserva el orden en que aparecen las propiedades para que el archivo sea fácil de comparar. Ese orden es una decisión de presentación: no debe utilizarse para dar significado a un mapa YAML. Si el orden forma parte de los datos, represéntalo mediante un array.
Procedimiento seguro de conversión
- Confirma que la entrada es JSON estricto. Los comentarios, las comillas simples y las comas finales no forman parte del formato.
- Convierte el documento completo sin realizar sustituciones globales.
- Revisa las cadenas que se parecen a booleanos, valores nulos, números o fechas.
- Comprueba los números grandes y los decimales con las capacidades del programa que leerá el YAML.
- Valida el resultado en la aplicación de destino. Una sintaxis YAML correcta no garantiza que cumpla su esquema de configuración.
Si el primer paso falla, utiliza el validador JSON para localizar el error antes de convertir. Formatear la entrada es opcional: el formateador JSON puede hacerla más legible, pero no cambia sus tipos.
Cita las cadenas que podrían parecer otro tipo
Los escalares sin comillas pueden resolverse como números, booleanos o valores nulos. Además, algunas aplicaciones utilizan esquemas o reglas propias para fechas y otros valores. Mantener comillas evita que una cadena cambie de tipo.
{
"habilitado": "true",
"vacio": "null",
"codigo": "0042",
"respuesta": "yes"
}
El resultado conserva los cuatro valores como texto:
habilitado: "true"
vacio: "null"
codigo: "0042"
respuesta: "yes"
No retires esas comillas solo para acortar el archivo. "true" y true no
significan lo mismo; tampoco "null" y null. Un código como "0042" es
texto cuando el cero inicial forma parte del identificador.
YAML 1.2 Core considera yes, no, on y off cadenas, a diferencia de
reglas antiguas de YAML 1.1. Aun así, el conversor los cita para que el archivo
sea más robusto ante lectores antiguos o configuraciones distintas.
Los números grandes requieren dos comprobaciones
La primera comprobación ocurre durante la conversión. Tools in a Tab lee el token numérico directamente del JSON, por lo que no redondea el entero ni reescribe el exponente:
{
"id": 9007199254740993123456789,
"umbral": 1.25e+3,
"cero": -0
}
id: 9007199254740993123456789
umbral: 1.25e+3
cero: -0
La segunda comprobación pertenece al consumidor del YAML. La especificación permite enteros de tamaño arbitrario, pero una biblioteca o aplicación puede usar tipos nativos con un rango menor. Los decimales también dependen de la precisión disponible. Si una cifra funciona como identificador y no como cantidad, modelarla como cadena suele expresar mejor su intención.
Conservar el tipo tampoco implica conservar para siempre la escritura exacta.
Un lector puede normalizar 1.25e+3 a otra notación equivalente o mostrar -0
como 0 sin haber convertido el valor en texto.
Arrays, objetos y colecciones vacías
Los arrays mantienen el orden de sus elementos. Los objetos anidados pasan a
mapas y las colecciones vacías se escriben como [] y {} para que no se
confundan con null.
{
"equipos": [
{ "nombre": "api", "roles": [] },
{ "nombre": "web", "roles": ["lector"] }
],
"opciones": {}
}
equipos:
- nombre: api
roles: []
- nombre: web
roles:
- lector
opciones: {}
La sangría define qué valores pertenecen a cada mapa o secuencia. Tools in a Tab usa dos espacios y nunca tabuladores. Si editas después el archivo, mantén una sangría coherente.
Qué no puede conservar una conversión desde JSON
JSON no contiene comentarios, anchors, aliases, tags YAML ni estilos de presentación. El conversor no puede recuperar información que nunca estuvo en la entrada y tampoco debe inventarla.
Los nombres duplicados merecen una revisión aparte. RFC 8259 recomienda que los nombres de un objeto JSON sean únicos, y distintos lectores pueden tratar las repeticiones de manera diferente. La herramienta conserva las apariciones en la salida para no ocultarlas, pero conviene resolver la duplicación en el origen antes de utilizar el YAML.
Una ida y vuelta tampoco conserva espacios, saltos de línea o elección de comillas byte a byte. El objetivo es mantener estructura y tipos, no reconstruir la presentación original.
Comprueba el recorrido inverso
Para una comprobación adicional, pasa el resultado por el conversor YAML a
JSON. En el subconjunto compatible deben
reaparecer objetos, arrays, cadenas, números, booleanos y null con la misma
clasificación.
Esta prueba detecta una cadena que quedó sin comillas o una colección que se indentó incorrectamente. No sustituye la validación de la aplicación final: Docker, Kubernetes, un workflow de CI o cualquier otra herramienta puede exigir propiedades y valores concretos además de sintaxis válida.
Checklist antes de utilizar el YAML
- La entrada original era JSON válido.
- Las cadenas ambiguas siguen entre comillas.
- Los identificadores numéricos están modelados como texto cuando corresponde.
- Los enteros grandes caben en el lector de destino.
- Los arrays conservan el orden esperado.
[],{}ynullno se han confundido entre sí.- No quedan nombres duplicados sin resolver.
- La aplicación de destino acepta la estructura generada.
Privacidad y límites de la herramienta
La conversión se ejecuta dentro de esta pestaña. El contenido no se envía a nuestros servidores, no se añade a la URL y no se guarda en almacenamiento local.
La entrada está limitada a 1.000.000 de caracteres y 100 niveles de anidación para proteger el navegador. Para documentos mayores, utiliza una herramienta local de línea de comandos y revisa igualmente los tipos del consumidor final.
Referencias técnicas
Los tipos de JSON utilizados en esta guía están definidos en RFC 8259. Los mapas, secuencias, escalares y esquemas de resolución se describen en la especificación YAML 1.2.2. Todos los ejemplos se comprueban contra los conversores publicados de Tools in a Tab.