TOML to JSON Converter

Convert TOML to JSON in your browser

This tool parses TOML configuration and outputs clean, indented JSON — useful for feeding a TOML config into JavaScript code, an API, or any tooling that expects JSON. It targets the TOML constructs people actually paste, all processed locally.

How TOML structures map onto JSON

The built-in parser implements a focused subset of TOML v1.0.0. It reads line by line, handling key = value pairs with basic and literal strings, integers and floats (including underscore separators), and booleans. [table] and [parent.child] headers create nested objects, dotted keys nest the same way, and [[array of tables]] headers append objects to a JSON array. Inline arrays of scalars and # line comments are supported. Constructs it deliberately does not implement — multi-line strings and date/time types — raise a clear error instead of being mis-parsed.

Example

This TOML:

title = "Gera Tools"
version = 6

[owner]
team = "platform"

[[servers]]
name = "eu-1"
port = 8080

becomes:

{
  "title": "Gera Tools",
  "version": 6,
  "owner": { "team": "platform" },
  "servers": [{ "name": "eu-1", "port": 8080 }]
}

When to convert TOML to JSON

TOML is common for developer configuration files because it is easier to read and write than JSON for humans — indentation is not significant, comments are allowed, and multi-line strings look natural. But many downstream consumers only speak JSON: JavaScript fetch calls, REST API bodies, Kubernetes ConfigMaps, and most validation tooling all expect JSON. This converter bridges the gap without requiring a Node.js environment or a Python script.

Common files people convert here include:

• Cargo.toml (Rust package manifests) when extracting dependency metadata into a script or CI pipeline
• pyproject.toml when reading tool configuration with JSON-aware scripts
• Traefik and other infrastructure configs when migrating from TOML to YAML or JSON providers
• Custom application configs when the developer wrote TOML locally but the deployment target reads JSON

Dotted keys and nested tables

TOML’s dotted-key syntax can confuse newcomers. The following three forms all produce the same JSON output:

# Dotted key
database.port = 5432

# Inline table (on a single line)
database = { port = 5432 }

# [table] header
[database]
port = 5432

All three become {"database": {"port": 5432}} in JSON. If you have a file that mixes these styles, the parser handles them consistently without conflicts, as long as the same key is not defined twice (which TOML forbids).

Limitations to know

The parser deliberately excludes TOML date/time types and multi-line strings (both basic """ and literal ''' forms). If your config uses these, the parser raises a clear error rather than silently misrepresenting the value. For full TOML support, use a server-side TOML library and copy the JSON result from there.

Everything runs locally in your browser — your config is never uploaded or stored.

The type that doesn’t survive: datetimes

TOML has first-class datetime values — created = 2026-07-02T09:00:00Z is a typed datetime, not a string — because config files constantly need dates. JSON has no datetime type at all, so conversion must stringify them, typically to their ISO 8601 text form. The information loss is one-way: a round-trip back to TOML cannot know the string was ever a datetime. The same applies to TOML’s distinction between integers and floats where the JSON consumer treats all numbers alike. The authoritative definitions of what each format supports are the TOML specification and RFC 8259 (JSON) — when a conversion surprises you, one of those two documents explains why.

The files you’ll actually convert

In practice this conversion runs against a handful of ubiquitous files: pyproject.toml (Python packaging), Cargo.toml (Rust), netlify.toml and CI configuration. Converting to JSON is the standard move when a build script, JSON-schema validator or jq pipeline needs to inspect project metadata — jq '.project.dependencies' over converted pyproject.toml answers questions no grep can. Because comments and key ordering are commentary rather than data, they vanish in conversion; treat the JSON as a read-only view of the TOML, and make edits in the TOML source where the comments live, never by round-tripping the JSON back.

The conversion is also the quickest TOML debugger: when an application rejects a TOML file with a vague parse error, converting it here shows exactly how each section, dotted key and array-of-tables was understood — a wrongly nested table is immediately obvious in the JSON tree in a way it never is in the flat TOML source.

As with any config translation, convert at build or inspection time rather than maintaining two parallel files by hand — a generated JSON view can never drift from its TOML source, but a hand-maintained copy always does.

One last interoperability note: TOML arrays of tables ([[servers]]) always become JSON arrays of objects, even with a single entry — the TOML syntax is explicit about plurality in a way XML is not, which spares this conversion the single-versus-list ambiguity that plagues XML-to-JSON pipelines.