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

  1. Confirma que la entrada es JSON estricto. Los comentarios, las comillas simples y las comas finales no forman parte del formato.
  2. Convierte el documento completo sin realizar sustituciones globales.
  3. Revisa las cadenas que se parecen a booleanos, valores nulos, números o fechas.
  4. Comprueba los números grandes y los decimales con las capacidades del programa que leerá el YAML.
  5. 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.
  • [], {} y null no 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.