Data

TOML Converter

Convert TOML into JSON, YAML, XML, JavaScript object literals, or PHP arrays. TOML tables, which correspond to objects or dictionaries, arrays of tables ([[x]]), inline tables, and dotted keys expand into ordinary nested structures, so TOML config files such as Cargo.toml, pyproject.toml, Hugo and Netlify config, wrangler.toml, and ruff or Poetry settings become readable JSON or YAML in one paste. The tool also calls out the two changes that are easiest to miss: TOML date-times have no native equivalent in JSON and are emitted as ISO-8601 strings, while 64-bit integers beyond Number.MAX_SAFE_INTEGER are kept as exact strings so precision is not lost without warning. Parse errors include the line, column, and nearby source. Parsing, conversion, and copying all happen in this browser tab; nothing is uploaded, proxied, or logged on a server.

  • One input feeds five targets — JSON, YAML, XML, JavaScript object literals, and PHP arrays — each with its own per-format options
  • Tables become objects or dictionaries, while arrays of tables ([[servers]]) become ordinary arrays that JSON and YAML tools understand
  • TOML date-times are converted to canonical ISO-8601 strings and flagged, so you can see which values changed from date types into strings
  • Big integers beyond Number.MAX_SAFE_INTEGER are preserved as exact strings instead of rounding, with a warning that points at each value
  • Fully local processing — no upload, no telemetry — safe for production config, secret sample data, and migration drafts
tools/TOML Converter
0 chars
Waiting for input
Conversion result appears here
Actions

Overview

A focused tool for work that starts from TOML. TOML tables as objects or dictionaries, arrays of tables as arrays, inline tables, dotted keys, native date-times, and 64-bit integers are resolved at parse time, so the output is ready for CI pipelines, JSON Schema validators, code generators, or scripts that only accept JSON without a second manual cleanup pass.

  1. 01

    Five target formats out of the box

    TOML to JSON, YAML, XML, JavaScript object literal, and PHP array. JSON and YAML expose indent size and alphabetical key sort; XML lets you set the root name, list-item name, declaration, and pretty-print; JS object literals keep quoted keys and proper escaping; PHP arrays emit a full <?php return [...]; file.

  2. 02

    TOML tables and arrays of tables become objects and arrays

    [section], [nested.section], and [[array.of.tables]] resolve into plain nested objects or dictionaries and arrays during parsing, so Cargo.toml or pyproject.toml can match the JSON shape a build script, linter, or validator expects without manual restructuring of TOML table headers.

  3. 03

    Inline tables and dotted keys expanded

    Inline tables ({ x = 1, y = 2 }) and dotted keys (a.b.c = true) expand into the same nested structure as full [a] sections, so two TOML files that differ only in authoring style can produce the same JSON.

  4. 04

    Date-time handling made explicit

    TOML offset date-times, local date-times, local dates, and local times are converted to canonical ISO-8601 strings, the most reliable representation for JSON, YAML, and XML. The checks panel lists each value so you can see exactly which date-time values became strings.

  5. 05

    64-bit integer precision preserved

    TOML permits signed 64-bit integers; JavaScript numbers stop being exact at 2^53. Values beyond that range are kept as exact strings rather than rounded, and each one is flagged so you can decide whether the next consumer should treat it as a string or a BigInt.

  6. 06

    Runs entirely in the browser

    Parsing, conversion, checks, and copy all happen on this page. Your TOML never leaves through a request to a server, CDN, or third-party analytics platform — safe for production config, secret sample data, and migration drafts.

How to use

The workflow is simple: paste TOML, pick a format, review the checks panel, and copy the result.

  1. 01

    Paste TOML into the input panel on the left. Parsing happens immediately and the checks panel surfaces TOML tables as objects, arrays of tables as arrays, date-time values, and any big-integer warnings.

  2. 02

    Pick a target at the bottom: JSON, YAML, XML, JavaScript object, or PHP array. Each format has its own options, such as indent size, key sort, and XML root name, and the output updates live.

  3. 03

    Read the checks panel. Date-times that become strings and out-of-range integers are flagged but never block conversion; they mark places where the JSON or YAML representation differs from the native TOML type.

  4. 04

    Switch to fullscreen for long config files. Both input and output panes get more room and the editor keeps syntax highlighting, folding, and copy controls.

  5. 05

    Click copy and paste the output into your IDE, snippet manager, CI job definition, or API client (Postman, Insomnia, Bruno) to continue the workflow.

Details

