Convertir YAML a TOML Online
Convierte configuración YAML a TOML, gratis, en tu navegador.
title = "My Project" version = "1.0.0" [server] host = "localhost" port = 8080 [database] host = "db.example.com" name = "myapp"
Casos de uso
De Docker y GitHub Actions a Rust y Hugo
Jekyll→Hugo migration
Convierte front matter YAML de Jekyll a TOML para migrar contenido a Hugo.
Python moderno
Extrae configuración de YAML para adaptarla a pyproject.toml con el estándar PEP 621.
100% privado
Tu YAML nunca sale de tu navegador. Sin servidores, sin registro.
Instantáneo
Conversión en tiempo real con detección inmediata de errores de sintaxis YAML.
Cómo funciona
Tres pasos, sin complicaciones
Pega tu YAML
Pega el YAML en el editor. Soporta docker-compose.yml, GitHub Actions workflows, Ansible playbooks y cualquier YAML 1.2 válido.
Conversión a TOML
El conversor transforma mapas y listas YAML a secciones y arrays TOML. Todo ocurre en tu navegador, sin subir archivos.
Copia o descarga el TOML
TOML resultante listo para Cargo.toml, pyproject.toml, Pipfile, hugo.toml o cualquier herramienta que acepte TOML v1.0.
Preguntas frecuentes
¿Tienes dudas?
Los escenarios más comunes son: migración de proyectos Python de requirements.txt + setup.cfg (formato legacy) a pyproject.toml (estándar moderno definido por PEP 517/518/621), donde parte de la configuración puede existir en YAML (como los workflows de CI/CD) y quieres normalizar las secciones de configuración a TOML. También es frecuente en la migración de sitios Jekyll (YAML front matter) a Hugo (TOML front matter preferido). Por último, equipos que adoptan Rust a menudo tienen configuraciones de CI/CD en YAML (GitHub Actions) que necesitan reflejar en Cargo.toml para gestionar features o workspace members.
docker-compose.yml define servicios, redes y volúmenes en YAML. Aunque no existe un equivalente TOML nativo para Docker Compose (Docker solo acepta YAML para su formato de Compose), convertir docker-compose.yml a TOML puede ser útil como representación intermedia: algunos proyectos Rust usan TOML como configuración de infraestructura propia (por ejemplo, configuraciones de servidores con tokio, actix-web o tauri), y tener la misma estructura de servicios en TOML facilita la integración. La conversión genera TOML válido con secciones [[services]] para arrays de objetos.
Los workflows de GitHub Actions (.github/workflows/*.yml) tienen una estructura específica (on, jobs, steps) que no se corresponde directamente con la estructura de pyproject.toml ([project], [tool.X], [build-system]). Sin embargo, es frecuente querer extraer partes del workflow (como la matriz de versiones de Python, las dependencias de test o la configuración de herramientas) para incluirlas en pyproject.toml. Esta herramienta convierte el YAML completo a TOML estructural; a partir del TOML resultante puedes seleccionar y adaptar las secciones relevantes para añadirlas a tu pyproject.toml.
El proceso inverso a Hugo→Jekyll: el front matter YAML de Jekyll está delimitado con --- al inicio y al final del Markdown. Para migrar a Hugo con front matter TOML, extrae el bloque YAML entre los ---, conviértelo a TOML con esta herramienta, y reemplaza los delimitadores --- por +++. Los campos comunes (title, date, tags, categories, draft) se traducen directamente. Los permalinks de Jekyll y los layouts específicos pueden necesitar mapeo manual a los equivalentes Hugo (url, type, layout).
Algunas características de YAML no tienen mapeo directo a TOML. Los anclajes y alias YAML (&anchor y *alias) son resueltos antes de la conversión, de modo que el TOML resultante contiene los valores expandidos, no las referencias. Los documentos múltiples YAML (separados por ---) no tienen equivalente en TOML, que es siempre un documento único. Las claves con tipos especiales (fechas como claves de mapa, claves con caracteres especiales) pueden requerir entrecomillado en TOML. Los valores null YAML (~ o null) se representan como cadenas vacías o se omiten en TOML, ya que TOML no tiene un tipo null nativo (TOML 1.0 no incluye null).
El TOML generado es sintácticamente válido según la especificación TOML 1.0 y puede parsearse con toml-rs (el parser de Rust usado por Cargo) u otras librerías TOML estándar. Sin embargo, la compatibilidad semántica con Cargo.toml depende de que el YAML de entrada modele correctamente la estructura de un manifiesto de Cargo: [package], [dependencies], [dev-dependencies], [[bin]], [[lib]], etc. Si tu YAML ya modela esta estructura, el TOML resultante será un Cargo.toml válido. Si viene de una fuente diferente (como docker-compose.yml), el TOML resultante necesitará adaptación manual.
Convertir YAML a TOML: migraciones de Docker y GitHub Actions al ecosistema Rust y Hugo
La conversión de YAML a TOML es un flujo menos común que la dirección inversa, pero tiene casos de uso bien definidos en el ecosistema moderno de desarrollo. El más relevante es la adopción de TOML como estándar de configuración en Python: pyproject.toml, definido por PEP 518 en 2016 y extendido por PEP 517 (sistema de build), PEP 621 (metadatos del proyecto, 2021) y PEP 660 (builds editables), ha reemplazado progresivamente a setup.py, setup.cfg y requirements.txt como la configuración central de proyectos Python modernos. Herramientas como Poetry, Hatch, Flit y PDM usan pyproject.toml como fuente de verdad. Si un proyecto Python existente tiene parte de su configuración en YAML (por ejemplo, las versiones de Python soportadas definidas en el workflow de GitHub Actions, o la configuración de tox en tox.ini/YAML), convertirla a TOML para centralizarla en pyproject.toml es una mejora de mantenibilidad.
En el ecosistema Rust, Cargo.toml es el corazón del proyecto: define el nombre del crate, la versión (siguiendo Semantic Versioning), los autores, la edición de Rust (Rust 2015, 2018, 2021, 2024), las dependencias con versiones semver, los features opcionales del crate, los targets (binarios, librerías, ejemplos, tests, benchmarks) y la configuración del workspace para proyectos monorepo. Cuando un equipo adopta Rust para un servicio nuevo en una infraestructura que ya usa YAML extensivamente (docker-compose.yml para el entorno de desarrollo local, manifests Kubernetes para producción, GitHub Actions para CI/CD), puede necesitar extraer partes de esa configuración YAML para incluirlas en Cargo.toml. El ejemplo más práctico: el workflow de GitHub Actions define la matriz de versiones de Rust a probar (stable, beta, nightly); esa información puede querer reflejarse en el Cargo.toml del workspace.
La migración de contenido entre generadores de sitios estáticos es el escenario más concreto para YAML→TOML. Jekyll, creado por Tom Preston-Werner en 2008 y el motor detrás de GitHub Pages, popularizó el concepto de front matter YAML delimitado por --- en archivos Markdown. Hugo, el generador de sitios estáticos más rápido (escrito en Go, con builds típicos de milisegundos para miles de páginas), adoptó TOML como formato de front matter preferido en sus primeras versiones, aunque también soporta YAML y JSON. Migrar un sitio de Jekyll a Hugo — una migración popular entre desarrolladores que buscan mayor rendimiento en sitios grandes — requiere convertir el front matter YAML de cada archivo Markdown al formato TOML con delimitadores +++. Para un sitio con cientos de posts, esto se automatiza con scripts Python (PyYAML + toml) o Node.js (js-yaml + @iarna/toml), usando esta herramienta para validar la conversión de casos individuales.