YAML / TOML / JSON Converter

What this does, and who needs it

Paste a config in YAML, TOML or JSON and get the other two formats back. It runs entirely in the browser, so a file with credentials in it never leaves your machine.

Most people arrive here for one of three reasons: a tool they have adopted wants TOML and their existing config is YAML, they are moving a Docker or CI config between systems, or they need to feed a hand-written config into something that only speaks JSON. All three are mechanical jobs. What is not mechanical is knowing what the conversion quietly changed, and that is what the rest of this page is for.

TOML is the format this page exists for, because nothing else here covers it. If you only need YAML and JSON, the two dedicated pages go deeper on that pair than a three-format hub can: the YAML to JSON converter handles multi-document files, anchors and merge keys, and the JSON to YAML converter lets you set indentation and quoting style for a file a person has to maintain.

Reading the output: a worked example

Here is a small, entirely ordinary YAML config. Nothing exotic in it.

# Deploy settings for the staging worker
service:
  name: invoice-worker
  deploy: no
  replicas: 3
  retry_after: null
  regions:
    - eu-west-1
    - eu-west-2

Converted to TOML it comes back as this:

[service]
name = "invoice-worker"
deploy = false
replicas = 3
regions = ["eu-west-1", "eu-west-2"]

Three things happened, and only one of them is obvious.

The comment is gone. TOML supports comments perfectly well, with the same # character. But a converter parses text into a data structure and then writes that structure back out, and a comment is not part of the structure. It never reaches the other side. Nothing you can do about it in any converter, including this one.

deploy: no became deploy = false. That looks like a helpful tidy-up. It is not: it is a semantic change that depends entirely on which YAML version your parser implements. The YAML 1.1 boolean type resolves an entire family of words to booleans, and the specification gives the regular expression outright as y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF (yaml.org/type/bool.html). So no, off, n and N are all booleans, which is why the country code for Norway is famous for turning into false in YAML configs. YAML 1.2 narrowed the set to true and false only, but plenty of widely used parsers still follow 1.1 semantics. If your intention was the string "no", you needed to quote it, and the converter cannot read your intention.

retry_after: null disappeared entirely. This is the one that causes real incidents. TOML has no null. Its value types are string, integer, float, boolean, offset date-time, local date-time, local date, local time, array and inline table (toml.io/en/v1.0.0). There is no representation for absence, so there is no honest thing to write. A key with a null value can only be dropped or turned into something that is not null, such as an empty string, and either choice changes behaviour in whatever reads the file. If your config depends on the difference between "this key is set to nothing" and "this key is missing", TOML cannot carry it and you should not convert.

Now the same YAML to JSON:

{
  "service": {
    "name": "invoice-worker",
    "deploy": false,
    "replicas": 3,
    "retry_after": null,
    "regions": ["eu-west-1", "eu-west-2"]
  }
}

The null survives, because JSON has one. The boolean still changed, for the same YAML-side reason. And the comment is gone again, this time permanently: JSON has no comment syntax at all. RFC 8259 defines insignificant whitespace as only space, horizontal tab, line feed and carriage return, and there is nowhere in the grammar a # or // may legally appear (rfc-editor.org/rfc/rfc8259). If your YAML file documented itself in comments, converting it to JSON throws away the documentation and keeps the settings.

The practical reading of this example: compare the two panes key by key on anything that matters, and pay attention to the keys that are missing rather than the ones that look different. A changed value is visible. A dropped key is not.

How the conversion works

There is no text-level rewriting happening. The input is parsed into a tree of plain values, and that tree is serialised out in the target syntax. This is why conversion is safe for structure and unsafe for meaning:

1. Parse. The input syntax is resolved into maps, arrays, strings, numbers, booleans, dates and nulls. Unquoted scalars are type-guessed here, and this is where no becomes a boolean and 08 may become an error.
2. Serialise. The tree is written in the target syntax, quoting and nesting as that syntax requires.

Anything that exists only in the source text and not in the tree is lost at step one: comments, blank lines, key order in some parsers, anchors and aliases in YAML (which are expanded, not preserved), and the choice between block and flow style. Anything the target has no type for is lost at step two, which in practice means nulls going into TOML.

