YAML to TOML Converter

No. Both formats support `#` line comments, but comments are trivia attached to the source text, not to the data model. The converter parses YAML into mappings, sequences, and scalars, then re-serializes that structure as TOML — any `#` comments in the original YAML are discarded in the process and won't appear in the TOML output.

YAML lets you write a mapping or sequence inline, like `{host: localhost, port: 5432}` or `[web, production]`, as an alternative to multi-line block style. TOML has a direct equivalent — inline tables (`{ host = "localhost", port = 5432 }`) and inline arrays (`["web", "production"]`). Since flow and block YAML parse to the identical data structure, the converter treats them the same way regardless of which style the source file used.

Yes. TOML's spec doesn't require any particular key order for two documents to be considered equivalent, but the converter still emits keys in the order they appeared in the YAML source, since standard parsers (PyYAML, js-yaml, ruamel.yaml) retain document order by default — this keeps diffs against the original file predictable.

TOML restricts unquoted ("bare") keys to ASCII letters, digits, underscores, and dashes. A YAML key like `first name` (a space) or `api.version` (a literal dot, which TOML would otherwise read as nested-table notation) doesn't fit that grammar, so the converter wraps it in quotes instead — producing `"first name" = "Jane"` — which TOML's spec defines as an equally valid alternative to a bare key.

Sí, pero lo que se pierde es la relación, no los datos. Las anclas de YAML (`&nombre`) marcan un bloque para su reutilización, y los alias (`*nombre`) copian ese contenido en otro punto del mismo documento; se usan habitualmente para valores por defecto compartidos, como un ancla `&defaults` fusionada en varias configuraciones de entorno mediante `<<: *defaults`. TOML no tiene concepto de ancla, alias ni clave de fusión, así que antes de generar el TOML el conversor resuelve cada alias a su valor literal expandido. El resultado es equivalente en datos —cada campo conserva el mismo valor—, pero desaparece la "fuente única de verdad": si el bloque del ancla cambia, antes lo actualizabas una sola vez en YAML, mientras que en TOML ahora tienes varias tablas independientes que editar a mano. Los archivos YAML multidocumento (varios documentos separados por `---`) chocan con el mismo límite por una razón distinta: un archivo TOML es exactamente un documento, así que solo sobrevive a la conversión un documento YAML.

Generalmente porque una herramienta concreta exige TOML y no aceptará YAML como sustituto. Cargo, de Rust, lee `Cargo.toml`; Poetry, Hatch y PDM, de Python, leen `pyproject.toml`; Hugo acepta front matter en TOML en los archivos de contenido; y cualquier herramienta construida sobre el crate `toml` de Rust o la librería BurntSushi/toml de Go espera específicamente TOML. Los equipos que ya mantienen su configuración de infraestructura o de CI en YAML —playbooks de Ansible, workflows de GitHub Actions, manifiestos de Kubernetes— a veces necesitan extraer valores concretos (nombres de servicios, puertos, versiones fijadas) de esos archivos y llevarlos a un proyecto o manifiesto de paquete basado en TOML, sin tener que retranscribir a mano cada campo ni revisar comillas y tipos uno por uno. Pasar el fragmento YAML de origen por un conversor es más rápido y con menos margen de error que transcribir manualmente claves anidadas a tablas TOML entre corchetes, sobre todo en bloques de configuración grandes con varios niveles de anidamiento.

YAML es el formato más antiguo, por más de una década: la versión 1.0 se publicó en 2004, obra de Clark Evans, Ingy döt Net y Oren Ben-Kiki, y la revisión actual, YAML 1.2.2, se finalizó en 2021 y define YAML como un superconjunto estricto de JSON. TOML es más reciente y fue creado en 2013 por Tom Preston-Werner, cofundador de GitHub, específicamente para ser un formato de configuración mínimo y sin ambigüedades, una alternativa tanto a la complejidad de YAML como a la falta de estandarización de INI. Cargo, el gestor de paquetes de Rust, fue de los primeros adoptantes y su influencia ayudó a consolidar TOML como la opción por defecto en los manifiestos de paquetes de Rust y, más tarde, de Python. TOML alcanzó su primera versión estable, v1.0.0, en 2021, el mismo año de la última revisión de YAML, así que ambas especificaciones que estás convirtiendo hoy son sus versiones estables más actuales.

No: aunque en algunos puntos se parecen, se diseñaron de forma independiente, y la sintaxis de TOML está más cerca de los archivos INI (encabezados `[sección]`, líneas `clave = valor`) que del estilo de bloque basado en sangría de YAML. TOML no tiene, deliberadamente, distinción entre estilo de flujo y de bloque, ni anclas o alias, ni etiquetas de tipo personalizadas, ni archivos multidocumento: busca que exista exactamente una forma de escribir cualquier estructura dada, que es precisamente lo que permite a este conversor transformar las asignaciones anidadas de YAML en tablas TOML de manera determinista. La relación solo funciona limpiamente en una dirección: cualquier documento TOML válido puede reexpresarse en YAML sin pérdida alguna, pero lo contrario no es cierto, ya que el conjunto de funciones de YAML es un superconjunto estricto de lo que la gramática de TOML es capaz de expresar.

De forma limpia, porque ambos formatos las tratan como tipos nativos y no como cadenas de texto. El esquema núcleo de YAML reconoce escalares de marca de tiempo como `2024-01-15` o `2024-01-15T10:30:00Z` y los etiqueta como fechas en lugar de texto plano; TOML v1.0.0 define cuatro tipos distintos de fecha/hora: fecha-hora con desfase (offset date-time), fecha-hora local, fecha local y hora local, cada uno con su propia gramática. El conversor asigna una marca de tiempo YAML al tipo de TOML que corresponda según los componentes realmente presentes: un `2024-01-15` sin más se convierte en una fecha local de TOML, mientras que una marca de tiempo con `Z` o con desfase `+00:00` se convierte en una fecha-hora con desfase. Ambos formatos siguen el formato RFC 3339 para estos valores, así que no hace falta reformatear la propia cadena de fecha: solo cambia la clasificación de tipo en el lado de TOML.