Skip to main content

TOML to JSON Converter

Convert TOML configuration to JSON format.

Reviewed by · Last reviewed

How to Use the TOML to JSON Converter

  1. Paste TOML into the input pane. A Rust Cargo.toml, a Python pyproject.toml, a Hugo config.toml, or a Black / Ruff configuration section all work.
  2. Select output formatting: 2-space JSON for readability, 4-space for conservative tooling, or minified for wire-format use.
  3. Press Convert. Section headers become nested objects, arrays of tables collapse into JSON arrays, and typed values (integers, floats, dates, booleans) map to their JSON equivalents.
  4. Copy the JSON into a downstream tool that does not speak TOML natively - a JSON Schema validator, a generic config library, or a small script that needs the structured data.

What the Tool Handles

TOML maps cleanly to JSON because both are hierarchical key-value formats. The converter reads the source line by line, maintaining a current-table pointer that starts at the root object. A bare header like [package] creates or selects package as the current table; a dotted header like [tool.poetry] walks to a nested object. Array-of-tables headers [[dependencies]] append a new empty object to the array at that key and make it the current table for the lines that follow. Inline tables { name = "foo", version = "1.0" } produce regular nested JSON objects.

Scalar typing matches the TOML spec. Integer literals keep their radix for display purposes but collapse to decimal in JSON. Floats retain decimal form. Offset date-times (1979-05-27T07:32:00Z) and local date-times become ISO-8601 JSON strings because JSON lacks a native date type. Basic strings ("...") interpret escape sequences, literal strings ('...') do not. Multi-line basic strings trim the first newline if present, matching TOML rules. Booleans are the literal lowercase true and false.

Practical Situations

  • Reading a project\'s Cargo.toml into a script that analyses dependency graphs written in something other than Rust.
  • Feeding pyproject.toml into a JSON-schema-based linter or a publishing pipeline that expects JSON config.
  • Converting Hugo or Zola site configuration to JSON for a static analysis tool.
  • Extracting the [tool.black] or [tool.ruff] section to pass through a JSON-patch based config merger.
  • Debugging a mistyped TOML file by seeing what structure it actually parses to - JSON output makes the shape obvious.
  • Embedding a small configuration into a JavaScript application that already parses JSON at startup.

Things That Can Go Wrong

  • Redefining a table. TOML forbids defining the same table twice. [a] followed later by [a] should be a parse error; a permissive parser might merge them.
  • Mixing dotted keys and table headers. If you wrote a.b.c = 1 and then a [a.b] header, the two styles conflict per spec. Choose one style per section.
  • Date-time without timezone. TOML distinguishes offset, local, and date-only values. JSON loses that distinction - they all become strings. If you need to reconstruct the original type, preserve the raw string and parse it with a TOML-aware library downstream.
  • Integers outside 64-bit range. TOML allows 64-bit signed integers. JavaScript numbers are 64-bit floats, so very large integers (past Number.MAX_SAFE_INTEGER around 9 petabytes) lose precision during parsing.
  • Non-ASCII in bare keys. TOML permits Unicode letters in bare keys. Some downstream tools expect ASCII-only JSON keys; validate the target\'s tolerance before converting.

TOML Specification in a Nutshell

TOML ("Tom\'s Obvious Minimal Language") was created by Tom Preston-Werner, GitHub co-founder. Version 1.0.0 was frozen in January 2021 and is specified at toml.io/en/v1.0.0. The design goal is a config format that is obvious to a human reader, distinguishes between types (unlike plain environment-variable configs), and has a minimal grammar (unlike YAML). Every TOML value is one of: string, integer, float, boolean, offset date-time, local date-time, local date, local time, array, or table. Tables are unordered collections of key-value pairs; arrays of tables let you express lists of similar objects. The conformance test suite at BurntSushi/toml-test is the industry reference for parser correctness.

Alternative Tools

Command-line users have tomljson (part of toml-cli), dasel, and recent versions of yq with TOML support. Python\'s standard library added tomllib in Python 3.11 for reading TOML; tomli_w handles the other direction. Rust projects use the toml crate by Alex Crichton, which is battle-tested. Go has pelletier/go-toml. For production conversions pick one of those because they pass the full conformance test suite; this in-browser tool covers the common 90% of TOML without the edge cases around escapes in multi-line literal strings and extreme date-time precision. For a Cargo.toml or pyproject.toml you want to inspect right now, the web tool is usually enough.

Frequently Asked Questions

Which TOML version does the parser target?

