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 text so precision is not lost without warning. The same panel flags the rest of what TOML can hold and JSON cannot: inf and nan, fractional seconds finer than a millisecond, and integers past the signed 64-bit window the TOML specification defines. Parse errors point at the offending line with a caret. 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 stay exact as text — or fold into plain numbers if you prefer — and either way the panel names every value involved
  • Fully local processing — no upload, no telemetry — safe for production config, secret sample data, and migration drafts
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 applies to every target; 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, and flags separately the fractional seconds finer than a millisecond that no JavaScript date can carry.

  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 text 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. One toggle switches to plain numbers when the next step needs a numeric type, and the panel then says which digits changed. Integers past the signed 64-bit window TOML itself defines get a warning of their own, because most TOML parsers reject them.

  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. Key sort and big-integer handling apply to every target, while indent size and the XML root and item names belong to their own format, and the output updates live.

  3. 03

    Read the checks panel. Date-times that become strings, out-of-range integers, inf and nan, and keys renamed for the XML target are flagged but never block conversion; they mark the places where the target representation differs from the native TOML type.

  4. 04

    Switch to fullscreen for long config files. Both panes get more room, the output keeps syntax highlighting and a fold gutter for collapsing long blocks, and the copy control stays in the toolbar.

  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.
  • Every target preserves the original 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, date-time, inf and nan 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 become text for the JSON, YAML, and XML targets — a faithful but not type-identical representation — and inf and nan reach JSON as null because JSON has no way to spell them. 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.
  • The XML target writes every value as an element and never as an attribute, and since XML carries no types, numbers, booleans, and dates all arrive as text. Keys that cannot be XML element names — a quoted key with a space, a table named 2024 — are renamed, and the checks panel lists each one.

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 text and flags each one in the checks panel. Turn off big integers as text when the next step insists on a numeric type — the panel then warns that the digits changed. Integers past the signed 64-bit range TOML defines get their own warning, since most TOML parsers reject a document containing them.

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.