Convertir JSON a TOML Online
Convierte JSON a TOML (Cargo.toml, Hugo, Netlify) gratis, en tu navegador.
title = "My Project" version = "1.0.0" features = ["async", "json"] [dependencies] serde = "1.0" tokio = "1.28" [[authors]] name = "John" email = "john@example.com"
Casos de uso
JSON a TOML para Rust, Hugo y configuración moderna
Cargo.toml para Rust
Convierte dependencias o configuración JSON al formato de manifiesto estándar de Rust.
Hugo y Netlify
Front matter y configuración de sitios Hugo, netlify.toml y configuraciones de CI/CD.
pyproject.toml (PEP 518)
Migra configuración de proyectos Python desde JSON a pyproject.toml estándar.
100% privado
La conversión ocurre en tu navegador. Tu código y configuración nunca salen de tu dispositivo.
Cómo funciona
Tres pasos, sin complicaciones
Pega o sube tu JSON
Pega el contenido JSON en el editor o sube el archivo .json. Sin registro, sin límites.
Conversión automática
El JSON se convierte a sintaxis TOML válida en tu navegador. Sin servidores, sin envío de datos.
Copia o descarga el TOML
TOML listo para usar como Cargo.toml, configuración de Hugo, netlify.toml o pyproject.toml.
Preguntas frecuentes
¿Tienes dudas?
TOML (Tom's Obvious, Minimal Language) fue creado por Tom Preston-Werner, co-fundador de GitHub, en 2013. Preston-Werner lo diseñó porque encontraba YAML demasiado ambiguo y los archivos de configuración JSON demasiado verbosos e incómodos para editar manualmente. TOML alcanzó la versión 1.0 en enero de 2021 después de años de desarrollo y revisión. Su objetivo es ser un formato de configuración que sea obvio de leer para humanos y fácil de parsear sin ambigüedad para máquinas. Hoy es el formato de configuración estándar del ecosistema Rust (Cargo.toml), el motor de sitios estáticos Hugo, y está definido como formato oficial para metadatos de paquetes Python en PEP 518 (pyproject.toml).
JSON es preciso y universal, pero incómodo para configuraciones escritas a mano: no admite comentarios, requiere comillas en todas las claves y las comas finales están prohibidas. YAML es más legible pero tiene una especificación notoriamente compleja con múltiples formas de expresar lo mismo, y errores de indentación pueden cambiar silenciosamente el significado del archivo. TOML ocupa el punto medio: usa una sintaxis de secciones [tabla] y clave = valor que resulta familiar para cualquiera que haya editado archivos .ini, admite comentarios con #, no depende de la indentación como YAML, y tiene una especificación compacta (la versión 1.0 tiene menos de 5000 palabras). La desventaja de TOML es que no es adecuado para datos profundamente anidados o estructuras de datos de propósito general.
Cargo.toml es el archivo de manifiesto de cada crate (paquete) en Rust. Define el nombre del paquete, la versión siguiendo semver, los autores, la edición de Rust, y las dependencias. La sección [dependencies] es donde se declaran las bibliotecas externas con sus versiones: por ejemplo, serde = { version = "1.0", features = ["derive"] }. Cargo, el gestor de paquetes de Rust, lee este archivo para resolver el árbol de dependencias, descargarlo desde crates.io y compilar el proyecto. Si tienes configuración de dependencias en JSON (por ejemplo, de otra herramienta) y necesitas migrarla a un proyecto Rust, este conversor genera el TOML correcto.
Hugo, el generador de sitios estáticos escrito en Go, soporta tres formatos de front matter para las páginas de contenido: YAML (delimitado por ---), TOML (delimitado por +++) y JSON (delimitado por { }). El front matter TOML en Hugo se ve así: +++\ntitle = "Mi artículo"\ndate = 2024-01-15T10:00:00Z\ntags = ["go", "hugo"]\ndraft = false\n+++. Si tienes front matter en JSON y quieres migrarlo a la convención TOML preferida por muchos temas de Hugo, este conversor hace la transformación en segundos.
pyproject.toml es el archivo de configuración estándar para proyectos Python, definido en PEP 518 (2016) y ampliado en PEP 517, PEP 621 y PEP 660. Reemplaza el antiguo setup.py y setup.cfg con un único archivo declarativo. El comité de Python eligió TOML después de evaluar YAML, JSON y otros formatos: YAML fue descartado por su especificación compleja y comportamientos sorprendentes, JSON por la falta de comentarios. La sección [build-system] define el backend de build (setuptools, flit, hatch, poetry), [project] define los metadatos del paquete, y [tool.ruff] o [tool.mypy] permiten configurar herramientas de desarrollo.
TOML maneja bien la anidación de dos o tres niveles a través de tablas: [database.server] crea un objeto anidado. Para anidación más profunda, TOML usa tablas en línea: { host = "localhost", port = 5432 }. Sin embargo, JSON con objetos anidados de más de tres o cuatro niveles puede volverse verboso y poco natural en TOML. El caso específico que TOML no maneja elegantemente es un array de objetos con múltiples propiedades: en TOML esto requiere la sintaxis [[tabla.array]] con secciones repetidas. Si tu JSON tiene estructuras muy anidadas pensadas para datos, considera si TOML es el formato de destino correcto o si sería mejor usar YAML.
Convertir JSON a TOML: Cargo.toml, Hugo, Netlify y pyproject.toml
TOML (Tom's Obvious, Minimal Language) fue creado en 2013 por Tom Preston-Werner, co-fundador de GitHub, creador de Jekyll (el generador de sitios estáticos que impulsó GitHub Pages y popularizó el concepto de JAMstack antes de que se llamara así) y autor de la especificación Semantic Versioning en semver.org. Preston-Werner diseñó TOML como respuesta directa y articulada a las frustraciones con los formatos de configuración existentes: YAML, a pesar de su legibilidad superficial, tiene una especificación de más de 80 páginas que incluye múltiples formas equivalentes y muchas veces sorprendentes de expresar el mismo dato — tipos implícitos, documentos múltiples, anclas y alias, bloques escalares literales versus bloques de flujo, etc. Un archivo YAML mal indentado puede cambiar completamente su significado sin generar ningún error de parseo, lo que lo hace peligroso en configuraciones de infraestructura. JSON, por su parte, es preciso y universal pero adolece de limitaciones críticas para configuraciones escritas y mantenidas por humanos: no admite comentarios de ningún tipo (una limitación que el propio Douglas Crockford, creador de JSON, reconoció como deliberada para evitar directivas de preprocesador, pero que resulta frustrante en configuración), exige comillas dobles en todas las claves incluso cuando son identificadores simples, prohíbe las comas finales (trailing commas) en arrays y objetos, y no tiene una sintaxis cómoda para representar estructuras de sección jerárquica. TOML resuelve todos estos problemas: usa secciones [tabla] y clave = "valor" que resultan familiares para cualquiera que haya editado archivos .ini o .cfg, admite comentarios con el carácter # al igual que Python y la mayoría de lenguajes de scripting, no depende de la indentación para el significado, tiene soporte explícito para fechas y timestamps como tipo nativo (conformes a RFC 3339), y una especificación completa y sin ambigüedades que alcanzó su versión estable 1.0.0 en enero de 2021 después de ocho años de desarrollo iterativo y revisión pública.
El ecosistema más importante y numeroso de TOML en la práctica es el de Rust y su gestor de paquetes Cargo. Cargo, el sistema de build y gestor de paquetes oficial de Rust (parte del toolchain desde la primera versión estable de Rust en mayo de 2015), usa Cargo.toml como el formato de manifiesto para absolutamente todos los crates — el término que usa Rust para referirse a bibliotecas o binarios empaquetables. El archivo Cargo.toml de un proyecto Rust típico contiene: la sección [package] con nombre, versión (semver obligatorio), authors, edition (2015, 2018 o 2021), descripción, licencia y repositorio; la sección [dependencies] con las dependencias de producción especificando versión y features opcionales; [dev-dependencies] para dependencias solo usadas en tests; [build-dependencies] para scripts de compilación; y [features] para definir funcionalidades opcionales del crate. Crates.io, el registro oficial de paquetes Rust, tiene más de 140.000 crates publicados, cada uno con su Cargo.toml como fuente de verdad de metadatos. Netlify adoptó TOML para su archivo de configuración netlify.toml, que define reglas de build (comando y directorio de publicación), cabeceras HTTP personalizadas, reglas de redirect y rewrite con códigos de estado, configuración de funciones serverless, y variables de entorno por contexto de despliegue (production, staging, branch-deploy). Hugo, el generador de sitios estáticos más rápido disponible — escrito en Go por Steve Francia en 2013, capaz de generar miles de páginas por segundo — usa TOML como uno de los tres formatos de front matter para páginas (junto a YAML y JSON), y muchos temas oficiales y de la comunidad de Hugo usan TOML como formato preferido por su legibilidad en archivos de configuración del sitio.
Python adoptó TOML como el formato oficial de configuración de proyectos a través de una serie de PEPs (Python Enhancement Proposals) que abarcan desde 2016 hasta el presente, representando uno de los cambios más significativos en la infraestructura del ecosistema Python de la última década. PEP 518 (mayo 2016) introdujo pyproject.toml con la sección [build-system] para especificar el backend de build y sus dependencias, eliminando la necesidad de importar setuptools antes de poder instalar las dependencias de build. PEP 517 (septiembre 2017) formalizó la interfaz estándar entre frontends de instalación (pip, build) y backends de build (setuptools, flit, hatch, poetry). PEP 621 (noviembre 2020) estandarizó los metadatos del paquete en la sección [project]: nombre, versión, descripción, readme, licencia, autores y maintainers, clasificadores de PyPI, palabras clave, URL del proyecto, versión mínima de Python en requires-python, dependencias de runtime en dependencies, y dependencias opcionales agrupadas por extra en [project.optional-dependencies]. PEP 660 (2021) añadió soporte para instalación en modo editable mediante el estándar pyproject.toml. Las secciones [tool.nombre_herramienta] permiten a cada herramienta del ecosistema almacenar su configuración en el mismo archivo sin conflictos: [tool.ruff] para el linter y formateador Ruff (el más rápido del ecosistema, escrito en Rust), [tool.mypy] para el verificador de tipos mypy, [tool.pytest.ini_options] para pytest, [tool.black] para el formateador Black, [tool.isort] para la organización de imports, [tool.coverage.run] para el análisis de cobertura de tests. Antes de pyproject.toml, la configuración de un proyecto Python típico estaba fragmentada entre setup.py, setup.cfg, tox.ini, .flake8, mypy.ini y otros archivos de configuración independientes — uno por herramienta, con formatos distintos y a menudo duplicación de metadatos entre ellos. pyproject.toml unificó todo en un único archivo declarativo, legible y anotable con comentarios. Convertir datos de configuración de JSON a TOML es el camino natural cuando esas configuraciones necesitan mantenimiento humano continuo.