One more parsing trap worth stating plainly. In TOML, a bare key containing a dot is a nesting instruction, not a name. The specification's own example is that 3.14159 = "pi" defines a table 3 containing a key 14159 (toml.io/en/v1.0.0). If your YAML has keys like app.timeout, they will nest on the way into TOML unless they are quoted.

What each format can actually represent

The duplicate-key row is worth dwelling on if you generate configs programmatically. RFC 8259 says names within an object SHOULD be unique and describes implementations as varying: some report only the last value, some report an error, some report all of them. TOML and YAML both reject duplicates outright. So a JSON file that a lenient parser has been quietly accepting for a year may fail loudly the moment you convert it.

Common mistakes

Converting a file and not diffing it. The single most common failure. Run the output through the tool your config feeds and check it starts, before you delete the original.

Assuming quotes are noise. In YAML, quoting is the only thing separating the string "no" from the boolean false, the string "1.0" from the float, and the string "2026-08-21" from a date. Strip quotes to tidy a file and you change types.

Expecting TOML to hold a deep tree. TOML is designed for flat-ish configuration. Four levels of nesting from a YAML file becomes a wall of [a.b.c.d] headers that is harder to read than what you started with. If the data is genuinely deep, it is data, not configuration, and it probably wants to stay JSON.

Round-tripping to "clean up" a file. YAML to JSON to YAML looks lossless and is not. You lose every comment, every anchor becomes duplicated inline, and any tag or custom type is flattened. Format your file in place instead.

Leaving secrets in the converted copy. Conversion often happens while migrating, and the migration leaves a second file with the same credentials in it, frequently outside .gitignore. Keep secrets out of the config entirely and reference them from the environment, which is the approach covered in n8n credentials security.

Trusting the numbers. A large integer that fits comfortably in one language's integer type may be read as a float, and therefore rounded, by another. If you have IDs above roughly 2^53 in a JSON file, quote them.

Frequently Asked Questions

Why did my null value vanish when I converted to TOML?

Because TOML has no null type. Its complete list of value types contains no representation for absence, so a key whose value is null has nothing it can legally become. The only options are dropping the key or substituting a value that is not null, and both change what the consuming program sees. If the distinction between empty and missing matters in your config, TOML is the wrong target format.

Why did no turn into false?

YAML 1.1 resolves twenty-two different words to booleans, no, n, off and their capitalised variants among them. Many parsers still in production use follow that behaviour. Quote the value as "no" if you meant the string. This is the same reason a two-letter country list in YAML tends to lose Norway.

Where did my comments go?

A converter parses text into data and writes data back out as text. Comments are not data, so they do not make the journey, even between two formats that both support comments. Converting to JSON makes it permanent, because JSON has no comment syntax anywhere in its grammar.

Is any of this sent to a server?

No. The parsing and serialising happen in your browser. That is deliberate, because config files are exactly the files most likely to contain credentials.

Which format should I choose for a new project?

TOML if the config is shallow, human-edited and needs comments. YAML if it is deep, or if the ecosystem you are in already expects it, such as Kubernetes or GitHub Actions. JSON if a program is generating and consuming it and no human will read it. Choose for the reader, not for the writer.

Can it convert a file with multiple YAML documents?

A multi-document YAML file separated by --- has no equivalent in TOML or JSON, both of which describe a single value. Split it and convert each document separately.

Where a converter stops being enough

A converter can tell you that your config is now valid TOML. It cannot tell you that it is the right TOML for whatever is about to read it. Validity is syntax; correctness is a question about the consuming program, and no amount of format-checking answers it. That gap is where migrations actually break: the file parses, the service starts, and a retry timeout that used to be null is now absent and defaulting to zero.

Closing that gap is the boring, specific work of reading the target system's documentation, writing the config by hand where the stakes are high, and putting something in place that fails loudly rather than defaulting silently. I do that work as part of vibe coding builds, which is roughly: you describe the tool or the workflow you want, I build it properly, with the config, the error handling and the deployment sorted rather than left as an exercise. If you have a migration that keeps producing files that parse but do not work, get in touch and describe it.

If you are here mid-migration between automation platforms, Make.com versus n8n from a developer's view covers the same problem one level up, and the Docker Compose generator is the next tool along if the config you are converting is a deployment one. For n8n workflow JSON specifically, use the n8n JSON sanitiser rather than this converter, since it strips credentials as well as reformatting.