TOML 1.0.0, released in January 2021. Earlier 0.x versions had subtly different rules for keys with dots, how arrays of mixed types were handled, and how dates were represented. If your source came from a pre-1.0 Rust crate or old Cargo file, most things still work but edge cases around mixed-type arrays or non-standard date formats may not convert cleanly. Upgrade the source file if you can.

How are date and time values represented in JSON?

JSON has no native date type, so all four TOML temporal variants (offset date-time, local date-time, local date, local time) become ISO-8601 strings that preserve their original textual form. A local date like <code>1979-05-27</code> becomes the JSON string <code>"1979-05-27"</code>; an offset date-time like <code>1979-05-27T07:32:00-08:00</code> keeps its offset. You can re-parse these with <code>new Date()</code> in JavaScript or <code>datetime.fromisoformat</code> in Python.

Does the converter support arrays of tables?

Yes. The <code>[[servers]]</code> syntax creates a JSON array whose elements are the objects defined between each pair of doubled brackets. This is the pattern Cargo uses for <code>[[bin]]</code> targets and Poetry uses for <code>[[tool.poetry.source]]</code> sources. Each doubled-bracket header starts a fresh object; the keys you set afterward populate it until the next header.

Is the conversion lossy?

In a handful of edge cases yes. Integer values larger than <code>Number.MAX_SAFE_INTEGER</code> (about 9 quadrillion) lose precision because JavaScript uses double-precision floats. Temporal types collapse to strings, losing their native type. Comments disappear because JSON has none. For 99% of real <code>Cargo.toml</code>, <code>pyproject.toml</code>, or Hugo configs, these limits do not bite.

Does any of my TOML leave the browser?

No. The converter runs inside a Preact component bundled with the page; clicking Convert invokes a local JavaScript function. There is no fetch call to a remote service, and the input is not logged anywhere. That matters because TOML configs frequently contain access tokens, API keys, and SSH endpoints that you would not want to send to an anonymous service.

What happens with inline tables inside arrays?

An inline table <code>{ a = 1, b = 2 }</code> inside an array becomes a plain JSON object inside a JSON array. Inline tables are fully immutable in TOML 1.0.0 - you cannot add keys to them after the closing brace - but that does not affect the JSON output because JSON has no mutability concept at parse time.

How are multi-line strings handled?

Multi-line basic strings (<code>"""..."""</code>) interpret backslash escapes and trim the first newline if it immediately follows the opening quotes. Multi-line literal strings (<code>&#39;&#39;&#39;...&#39;&#39;&#39;</code>) preserve their contents including backslashes. Both end up as standard JSON strings with any embedded newlines represented as <code>\\n</code> escapes.

Can I convert JSON back to TOML with the same tool?

Not on this page. JSON to TOML is a separate conversion because TOML's structure (tables, arrays of tables, dotted keys) does not map one-to-one from JSON's simpler object/array model. There are choices to make - should a deeply nested object be a dotted header or a series of nested tables? Use <code>tomlkit</code> or <code>tomli_w</code> in Python for that direction.

What is the difference between a dotted key and a section header?

Both produce nested JSON objects but look different in source. <code>a.b.c = 1</code> at the top level is a dotted key that creates <code>{"a":{"b":{"c":1}}}</code>. A section header <code>[a.b]</code> followed by <code>c = 1</code> produces the same structure but scopes subsequent keys to the <code>a.b</code> namespace. In the converter both round-trip to identical JSON.

Why would I use TOML over YAML or JSON?

TOML splits the difference: a stricter, more readable grammar than YAML (no indentation rules, fewer gotchas) and richer types than JSON (dates, multi-line strings). It is also less ambiguous - TOML has one way to express most things, while YAML has several. That is why the Rust ecosystem standardised on it for Cargo and why PEP 621 adopted it for <code>pyproject.toml</code>. The trade-off is less widespread library support than JSON or YAML.

More Developer Tools

Base64 Encoder & Decoder

Encode UTF-8 text to Base64 online or decode Base64 back to UTF-8 and plain text. Runs in your browser with no upload.

Open tool

Bulk URL Encode / Decode

Encode or decode many URLs at once. Paste a newline-separated list and the tool processes each line in parallel, preserving order and blank lines.

Open tool

Code Screenshot

Create beautiful code snippet images with customizable themes.

Open tool

Color Converter

Convert colors between HEX, RGB, HSL and CMYK formats.

Open tool

Cron Expression Parser

Parse cron expressions into human-readable schedules with next run times.

Open tool

CSS Formatter / Minifier

Format, beautify and minify CSS code.

Open tool