The common pain points in everyday TOML work are handled by default, so you do not need to chain several external tools just to get a clean conversion.

  • Parsing follows the TOML 1.0 specification, so tables as objects, arrays of tables as arrays, inline tables, and dotted keys resolve exactly the way Cargo, Poetry, and Hugo read them.
  • JSON and YAML output preserve key order, with an opt-in alphabetical sort for stable git diffs, code review, and JSON Schema validation.
  • Date-time values become ISO-8601 strings, a representation JSON parsers, YAML loaders, and JavaScript Date can work with directly.
  • XML accepts custom root and item names, declaration, and pretty-print to align cleanly with schemas already in production.
  • JavaScript object and PHP array outputs preserve nesting, escaping, and boolean literals so the result drops directly back into config loaders, test data, or seed scripts.
  • The checks panel summarises structure — tables as objects, keys, and arrays of tables as arrays — so an unfamiliar TOML file becomes legible in seconds.
  • Big-integer and date-time hints appear inline, marking where a later conversion back to TOML would need a string or a typed value to preserve the original meaning.
  • Everything runs locally in the browser — no SaaS backend — so the tool keeps working on a flight, in a VPN-only network, or behind an enterprise proxy.

Use cases

Whenever the source is TOML, the following everyday tasks need less manual copy-paste or line-by-line rewriting.

  1. Read Cargo.toml and Rust workspace manifests

    Convert a Cargo.toml — dependencies, features, workspace members, and [[bin]] targets — into JSON so a build script, dependency audit, or dashboard can consume the manifest programmatically without a TOML parser in the loop.

  2. Inspect pyproject.toml and Python tooling config

    pyproject.toml packs Poetry, setuptools, ruff, black, and mypy settings into one file. Converting to JSON or YAML shows the resolved object shape of each tool section and makes it easy to compare configuration across repositories.

  3. Bridge static-site and edge config to tooling

    Hugo config.toml, Netlify netlify.toml, and Cloudflare wrangler.toml are authored in TOML but often need to be read by scripts, CI steps, or dashboards that expect JSON. One conversion lets TOML remain the source file while avoiding drift between duplicated configs.

  4. Migrate config between TOML, YAML, and JSON

    Moving a project from TOML to a YAML- or JSON-based config? See the converted output first, then refine by hand. The structural diff catches typos that line-by-line retyping introduces.

  5. Feed config into JSON Schema validators

    Many validators and IDE integrations accept only JSON. Convert TOML to JSON, run it through AJV or your editor’s schema tooling, and confirm the config satisfies its schema before it ships.

  6. Sync backend config with frontend test data

    Backends often keep config in TOML while frontend Jest, Vitest, and Storybook tests want JSON or JS objects. Convert and paste — no bespoke transformation script required.

  7. Audit date-time and integer fields before a migration

    TOML date-times and 64-bit integers are exactly the values that change meaning when a config moves to JSON. The checks panel lists them up front so you can decide which fields need to become quoted strings in the target.

  8. Onboarding and code review

    A dense TOML file with deep [nested.tables] and repeated [[arrays]] is hard to read at a glance. Converting to indented JSON or YAML turns those sections into a visual hierarchy that is easier to explain and review.

See also

When the config you are working with started as YAML instead — a Kubernetes manifest, a GitHub Actions workflow, a Docker Compose file, or an OpenAPI spec — and you need to convert it into JSON, TOML, XML, JavaScript object literals, or PHP arrays, reach for YAML Converter , which merges multi-document YAML into an array and expands anchors and merge keys before converting. And when the source is JSON rather than TOML — a minified API response, the JSON view of a Terraform plan, the output of a build tool — and you need the opposite direction back into YAML, TOML, XML, CSV, JS object, or PHP array files, use JSON Converter , where every target carries its own options — YAML indent and key sort, XML root name and attribute mode, CSV delimiter and header row, TOML key sort. If the JSON itself needs a cleanup first — pretty-printing, folding deep nodes, pinpointing a syntax error, or inspecting key statistics before you decide which target to convert into — pass it through JSON Formatter , which supports hierarchical collapsing, error-line highlighting, key search, and depth statistics with the same no-upload guarantee, so the whole path from raw config to validated, review-ready output stays in your browser.

Best practices

