Converter JSON para TOML Online
Converta JSON para TOML (Cargo.toml, Hugo, Netlify) grátis, no seu 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 para TOML para Rust, Hugo e configuração moderna
Cargo.toml para Rust
Converta dependências ou configuração JSON para o formato de manifesto padrão de crates Rust.
Hugo e Netlify
Front matter e configuração de sites Hugo, netlify.toml e configurações de CI/CD.
pyproject.toml (PEP 518)
Migre configuração de projetos Python de JSON para o formato pyproject.toml padrão.
100% privado
A conversão acontece no seu navegador. Seu código e configuração nunca saem do seu dispositivo.
Como funciona
Três passos, sem complicação
Cole ou envie seu JSON
Cole o conteúdo JSON no editor ou envie o arquivo .json. Sem cadastro, sem limites.
Conversão automática
O JSON é convertido para sintaxe TOML válida no seu navegador. Sem servidores, sem transmissão de dados.
Copie ou baixe o TOML
TOML pronto para usar como Cargo.toml, configuração do Hugo, netlify.toml ou pyproject.toml.
Perguntas frequentes
Ficou com dúvidas?
TOML (Tom's Obvious, Minimal Language) foi criado por Tom Preston-Werner, co-fundador do GitHub, em 2013. Preston-Werner o projetou porque achava o YAML muito ambíguo e o JSON muito verboso e incômodo de editar manualmente como formato de configuração. O TOML atingiu a versão 1.0 em janeiro de 2021 após anos de desenvolvimento e revisão. Seu objetivo é ser um formato de configuração óbvio de ler para humanos e fácil de analisar sem ambiguidade para máquinas. Hoje é o formato de configuração padrão do ecossistema Rust (Cargo.toml), do gerador de sites estáticos Hugo e está definido como o formato oficial para metadados de pacotes Python no PEP 518 (pyproject.toml).
O JSON é preciso e universal, mas incômodo para configurações escritas à mão: não permite comentários, exige aspas em todas as chaves e proíbe vírgulas finais. O YAML é mais legível, mas tem uma especificação notoriamente complexa com múltiplas formas de expressar a mesma coisa, e erros de indentação podem alterar silenciosamente o significado do arquivo. O TOML ocupa o meio-termo: usa seções [tabela] e sintaxe chave = valor familiar para qualquer um que já editou arquivos .ini, suporta comentários com #, não depende de indentação como o YAML e tem uma especificação compacta — a versão 1.0 tem menos de 5000 palavras. A limitação do TOML é que não é adequado para dados profundamente aninhados ou estruturas de dados de propósito geral.
Cargo.toml é o arquivo de manifesto de cada crate (pacote) no Rust. Ele define o nome do pacote, a versão seguindo semver, autores, a edição do Rust e as dependências. A seção [dependencies] é onde as bibliotecas externas são declaradas com suas versões: por exemplo, serde com versão 1.0 e a feature derive. O Cargo, o gerenciador de pacotes do Rust, lê esse arquivo para resolver a árvore de dependências, baixar pacotes do crates.io e compilar o projeto. Se você tem configuração de dependências em JSON e precisa migrá-la para um projeto Rust, este conversor gera o TOML correto.
Hugo, o gerador de sites estáticos baseado em Go, suporta três formatos de front matter para páginas de conteúdo: YAML (delimitado por ---), TOML (delimitado por +++) e JSON (delimitado por chaves). O front matter TOML no Hugo tem a estrutura com title, date, tags e draft separados por quebras de linha entre os delimitadores +++. Se você tem front matter em JSON e quer migrá-lo para a convenção TOML preferida por muitos temas do Hugo, este conversor faz a transformação em segundos.
pyproject.toml é o arquivo de configuração padrão para projetos Python, definido no PEP 518 (2016) e ampliado pelos PEP 517, PEP 621 e PEP 660. Ele substitui o antigo setup.py e setup.cfg por um único arquivo declarativo. O conselho diretivo do Python escolheu TOML após avaliar YAML, JSON e outros formatos: o YAML foi descartado pela especificação complexa e comportamentos surpreendentes; o JSON, pela falta de comentários. A seção [build-system] define o backend de build (setuptools, flit, hatch, poetry), [project] define os metadados do pacote, e seções como [tool.ruff] ou [tool.mypy] configuram ferramentas de desenvolvimento.
O TOML lida bem com dois ou três níveis de aninhamento por meio de tabelas: [database.server] cria um objeto aninhado. Para aninhamento mais profundo, o TOML usa tabelas inline. No entanto, JSON com objetos aninhados com mais de três ou quatro níveis pode ficar verboso e pouco natural em TOML. O caso específico que o TOML não trata elegantemente é um array de objetos com múltiplas propriedades: o TOML exige a sintaxe [[tabela.array]] com seções repetidas. Se o seu JSON tem estruturas muito aninhadas para dados em vez de configuração, considere se TOML é o formato de destino correto ou se YAML seria mais adequado.
Converter JSON para TOML: Cargo.toml, Hugo, Netlify e pyproject.toml
TOML (Tom's Obvious, Minimal Language) foi criado em 2013 por Tom Preston-Werner, co-fundador do GitHub, criador do Jekyll (o gerador de sites estáticos que impulsionou o GitHub Pages e popularizou o conceito de JAMstack antes de ter esse nome) e autor da especificação de Versionamento Semântico em semver.org. Preston-Werner projetou o TOML como resposta direta e articulada às frustrações com os formatos de configuração existentes. O YAML, apesar de sua legibilidade superficial, tem uma especificação de mais de 80 páginas que inclui múltiplas formas equivalentes e muitas vezes surpreendentes de expressar o mesmo dado — tipagem implícita, múltiplos streams de documento, âncoras e aliases, escalares literais versus blocos de fluxo, e mais. Um arquivo YAML com indentação incorreta pode mudar completamente seu significado sem gerar nenhum erro de análise, tornando-o perigoso em configurações de infraestrutura. O JSON, por sua vez, é preciso e universal, mas tem limitações críticas para configurações escritas e mantidas por humanos: não permite comentários de nenhum tipo (uma limitação que o próprio Douglas Crockford, criador do JSON, reconheceu como deliberada para evitar diretivas de pré-processador, mas que é frustrante em arquivos de configuração), exige aspas duplas em todas as chaves mesmo quando são identificadores simples, proíbe vírgulas finais em arrays e objetos e não oferece sintaxe conveniente para representar estruturas de seção hierárquica. O TOML resolve todos esses problemas: usa seções [tabela] e sintaxe chave = valor familiar para qualquer um que já editou arquivos .ini ou .cfg, suporta comentários com # como Python e a maioria das linguagens de script, não depende de indentação para o significado, tem suporte explícito nativo para datas e timestamps conformes ao RFC 3339 e uma especificação completa e sem ambiguidades que atingiu sua versão estável 1.0.0 em janeiro de 2021 após oito anos de desenvolvimento iterativo e revisão pública.
O ecossistema mais importante e numeroso do TOML na prática é o Rust e seu gerenciador de pacotes Cargo. O Cargo, o sistema de build e gerenciador de pacotes oficial do Rust (parte do toolchain desde o primeiro lançamento estável do Rust em maio de 2015), usa Cargo.toml como o formato de manifesto para todos os crates — o termo do Rust para uma biblioteca ou binário empacotável. Um Cargo.toml típico de projeto Rust contém: a seção [package] com nome, versão (semver obrigatório), autores, edição (2015, 2018 ou 2021), descrição, licença e URL do repositório; a seção [dependencies] com dependências de produção especificando versões e feature flags opcionais (por exemplo, tokio com versão 1 e a feature full); [dev-dependencies] para dependências somente de testes; [build-dependencies] para scripts de build; [features] para definir capacidades opcionais do crate; e [workspace] para gerenciar monorepos com múltiplos crates. O crates.io, o registro oficial de pacotes Rust, tem mais de 140.000 crates publicados, cada um com seu Cargo.toml como fonte autoritativa de metadados. A Netlify adotou TOML para seu arquivo de configuração netlify.toml, que define regras de build, cabeçalhos HTTP personalizados por padrão de caminho, regras de redirecionamento e reescrita com suporte completo a regex e códigos HTTP arbitrários, configuração de funções serverless e Edge Functions, e variáveis de ambiente com escopo por contexto de implantação (production, deploy-preview, branch-deploy). Hugo, o gerador de sites estáticos mais rápido disponível — escrito em Go por Steve Francia em 2013, capaz de gerar milhares de páginas por segundo — usa TOML como um dos três formatos de front matter suportados para páginas de conteúdo (ao lado de YAML e JSON), e muitos temas oficiais e da comunidade Hugo utilizam TOML como formato preferido.
O Python adotou TOML como o formato oficial de configuração de projetos por meio de uma série de PEPs (Python Enhancement Proposals) que abrangem de 2016 até o presente, representando uma das mudanças mais significativas na infraestrutura de build e empacotamento do ecossistema Python em anos. O PEP 518 (maio de 2016) introduziu pyproject.toml com a seção [build-system] para especificar o backend de build e suas dependências de instalação, eliminando o problema de dependência circular onde o setuptools precisava ser importável antes de suas próprias dependências poderem ser instaladas. O PEP 517 (setembro de 2017) formalizou a interface padrão entre frontends de instalação (pip, build) e backends de build (setuptools, flit, hatch, poetry, meson-python). O PEP 621 (novembro de 2020) padronizou os metadados do pacote na seção [project]: nome, versão, descrição, readme, licença, autores e mantenedores, classificadores PyPI, palavras-chave, URLs do projeto, versão mínima do Python em requires-python, dependências de runtime em dependencies e dependências opcionais agrupadas em [project.optional-dependencies]. O PEP 660 (2021) adicionou suporte a instalação editável via o padrão pyproject.toml. As seções [tool.nome_da_ferramenta] permitem que cada ferramenta do ecossistema armazene sua configuração sem conflitos: [tool.ruff] para o linter e formatador Ruff (escrito em Rust, o mais rápido do ecossistema), [tool.mypy] para o verificador de tipos mypy, [tool.pytest.ini_options] para pytest, [tool.black] para o formatador Black, [tool.isort] para ordenação de imports e [tool.coverage.run] para análise de cobertura de testes. Antes do pyproject.toml, um projeto Python típico exigia arquivos de configuração separados para cada ferramenta — setup.py, setup.cfg, tox.ini, .flake8, mypy.ini e mais — muitas vezes com metadados duplicados. O pyproject.toml unificou tudo em um único arquivo declarativo, legível por humanos e anotável com comentários. Converter dados de configuração gerados programaticamente de JSON para TOML é o passo natural quando essa configuração exige manutenção e revisão humana contínua.