YAML a JSON
Convierta YAML al formato de llaves que leen las aplicaciones, o al revés: en el ejemplo, un bloque de servidor con host example.com y puerto 8080 mantiene su anidación, y 8080 sigue siendo número. Los comentarios que no sobreviven se avisan, no se pierden en silencio. Gratis en su navegador.
- Gratis
- Funciona en su navegador
- Sin registro
- Sus datos no salen de su equipo
Ejecutar — gratis
Corre en su navegador. Gratis y sin límite: sus datos no salen de esta página.
en ambos sentidos, gratis en la web
Dos maneras de escribir los mismos datos
El YAML, publicado por primera vez en 2001, se diseñó para que las personas lo lean y lo editen: sangrías en lugar de llaves y espacio para comentarios junto a cada ajuste. El formato de llaves que leen la mayoría de las aplicaciones es lo contrario: estricto y cómodo para los programas, pero pesado de editar a mano. Los manifiestos de Kubernetes, los flujos de GitHub Actions y los archivos de docker-compose son YAML, y los paneles, validadores y editores de configuración pensados para el otro formato no pueden leerlos directamente. Muchas configuraciones nacen además en el formato de llaves y tienen que convertirse en YAML en cuanto llegan a un proceso de despliegue que solo habla YAML. Un único conversor cubre los dos viajes.
Qué sobrevive a la conversión y qué no
La estructura y los tipos viajan intactos. En el ejemplo, el grupo del servidor conserva dentro su host, example.com, y su puerto, 8080; el puerto sigue siendo un número y el ajuste activo sigue siendo verdadero. Con los comentarios es distinto: el formato de llaves no tiene sitio para ellos, así que no pueden acompañar a los datos. En vez de desaparecer sin avisar, se listan en un breve resumen, junto con ciertos anclajes de YAML que tampoco sobreviven. El sentido de la conversión se deduce de lo que usted pega, o puede fijarlo. La sorpresa clásica es convertir un archivo comentado, devolverlo a YAML y descubrir que las notas ya no están: conserve el YAML original si esos comentarios importan.
Preguntas frecuentes
¿Soporta archivos YAML con varios documentos?
Sí, los archivos YAML con múltiples documentos separados por --- se procesan, convirtiendo cada documento y devolviéndolos en un resultado estructurado.
¿Qué pasa con los comentarios del YAML?
No tienen equivalente en el otro formato, así que no pueden viajar con los datos. En lugar de desaparecer sin aviso, se le informan en un breve resumen, junto con ciertos anclajes que tampoco sobreviven a la conversión.
¿Cómo sabe en qué sentido convertir?
Por lo que usted envía: si pega YAML obtiene el formato de llaves, y si pega el formato de llaves obtiene YAML. Si prefiere no depender de eso, también puede fijar el sentido de la conversión.
¿Los números y los valores verdadero o falso conservan su tipo?
Sí. En el ejemplo, el puerto 8080 sale como número, el ajuste activo sigue siendo un valor verdadero y example.com sigue siendo texto, todo dentro del mismo grupo anidado del servidor.
¿Para qué sirve pasar de un formato al otro?
Los manifiestos de Kubernetes, los flujos de GitHub Actions y los archivos de docker-compose están en YAML, y muchos paneles, validadores y editores de configuración solo leen el formato de llaves. Al revés, una configuración nacida en ese formato debe pasar a YAML para un proceso de despliegue que solo entiende YAML.
Herramientas relacionadas
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/data/yaml-json \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"yaml":"a: 1","json":{"a":1}}'const res = await fetch("https://api.kit.forhosting.com/data/yaml-json", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"yaml": "a: 1",
"json": {
"a": 1
}
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/data/yaml-json",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"yaml": "a: 1",
"json": {
"a": 1
}
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/data/yaml-json", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"yaml":"a: 1","json":{"a":1}}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"yaml":"a: 1","json":{"a":1}}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/data/yaml-json", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Ejemplo de solicitud
{
"yaml": "a: 1",
"json": {
"a": 1
}
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "data.yaml_json",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Límites
max_mb | 25 |
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |
Notas técnicas
YAML se lee de maravilla para las personas y muy mal para casi cualquier herramienta fuera del mundo DevOps, mientras que JSON es justo lo contrario; este endpoint se mueve con limpieza entre ambos en cualquier dirección. Además le dice, con honestidad, qué quedó en el camino: los comentarios de YAML no tienen equivalente en JSON, así que en lugar de desaparecer en silencio, se le informan de vuelta.
Una herramienta, dos direcciones
Un manifiesto de Kubernetes, un flujo de trabajo de GitHub Actions, un archivo docker-compose: todos en YAML, todos ilegibles de forma nativa para un panel, validador o editor de configuración basado en JSON. Al mismo tiempo, buena parte de la configuración de aplicaciones nace en JSON y necesita volverse YAML en el momento en que entra a un pipeline de integración continua que solo habla ese formato. data.yaml_json resuelve ambos viajes en un solo endpoint: envíe YAML y reciba JSON, o envíe JSON y reciba YAML, con la dirección inferida de lo que envía o fijada explícitamente en la solicitud.
Qué pasa con su solicitud
Envíe su documento por POST a /data/yaml-json, y recibirá un task_id de inmediato mientras la conversión corre en segundo plano. Al terminar, el documento convertido —junto con un reporte breve de cualquier elemento propio de YAML que no haya sobrevivido el viaje a JSON, como comentarios y ciertos anclajes— llega por webhook firmado o queda disponible en un enlace firmado válido por 24 horas.
Por qué los comentarios son la excepción honesta
YAML, publicado por primera vez en 2001 y pensado para que las personas editaran archivos de configuración a mano, permite comentarios en línea como una función de primera clase: una línea que empieza con # explicando por qué un valor está configurado de cierta forma. JSON, diseñado exclusivamente como formato de intercambio de datos, no tiene sintaxis de comentarios en absoluto, por diseño, así que no hay adónde llevar ese texto. En lugar de fingir que no se perdió nada, el endpoint reporta qué comentarios existían y aproximadamente dónde, para que sepa exactamente qué cambió en vez de descubrirlo después cuando alguien pregunte adónde se fue la nota explicativa.
Cómo encaja en un flujo automatizado
Los equipos con configuraciones extensas suelen mantener YAML editado a mano como fuente de verdad y necesitan una copia validada en JSON para sus herramientas, o al revés: un almacén de configuración en JSON que necesita exportar YAML legible para un repositorio. Ejecutar esa conversión mediante un endpoint asíncrono y con precio por solicitud permite que un paso de integración continua envíe un archivo, siga con la siguiente etapa y reciba el resultado por webhook sin bloquear el pipeline en el paso de conversión, y un análisis fallido nunca se cobra, lo cual importa cuando los archivos de configuración se editan a mano y ocasionalmente quedan mal formados.
Casos de integración
Herramientas para manifiestos de Kubernetes
Un panel convierte manifiestos de Kubernetes en YAML a JSON para que su validador de esquema JSON y su visor de diferencias los procesen sin un analizador YAML propio.
Exportación de configuración de CI/CD
Una plataforma guarda internamente sus definiciones de pipeline en JSON y las convierte a YAML al exportarlas, para poder subirlas a un repositorio en el formato que espera el ejecutor de integración continua.
docker-compose a JSON para automatización
Una herramienta de infraestructura convierte archivos docker-compose en YAML a JSON para alimentarlos a un script de aprovisionamiento basado en JSON.
Conservar el contexto de comentarios en auditorías
Una herramienta de revisión de configuraciones convierte YAML a JSON para sus verificaciones automatizadas, pero conserva la lista de comentarios reportada para que los revisores sigan viendo las notas humanas originales.
Preguntas técnicas
¿Cómo convierto YAML a JSON con la API?
Envíe su documento YAML o JSON por POST a /data/yaml-json, guarde el task_id devuelto y reciba el documento convertido por webhook o mediante un enlace firmado válido por 24 horas.
¿Es gratis la API para convertir YAML a JSON?
No, no hay plan gratuito ni prueba; cuesta $0.002 por solicitud, y una conversión fallida nunca se cobra.
¿También convierte de JSON a YAML?
Sí, el mismo endpoint convierte en cualquier dirección, detectando el formato de entrada o siguiendo una dirección explícita que usted fije en la solicitud.
¿Qué pasa con los comentarios de YAML al convertir a JSON?
No se pueden representar en JSON, porque JSON no tiene sintaxis de comentarios, así que en lugar de desaparecer en silencio el endpoint informa qué comentarios existían y dónde.
¿Un error de sangría o de formato rompe la conversión?
Un YAML mal formado falla de manera clara con un error que identifica el problema en lugar de adivinar una estructura rota, y no se le cobra por una solicitud fallida.
¿Puedo convertir muchos archivos de configuración por lote?
Sí, envíe una tarea asíncrona por archivo y reciba cada resultado por webhook a medida que termine, lo cual funciona bien para pipelines de integración continua que procesan muchas configuraciones a la vez.
¿Se guardan mis datos YAML o JSON después de la conversión?
No, los archivos de origen y los resultados se eliminan después del período de retención y nunca se usan para entrenamiento.