What this tool does
The tool reads TOML with its own parser for TOML 1.0.0, checked against the official toml-test suite. It supports comments; bare, quoted and dotted keys; [tables], inline tables and [[arrays of tables]]; basic and literal strings and their multi-line forms, with \uXXXX and \UXXXXXXXX escapes and line-ending backslashes; decimal, hex, octal and binary integers with underscores; floats including inf and nan; booleans; and offset date-times, local date-times, local dates and local times. It enforces the rules that trip people up: a key or table can be defined only once, dotted keys and a [table] header can't both define the same table, and an array written as key = [ … ] can't be extended with [[key]]. TOML integers are 64-bit, so they are read exactly and written to JSON with every digit, with a warning when one is beyond 2^53, where JavaScript's JSON.parse rounds it. JSON has no date type, so dates and times become RFC 3339 strings such as "1979-05-27T07:32:00Z". Going the other way, objects become tables, arrays of objects become arrays of tables, and keys are quoted when they need it. TOML has no null, so a null value stops the conversion and names its path, such as $.server.port.
Example input and output
[package]
name = "hello-cli"
version = "0.1.0"
edition = "2021"
[dependencies]
serde = { version = "1.0", features = ["derive"] }
clap = "4.5"
[[bin]]
name = "hello"
path = "src/main.rs"{
"package": {
"name": "hello-cli",
"version": "0.1.0",
"edition": "2021"
},
"dependencies": {
"serde": {
"version": "1.0",
"features": [
"derive"
]
},
"clap": "4.5"
},
"bin": [
{
"name": "hello",
"path": "src/main.rs"
}
]
}The inline table for serde becomes a nested object, and [[bin]] becomes an array with one object per [[bin]] section. Keys keep their order unless you turn on Sort keys.
[server]
host = "0.0.0.0"
[database]
url = "postgres://db.internal/app"
[server]
port = 8080Line 7, column 1
Table [server] is defined twice
It was first defined on line 1. Merge the two sections, or use [[server]] for a list of tables.Unlike INI files, TOML doesn't merge repeated sections. Move port = 8080 up into the first [server] section.
{
"title": "Release pipeline",
"released": "2026-10-22",
"server": { "host": "0.0.0.0", "port": 8080 },
"jobs": [
{ "name": "build", "retries": 2 },
{ "name": "deploy", "after": ["build"] }
]
}title = "Release pipeline"
released = "2026-10-22"
[server]
host = "0.0.0.0"
port = 8080
[[jobs]]
name = "build"
retries = 2
[[jobs]]
name = "deploy"
after = ["build"]released stays a quoted string: JSON has no date type, so the converter can't tell a date from text. Delete the quotes in the TOML to make it a TOML date.
Common errors and fixes
- Table [server] is defined twice
- Each [table] header can appear only once, and repeated sections are not merged. Move the keys into the first section, or, if you want a list of tables, write every one as [[server]].
- Table [fruit.apple] was already created with dotted keys on line 2
- A line such as apple.color = "red" under [fruit] defines the table fruit.apple, so a later [fruit.apple] header defines it a second time. Keep its keys in one place: either all dotted keys or one [fruit.apple] section. A new sub-table such as [fruit.apple.texture] is allowed.
- TOML has no null value
- TOML has no null, nil or None. Leave the key out, or use a value such as "", 0, false or []. Converting JSON to TOML stops at the first null and names its path, such as $.server.port.
- Invalid date-time 2024-01-15 10:30: TOML 1.0 requires seconds
- TOML 1.0 dates are YYYY-MM-DD and times are HH:MM:SS with two digits each, so write 2024-01-15 10:30:00. A time zone offset needs a colon (+05:30, not +0530). TOML 1.1 makes seconds optional, but TOML 1.0 parsers reject times without them.
- Newlines aren't allowed inside an inline table
- In TOML 1.0 an inline table such as { x = 1, y = 2 } must fit on one line and can't end with a comma. TOML 1.1 relaxes both rules, but parsers that only read 1.0 reject them. Put it on one line, or use a [section] for a longer table.
- \U needs exactly 8 hex digits
- In a "double-quoted" string, a backslash starts an escape, so "C:\Users\ada" fails at \U. Use a literal string, 'C:\Users\ada', which keeps backslashes as written, or double each backslash. The same applies to regular expressions.
- An older TOML parser rejects an array that mixes types
- TOML 1.0 allows arrays such as [1, "two", 3.0] and this tool accepts them, but TOML 0.5 and earlier required every element to have the same type, and some old libraries still enforce that. Upgrade the library, or make the elements one type, for example all strings.
Common use cases
- Reading a Cargo.toml or pyproject.toml as JSON, to script against it with jq or JavaScript
- Checking a hand-edited Hugo, Netlify or Poetry config for TOML errors before a commit or deploy
- Writing a JSON settings object as a TOML config file for a Rust, Python or Go app
- Moving configuration between YAML and TOML, for example when switching CI tools or site generators
- Comparing two versions of a TOML config as JSON with sorted keys, so only real changes show
Privacy and security notes
- Your TOML, JSON or YAML is parsed and converted by JavaScript in this browser tab. It is not sent to DevPrix or stored on a server.
- Config files often contain hostnames, connection strings and credentials. Share copies a link that carries your input after the # in the URL. Browsers do not send that part to servers, but anyone you give the link to can read it, so remove credentials before sharing.
Frequently asked questions
Why do TOML dates become strings in JSON?
JSON has no date type, so each TOML date or time is written as an RFC 3339 string: an offset date-time as "1979-05-27T07:32:00-08:00", a local date-time as "1979-05-27T07:32:00", a local date as "1979-05-27" and a local time as "07:32:00". A space or lower-case t between the date and time is written as T. Converting that JSON back to TOML keeps them as quoted strings, because the converter can't tell a date from text; remove the quotes to make them TOML dates again.
What happens to large integers?
TOML integers are 64-bit, up to 9223372036854775807. The JSON output keeps every digit, but JavaScript's JSON.parse reads numbers as 64-bit floats, which are exact only up to 2^53 (9007199254740991), so the tool warns and shows what a larger value would be rounded to. From JSON to TOML, whole numbers become TOML integers and numbers with a decimal point or exponent become floats; where the browser gives JSON.parse the original digits, large integers keep them, and otherwise the tool warns that they may have been rounded.
Which TOML version does it support?
TOML 1.0.0. The changes in TOML 1.1, namely inline tables over several lines with a trailing comma, times without seconds, and the \e and \xHH escapes, are reported as errors with the line and column, so a file that passes here also works with parsers that only read TOML 1.0.
Why are some keys in a different order after JSON → TOML?
In TOML, the plain key = value lines of a table must come before its [sub-table] sections, because everything after a header belongs to that header. The converter therefore writes each object's plain values first and its nested objects and arrays of objects after them. The data is the same; only the order of keys changes. Turn on Sort keys to order them alphabetically in every direction.
Is TOML the same as an INI file?
No. They look alike, but TOML is stricter and typed: strings must be quoted, so name = hello is an error while name = "hello" is a string; true, 8080 and 1979-05-27 are a boolean, an integer and a date; a section can't appear twice; and nested tables use dotted names such as [server.tls]. An INI file usually needs quotes added before it is valid TOML.