TOML 1.1: What's New and How to Convert TOML to JSON

TOML 1.1.0 is the first TOML spec release since 1.0.0 in 2021. It lets inline tables span multiple lines with trailing commas, adds \xHH and \e string escapes, and makes seconds optional in times. All 1.0 files remain valid. To convert TOML 1.1 to JSON, use the free TOML to JSON converter, which uses a 1.1-compliant parser.

When was TOML 1.1 released?

The 1.1.0 release was published on GitHub on December 24, 2025. The project changelog dates the version 2025-12-18. The full text is at toml.io/en/v1.1.0. It is a small release: four syntax changes and six clarifications. Nothing was removed.

What changed in TOML 1.1?

The clarifications cover: comments never affect parser output, Unicode and UTF-8 wording, where dotted keys define tables, newline normalization in multi-line literal strings, that sub-millisecond precision is allowed, and that parsers may support any int or float size.

What do multi-line inline tables look like?

This is the change most people will notice. In TOML 1.0, a nested inline table had to fit on one line, which pushed authors to split small objects into separate [section.sub] headers. In 1.1 this is valid:

[server]
host = "0.0.0.0"
port = 8080
tls = {
    cert = "/etc/ssl/app.pem",
    key  = "/etc/ssl/app.key",
}

[schedule]
backup = 02:30
window = 2026-10-01 22:00

[ui]
prompt = "\e[1;32m>\e[0m "
copyright = "\xA9 2026 Example AB"

Every line in [schedule] and [ui] also uses 1.1-only syntax. A TOML 1.0 parser rejects this file. That is the main risk of the release: the new syntax is easy to write and quietly breaks older tools.

How do I convert TOML 1.1 to JSON?

The site's converter parses TOML with smol-toml, which says it "is fully spec-compliant with TOML v1.1.0." We ran the file above through smol-toml 1.9.0 and JSON.stringify, which is what the TOML to JSON converter does:

{
  "server": {
    "host": "0.0.0.0",
    "port": 8080,
    "tls": {
      "cert": "/etc/ssl/app.pem",
      "key": "/etc/ssl/app.key"
    }
  },
  "schedule": {
    "backup": "02:30:00.000",
    "window": "2026-10-01T22:00:00.000"
  },
  "ui": {
    "prompt": "\u001b[1;32m>\u001b[0m ",
    "copyright": "© 2026 Example AB"
  }
}

Note what happened. The multi-line inline table became an ordinary nested object. The escapes resolved to real characters: \e became U+001B and \xA9 became the copyright sign. The short times gained seconds and milliseconds, and the local datetime gained a T.

What gets lost converting TOML to JSON?

Dates become strings

TOML has four native date and time types; JSON has none. smol-toml returns date objects, and serializing them produces ISO strings: an offset datetime 2026-10-01T09:30:00+02:00 becomes "2026-10-01T09:30:00.000+02:00", and a local date stays "2026-10-01". The value survives, but the type does not. Anything reading the JSON must know which strings are dates.

Big integers fail loudly

TOML integers are 64-bit, JavaScript numbers are not. smol-toml refuses id = 9007199254740993 with "integer value cannot be represented losslessly" rather than rounding it. That is the right behavior. Quote large IDs as strings in the TOML source.

Formatting and comments

Comments, key order choices and inline-versus-section layout all vanish. Converting back with smol-toml's stringify turns tls into a [server.tls] section, writes backup = 02:30:00.000, and emits the escape as \u001b rather than \e. The output is valid 1.0 syntax in that respect, but not the file you started with. Do not round-trip hand-written config files through JSON if you care about their layout.

Duplicate keys are still an error in 1.1. smol-toml reports "trying to redefine an already defined table or value", which is a useful lint before deploying.

Should I start writing TOML 1.1?

Only if every tool that reads your file supports it. Check the parser your build tool, package manager or framework uses. If even one is 1.0-only, keep inline tables on one line and write full HH:MM:SS times. Validate a file by pasting it into the TOML to JSON converter: if smol-toml accepts it, it is valid 1.1, but that does not prove it is valid 1.0.

If you are choosing a config format from scratch, our JSON vs YAML comparison covers the other common options, and TOML vs TOON explains why TOML is for config files and TOON is for data you send to an LLM. If your input is XML instead, see how to convert XML to JSON.

Frequently Asked Questions