Convert JSON to TOML Online
Convert JSON to TOML (Cargo.toml, Hugo, Netlify) free, in your browser.
title = "My Project" version = "1.0.0" features = ["async", "json"] [dependencies] serde = "1.0" tokio = "1.28" [[authors]] name = "John" email = "john@example.com"
Use cases
JSON to TOML for Rust, Hugo, and modern configuration
Cargo.toml for Rust
Convert JSON dependencies or config to Rust's standard crate manifest format.
Hugo and Netlify
Front matter and config for Hugo sites, netlify.toml, and CI/CD configuration.
pyproject.toml (PEP 518)
Migrate Python project configuration from JSON to the standard pyproject.toml format.
100% private
Conversion runs in your browser. Your code and config never leave your device.
How it works
Three steps, no hassle
Paste or upload your JSON
Paste JSON content into the editor or upload the .json file. No signup, no limits.
Automatic conversion
JSON is converted to valid TOML syntax in your browser. No servers, no data transmission.
Copy or download the TOML
TOML ready to use as Cargo.toml, Hugo config, netlify.toml, or pyproject.toml.
FAQ
Got questions?
TOML (Tom's Obvious, Minimal Language) was created by Tom Preston-Werner, GitHub co-founder, in 2013. Preston-Werner designed it because he found YAML too ambiguous and JSON too verbose and awkward to edit by hand as a configuration format. TOML reached version 1.0 in January 2021 after years of development and review. Its goal is to be a configuration format that is obvious to read for humans and unambiguously easy to parse for machines. Today it is the standard configuration format for the Rust ecosystem (Cargo.toml), the Hugo static site generator, and is defined as the official format for Python package metadata in PEP 518 (pyproject.toml).
JSON is precise and universal but awkward for hand-written configuration: it does not allow comments, requires quotes on all keys, and trailing commas are forbidden. YAML is more readable but has a notoriously complex spec with multiple ways to express the same thing, and indentation errors can silently change file meaning. TOML occupies the middle ground: it uses [table] section and key = value syntax familiar to anyone who has edited .ini files, supports # comments, does not depend on indentation like YAML, and has a compact spec (version 1.0 is under 5000 words). TOML's limitation is that it is not well-suited for deeply nested data or general-purpose data structures.
Cargo.toml is the manifest file for every crate (package) in Rust. It defines the package name, version following semver, authors, Rust edition, and dependencies. The [dependencies] section is where external libraries are declared with their versions: for example, serde = { version = "1.0", features = ["derive"] }. Cargo, Rust's package manager, reads this file to resolve the dependency tree, download packages from crates.io, and compile the project. If you have dependency configuration in JSON and need to migrate it to a Rust project, this converter generates the correct TOML.
Hugo, the Go-based static site generator, supports three front matter formats for content pages: YAML (delimited by ---), TOML (delimited by +++), and JSON (delimited by { }). TOML front matter in Hugo looks like: +++\ntitle = "My article"\ndate = 2024-01-15T10:00:00Z\ntags = ["go", "hugo"]\ndraft = false\n+++. If you have front matter in JSON and want to migrate it to the TOML convention preferred by many Hugo themes, this converter handles the transformation in seconds.
pyproject.toml is the standard configuration file for Python projects, defined in PEP 518 (2016) and extended by PEP 517, PEP 621, and PEP 660. It replaces the old setup.py and setup.cfg with a single declarative file. The Python steering council chose TOML after evaluating YAML, JSON, and others: YAML was rejected for its complex spec and surprising behaviors, JSON for the lack of comments. The [build-system] section defines the build backend (setuptools, flit, hatch, poetry), [project] defines package metadata, and [tool.ruff] or [tool.mypy] sections configure development tools.
TOML handles two or three levels of nesting well through tables: [database.server] creates a nested object. For deeper nesting, TOML uses inline tables: { host = "localhost", port = 5432 }. However, JSON with objects nested more than three or four levels deep can become verbose and unnatural in TOML. The specific case TOML does not handle elegantly is an array of objects with multiple properties: TOML requires the [[table.array]] syntax with repeated sections. If your JSON has deeply nested structures intended for data rather than configuration, consider whether TOML is the right target format or whether YAML would be more appropriate.
Convert JSON to TOML: Cargo.toml, Hugo, Netlify, and pyproject.toml
TOML (Tom's Obvious, Minimal Language) was created in 2013 by Tom Preston-Werner, GitHub co-founder, creator of Jekyll (the static site generator that powered GitHub Pages and popularized the JAMstack concept before it had that name), and author of the Semantic Versioning specification at semver.org. Preston-Werner designed TOML as a direct and articulated response to frustrations with existing configuration formats. YAML, despite its superficial readability, has a specification of over 80 pages that includes multiple equivalent and often surprising ways to express the same data — implicit typing, multiple document streams, anchors and aliases, literal versus folded block scalars, and more. A YAML file with incorrect indentation can completely change its meaning without triggering any parse error, making it dangerous in infrastructure configuration. JSON, for its part, is precise and universal but has critical limitations for configurations written and maintained by humans: it does not allow comments of any kind (a limitation that JSON's creator Douglas Crockford acknowledged was deliberate, to prevent preprocessor directives, but which is frustrating for configuration files), it requires double quotes on all keys even when they are simple identifiers, it forbids trailing commas in arrays and objects, and it offers no convenient syntax for representing hierarchical section structures. TOML solves all these problems: it uses [table] sections and key = "value" syntax familiar to anyone who has edited .ini or .cfg files, supports # comments like Python and most scripting languages, does not depend on indentation for meaning, has explicit native support for dates and timestamps conforming to RFC 3339, and a complete, unambiguous specification that reached its stable version 1.0.0 in January 2021 after eight years of iterative development and public review.
The largest and most active TOML ecosystem in practice is Rust and its package manager Cargo. Cargo, Rust's official build system and package manager (part of the toolchain since Rust's first stable release in May 2015), uses Cargo.toml as the manifest format for every crate — Rust's term for a packageable library or binary. A typical Rust project's Cargo.toml contains: the [package] section with name, version (semver required), authors, edition (2015, 2018, or 2021), description, license, repository URL, and documentation link; the [dependencies] section with production dependencies specifying version constraints and optional feature flags (for example, tokio = { version = "1", features = ["full"] }); [dev-dependencies] for test-only and benchmark dependencies; [build-dependencies] for build.rs scripts; [features] for defining optional crate capabilities that downstream users can enable; and [workspace] for managing multi-crate monorepos. The Cargo.lock file, generated automatically from Cargo.toml, pins exact dependency versions for reproducible builds. Crates.io, the official Rust package registry, has over 140,000 published crates, each with its Cargo.toml as the authoritative source of metadata. Netlify adopted TOML for its netlify.toml configuration file, which defines build rules (command, publish directory, and functions directory), custom HTTP response headers by path pattern, redirect and rewrite rules with full regex support and arbitrary HTTP status codes, serverless function and Edge Function configuration, and scoped environment variables per deployment context (production, deploy-preview, branch-deploy). Hugo, the fastest static site generator available — written in Go by Steve Francia in 2013, capable of generating thousands of pages per second on commodity hardware — uses TOML as one of three supported front matter formats for content pages (alongside YAML and JSON), and many official and community Hugo themes and starter kits ship their default configuration files in TOML format.
Python adopted TOML as the official project configuration format through a series of PEPs (Python Enhancement Proposals) spanning from 2016 to the present, representing one of the most significant changes to the Python ecosystem's build and packaging infrastructure in years. PEP 518 (May 2016) introduced pyproject.toml with the [build-system] section for specifying the build backend and its own installation dependencies, eliminating the circular dependency problem where setuptools had to be importable before its own dependencies could be installed. PEP 517 (September 2017) formalized the standard interface between installation frontends (pip, build) and build backends (setuptools, flit, hatch, poetry, meson-python). PEP 621 (November 2020) standardized package metadata in the [project] section: name, version, description, readme, license, authors and maintainers, PyPI classifiers, keywords, project URLs, minimum Python version in requires-python, runtime dependencies in dependencies, and optional grouped dependencies in [project.optional-dependencies]. PEP 660 (2021) added editable install support via the pyproject.toml standard. The [tool.tool_name] sections allow each ecosystem tool to store its configuration without conflicts: [tool.ruff] for the Ruff linter and formatter (written in Rust, the fastest in the ecosystem), [tool.mypy] for the mypy type checker, [tool.pytest.ini_options] for pytest, [tool.black] for the Black formatter, [tool.isort] for import sorting, and [tool.coverage.run] for test coverage analysis. Before pyproject.toml, a typical Python project required separate configuration files for every tool — setup.py, setup.cfg, tox.ini, .flake8, mypy.ini, and more — often with duplicated metadata. pyproject.toml unified all of this into a single declarative, human-readable, and annotatable file. Converting programmatically generated JSON configuration data to TOML is the natural step when that configuration requires ongoing human maintenance and review.