TOML is deliberately explicit, but a few habits keep conversions predictable when the target format is less strict about types than TOML is.

  • Decide up front how date-times should be represented after conversion: as ISO-8601 strings (the default here) or as typed values your loader re-parses. Document the choice so a later conversion back to TOML keeps the intended meaning.
  • Treat 64-bit integers — Snowflake IDs, large timestamps, database keys — as strings in any JSON that will be re-read, since JavaScript numbers lose precision beyond 2^53. The checks panel flags the risky values.
  • Remember that TOML has no null. When converting the other direction later, JSON nulls have no TOML equivalent, so model optional fields as omitted keys rather than explicit nulls.
  • After converting TOML to JSON, run the result through json-diff against the previous version to catch unintended field changes before they reach production.
  • Prefer arrays of tables ([[x]], which become arrays) over deeply nested inline tables for anything a human will edit — they convert to the same JSON but stay far more readable in the TOML source.
  • Keep indent size and key-sort settings consistent across a repository so converted output produces stable, review-friendly diffs.
  • When a config feeds a JSON Schema validator, convert to JSON first and validate there; TOML’s own syntax check does not enforce your schema’s field rules.
  • For XML targets, set a meaningful root and item name up front; generic root/item labels make the output harder to use in later steps.

Limitations

Knowing what the tool does not do keeps you from reaching for it as a full config IDE, schema validator, or migration pipeline.

  • No business-schema validation: Cargo manifest rules, pyproject field constraints, and JSON Schema are out of scope — a successful parse is not semantic correctness.
  • TOML comments are not preserved; JSON, YAML, and XML outputs drop everything after #. Move essential notes into dedicated fields or external documentation if they must survive conversion.
  • Date-times and 64-bit integers are converted to strings for JSON, YAML, and XML targets — a faithful but not type-identical representation. The checks panel marks every such value.
  • The tool never rewrites your source file. All edits should go back through the original document, so the file in version control remains the source of record.
  • Very large files may slow the browser, but processing stays local — nothing is truncated or uploaded. Validate options against a representative slice before attempting a huge document.
  • No version control, collaboration, comments, or Git integration: the tool is built for single-shot conversion and inspection. Pair it with your Git workflow for review and approval.
  • Some TOML-to-XML conversions hit structural mismatches, such as mixed-type arrays or values that XML cannot represent cleanly as attributes. The tool shows those conflicts rather than producing misleading output.

FAQ

Common questions cover arrays of tables, date-times, big integers, and whether data leaves the browser.

How are arrays of tables ([[x]]) converted?

Each [[name]] block becomes one element of a JSON array under the key name, in source order. So [[servers]] repeated three times converts to "servers": [ {…}, {…}, {…} ]. YAML, JS object, and PHP array targets follow the same mapping, so nothing about the repeated block structure is lost.

Why did my TOML date become a string in JSON?

JSON, YAML, and XML have no native date-time type, so TOML offset date-times, local date-times, local dates, and local times are emitted as canonical ISO-8601 strings, which those formats can handle reliably. The checks panel lists every converted date value so the change is explicit. Your JSON parser or JavaScript Date can re-parse the string when you need a real date again.

What happens to very large integers?

TOML allows signed 64-bit integers, but JavaScript numbers stop being exact at 2^53 - 1. Rather than rounding a Snowflake ID or large timestamp without warning, the tool keeps out-of-range integers as exact strings and flags each one in the checks panel. If the next step needs a numeric type, use a BigInt-aware JSON parser on the string.

Do inline tables and dotted keys convert the same way?

Yes. { x = 1 } inline tables and a.b = 1 dotted keys expand into the same nested objects that full [a] sections produce, so two TOML files that differ only in authoring style convert to identical JSON, YAML, or XML output.

Can I convert JSON or YAML back into TOML?

Yes, but from the other tools: the JSON Converter and YAML Converter both offer a TOML target. TOML requires an object at the top level and has no null type, so a root array or a value of null cannot be represented — those tools report the conflict clearly rather than emitting invalid TOML.

Why does the output preserve key order by default?

Keeping the original TOML section and key order makes the converted JSON or YAML easy to compare against the source line by line. When you need a canonical order for stable git diffs or schema validation instead, enable the alphabetical key sort in the options row.

Does pasted data get uploaded?

No. Parsing, conversion, checks, and copy all happen in the browser. No request carries your TOML out of this page to a server, CDN, or analytics platform. Closing the tab leaves nothing behind — safe for production config, secret sample data, and migration drafts alike.

Can I use it offline?

Once the page has loaded, the browser already has every resource it needs for parsing and conversion. The tool keeps working without network access, which is helpful on a flight, behind a strict corporate proxy, or inside an air-gapped network.

Related tools

Keep moving through data work: convert YAML or JSON into other formats, tidy JSON structure, or compare two outputs side by side. The tools below fit into the same workflow.