Convertir TOML a JSON

¿Qué hace el convertidor TOML a JSON?

El convertidor lee TOML 1.0 y emite tres formatos objetivo — JSON, JSON5 o YAML — según para qué deba reutilizarse el resultado. A diferencia de los convertidores típicos que aplastan todos los valores TOML en un flujo JSON plano, este convertidor conserva las informaciones estructurales que distinguen TOML de JSON: cuatro tipos datetime, comentarios y jerarquía comprensible.

Pure-client. Cada entrada queda en su navegador. Sin registro, sin subida al servidor, sin tracking — puede verificarlo con DevTools en la pestaña de red.

Tres propiedades lo distinguen de los convertidores estándar:

• Sidecar datetime. Los cuatro tipos datetime TOML (con/sin zona horaria, solo fecha, solo hora) se preservan mediante wrapper {$type, value} — en el camino JSON → TOML se restaura el formato adecuado.
• Preservación de comentarios. Quien elija JSON5 como salida y active el toggle comentarios obtiene los comentarios TOML # como líneas // en las posiciones JSON5 apropiadas.
• Avisos Cargo/pyproject. Si su TOML es un manifiesto Cargo o pyproject.toml, el convertidor muestra avisos de sanity — campos obligatorios, claves desconocidas — sin bloquear el archivo.

¿Cómo funciona la fidelidad datetime?

TOML 1.0 distingue cuatro tipos datetime, JSON solo conoce strings. Ejemplo: 2026-05-17 en TOML es un LocalDate, o sea « este día, sin contexto de zona horaria ». 2026-05-17T14:30:00+02:00 es un OffsetDateTime, o sea « este momento en horario de verano de Madrid ». 14:30:00 es un LocalTime, o sea « esta hora, sin fecha ». Si convierte estos cuatro tipos a JSON sin medidas especiales, solo son strings — la diferencia se pierde, el camino de vuelta no es unívoco.

El toggle sidecar datetime resuelve eso. Si está activo, cada valor datetime se empaqueta en un pequeño objeto wrapper: {"$type":"toml/local-date","value":"2026-05-17"}. Los consumidores JSON pueden leer el wrapper si quieren, o simplemente extraer .value. En el camino JSON → TOML, el convertidor reconoce el campo $type y restaura la sintaxis TOML correcta.

Quien no necesite el sidecar — por ejemplo porque el JSON se lee a mano o los datos van a una base de datos que acepta strings ISO — desactiva el toggle.

JSON, JSON5 o YAML — ¿qué formato encaja?

JSON es el estándar y el default. Para comunicación máquina-a-máquina, REST-APIs y pipelines de datos es la elección correcta. La salida es bytes-clean, conforme con la spec JSON y legible por cualquier parser.

JSON5 es una extensión práctica de la sintaxis JSON que permite comentarios, comas trailing y claves de objeto sin comillas. Muchas herramientas de build (tsconfig.json TypeScript, config Babel, config Webpack) leen JSON5 nativamente. Si convierte TOML a JSON5 y activa el toggle comentarios, obtiene un archivo con el mismo contenido estructural que el TOML original, más todos los comentarios # como //.

YAML es la alternativa más popular a TOML para archivos de configuración. Quien quiera migrar de TOML a YAML (configs Kubernetes, playbooks Ansible, workflows GitHub-Actions) elige YAML como salida. El convertidor elimina automáticamente los sidecars datetime porque YAML no diferencia los cuatro tipos de timestamp — obtiene cadenas ISO planas en la salida YAML.

¿Cómo ayudan los avisos Cargo.toml y pyproject.toml?

Si el convertidor reconoce un bloque [package] (Rust) o un bloque [project] (PEP 621), muestra un banner de aviso. El banner es no bloqueante — no prescribe cómo debe verse el manifiesto, solo señala anomalías.

Avisos Cargo (según Cargo Manifest Reference):

• name o version faltantes en el bloque [package] — ambos son obligatorios.
• edition mal tipado — debería ser un string como "2021", no un entero.
• Claves top-level desconocidas fuera de las tablas estándar Cargo ([dependencies], [dev-dependencies], [build-dependencies], [features], [workspace], [bin], [lib], [profile], [patch], [badges]).

Avisos pyproject (según PEP 621):

• name faltante en el bloque [project] — obligatorio.
• version faltante sin entrada dynamic = ['version'] — uno de los dos es necesario.
• requires-python faltante — recomendado pero no obligatorio.
• Claves top-level desconocidas fuera de [project], [build-system], [tool], [dependency-groups].

La idea: sanity-check rápido al escribir o editar manifiestos, sin tener que llamar a cargo check o python -m build --dry-run localmente.

¿Cómo visualiza el árbol de jerarquía la estructura TOML?

La mayor debilidad UX de TOML es la legibilidad de tablas anidadas. [server.database.replica] se lee a primera vista como tres tablas separadas pero es una sola jerarquía profundamente anidada. Con muchas entradas [[products]] se pierde rápido la visión general.

El árbol de jerarquía en el panel lateral resuelve eso. En cuanto se parsea el TOML, el árbol muestra la estructura completa como árbol colapsable con badges de tipo: str, int, float, bool, table, aot[] para Array-of-Tables, dt+offset / dt / date / time para los cuatro tipos datetime. En aot[] los elementos del array aparecen como products[0], products[1] — se ve al instante qué elemento lleva qué propiedad.

En cadenas largas se acorta una vista previa ("Lorem ipsum..." → "Lorem ipsum dolor sit am…").

¿Qué no se construye deliberadamente?

• Sin validación TOML contra schemas completos. Los avisos Cargo y pyproject son heurísticas — no validación completa. Quien necesite eso usa cargo check o validate-pyproject localmente.
• Sin auto-fix de formato TOML. Ordenamiento de claves, agrupación de tablas, reformateo de whitespace — tareas que un formatter dedicado resuelve mejor.
• Sin modo backwards-compat v0.5. TOML 0.5 tenía algunos quirks (arrays homogéneos, otra sintaxis datetime). Parseamos estricto v1.0.
• Sin pipeline server-side big-file. Pure-client significa que el archivo se procesa local. Hasta unos 10 MB es sin problema en cualquier navegador moderno.
• Sin UI de edición AST que preserve sintaxis. Quien cambie TOML programáticamente y quiera mantener exactamente el formato original usa un editor TOML como Taplo localmente.

¿Dónde encuentro más detalles?

• Spec TOML 1.0 — la especificación oficial
• TOML en Wikipedia — historia y propiedades
• Especificación JSON5 — la extensión JSON con comentarios
• Cargo Manifest Reference — manifiesto Rust
• PEP 621 — estándar pyproject.toml
• validate-pyproject — validación PEP 621 completa