TOML to JSON converter

What does the TOML-to-JSON converter do?

The converter reads TOML 1.0 and emits one of three target formats — JSON, JSON5 or YAML — depending on what the result is for. Unlike typical converters that flatten every TOML value into a plain JSON stream, this converter preserves the structural information that distinguishes TOML from JSON: four datetime types, comments, and traceable hierarchy.

Pure-client. Every input stays in your browser. No signup, no server upload, no tracking — you can verify this in the browser dev tools’ Network tab yourself.

Three properties set it apart from standard converters:

• Datetime sidecar. The four TOML datetime types (with/without timezone, date-only, time-only) are preserved via a {$type, value} wrapper — the reverse JSON→TOML direction restores the right format.
• Comment preservation. Pick JSON5 as the output and flip the comment toggle to keep TOML’s # comments as // lines at the right JSON5 positions.
• Cargo / pyproject hints. If your TOML is a Cargo manifest or pyproject.toml, the converter surfaces sanity hints — required fields, unknown keys — without blocking the file.

How does datetime fidelity work?

TOML 1.0 distinguishes four datetime types; JSON only has strings. Example: 2026-05-17 is in TOML a LocalDate, meaning “this day, no timezone context”. 2026-05-17T14:30:00+02:00 is an OffsetDateTime, meaning “this moment in Berlin summer time”. 14:30:00 is a LocalTime, meaning “this clock time, no date”. If you convert these four types to JSON without special handling, they are all just strings — the distinction is lost, the reverse direction is no longer unambiguous.

The datetime sidecar toggle solves that. When active, every datetime value is wrapped in a small wrapper object: {"$type":"toml/local-date","value":"2026-05-17"}. JSON consumers can read the wrapper if they want, or just grab .value. On the JSON→TOML path, the converter spots the $type field and restores the correct TOML syntax.

If you do not need the sidecar — for example because the JSON is read by hand or feeds a database that accepts ISO strings — disable the toggle. Then all four datetime types become plain ISO strings, with the trade-off of information loss.

JSON, JSON5 or YAML — which format fits?

JSON is the default. For machine-to-machine communication, REST APIs and data pipelines it is the right choice. The output is byte-clean, JSON-spec-compliant and readable by every parser.

JSON5 is a practical extension of JSON syntax that allows comments, trailing commas and unquoted object keys. Many build tools (TypeScript tsconfig.json, Babel config, Webpack config) read JSON5 natively. If you convert TOML to JSON5 and enable the comment toggle, you get a file with the same structural content as the TOML original plus all # comments as // lines. Useful if the file lives on inside a JSON5-aware build tool.

YAML is the most popular alternative to TOML for configuration. If you want to migrate from TOML to YAML (Kubernetes configs, Ansible playbooks, GitHub Actions workflows), pick YAML as the output. The converter automatically strips the datetime sidecars, because YAML does not distinguish the four timestamp types — you get plain ISO strings in the YAML output.

One migration tip: TOML → JSON5 is lossless (with sidecar + comments). TOML → YAML loses the datetime-type information. If you “just want to take a peek at YAML”, YAML is fine — if you want to truly migrate, check the datetime fields by hand.

How do the Cargo.toml and pyproject.toml hints help?

When the converter spots a [package] block (Rust) or a [project] block (PEP 621), it surfaces a hint banner. The banner is non-blocking — it does not dictate what your manifest must look like, it only flags oddities.

Cargo hints (per the Cargo Manifest Reference):

• Missing name or version in [package] — both are mandatory.
• Wrongly typed edition — should be a string like "2021", not an integer.
• Unknown top-level keys outside the canonical Cargo tables ([dependencies], [dev-dependencies], [build-dependencies], [features], [workspace], [bin], [lib], [profile], [patch], [badges]).

pyproject hints (per PEP 621):

• Missing name in [project] — mandatory.
• Missing version without a dynamic = ['version'] entry — one of the two is required.
• Missing requires-python — recommended, not mandatory.
• Unknown top-level keys outside [project], [build-system], [tool], [dependency-groups].

The point of this feature: a fast sanity check while writing or editing a manifest, without you having to run cargo check or python -m build --dry-run locally. When a hint shows up, you know immediately what you forgot.

How does the hierarchy tree visualise the TOML structure?

TOML’s biggest UX weakness is readability of nested tables. [server.database.replica] looks at first glance like three separate tables, but is one deeply nested hierarchy. With many [[products]] entries you quickly lose track of which value sits in which element.

The hierarchy tree in the side panel fixes that. As soon as TOML is parsed, the tree shows the complete structure as a collapsible tree with type badges: str, int, float, bool, table, aot[] for array-of-tables, dt+offset / dt / date / time for the four datetime types. With aot[] the individual array elements show up as products[0], products[1] — you see immediately which element carries which property.

Long strings are truncated in the preview ("Lorem ipsum..." → "Lorem ipsum dolor sit am…") so the tree stays readable. Nested tables are collapsible.

What is deliberately not built

• No TOML validation against full schemas. Cargo and pyproject hints are heuristics — not full manifest validation. If you need that, run cargo check or validate-pyproject locally. This tool is a converter, not a linter.
• No TOML auto-formatter. Key sorting, table grouping, whitespace reformatting — all jobs a dedicated formatter solves better. The converter respects the input structure, it does not reformat it.
• No v0.5 backwards-compat mode. TOML 0.5 had a few quirks (homogeneous arrays, different datetime syntax). We parse strict v1.0 and pass tolerant error hints up — if you still have a v0.5 file, upgrade it to v1.0 (the spec has been stable since 2021).
• No server-side big-file pipeline. Pure-client means the file is processed locally. Up to about 10 MB this is unproblematic in every modern browser. Larger TOML files almost never exist in practice — that is not a typical TOML use case.
• No syntax-preserving AST edit UI. If you want to edit TOML programmatically and keep the exact original formatting (e.g. the same whitespace conventions), use a TOML editor like Taplo locally. We parse to an AST and re-emit — whitespace preservation is not a goal.

Where can I read more?

• TOML 1.0 specification — the official spec
• TOML on Wikipedia — history and properties
• JSON5 specification — the JSON extension with comments
• Cargo Manifest Reference — Rust manifest spec
• PEP 621 — the pyproject.toml standard
• validate-pyproject — full PEP 621 validation