YAML / JSON / TOML Converter

When the Converted Output Isn't What You Expected

The single most common surprise when converting YAML to JSON is an unquoted scalar changing meaning. YAML treats bareword values like no, yes, on, and off as booleans by default, so a hostname field accidentally written as environment: no converts to the JSON boolean false rather than the string "no" — which is correct behaviour for a strict YAML parser, but rarely what the author intended. Quoting any value that could be mistaken for a boolean, null, or number ("no" instead of bare no) before conversion avoids this entirely.

The second common issue is round-tripping losing information that one format simply can't represent. Converting TOML containing a native datetime value to JSON produces a plain string, because JSON has no datetime literal — converting that string back to TOML afterward won't automatically restore the original typed datetime unless the tool recognizes the ISO 8601 pattern. Similarly, YAML comments are silently dropped when converting to JSON or TOML, since neither target format has a comment syntax to preserve them in. Neither of these is a bug in the converter — they're structural limits of the target format — but they're worth expecting rather than being surprised by mid-migration.

Format Conversion as a Pipeline Step

Configuration format translation is a common, if unglamorous, step in infrastructure automation. A pipeline that generates a Kubernetes manifest as YAML but needs to submit it directly to the Kubernetes API server over REST (rather than through kubectl) needs that manifest as JSON first — a step usually handled by yq -o=json on the command line, doing the same job this browser tool does interactively. Migrations between infrastructure-as-code tools frequently need the reverse direction: a project moving its variable definitions from a JSON-based system to a YAML-preferring one benefits from converting existing files programmatically rather than hand-transcribing potentially hundreds of keys, where a single missed comma or misplaced brace introduces a hard-to-spot bug. Any of these conversions can be scripted with an equivalent CLI tool once the correct field mappings and edge cases (like the boolean-coercion issue above) have been worked out interactively in a tool like this one.

Parsing In, Serializing Out

Every conversion goes through two independent stages: parsing the source format into an in-memory JavaScript object, then serializing that object into the target format. A custom parser handles the YAML subset commonly seen in Kubernetes manifests and CI/CD workflow files, while the TOML parser understands sections, array-of-tables ([[section]]), and TOML's distinct scalar types. Once parsed, the same internal object can be serialized to JSON via JSON.stringify(), or through custom YAML and TOML serializers — which is why all six directions (YAML↔JSON, JSON↔TOML, YAML↔TOML) share one code path rather than needing six separate converters. Pretty-printing and key-sorting options are applied at the serialization stage, after parsing, so they behave consistently no matter which format the data started in.

Three Formats, Three Design Philosophies

JSON's grammar is defined by RFC 8259 and is deliberately minimal — no comments, no trailing commas, exactly one way to represent any given value — which is precisely why it dominates as a machine-to-machine interchange format: strict grammar means no ambiguity for a parser to resolve. YAML 1.2's specification takes the opposite approach, prioritizing human readability with significant whitespace, anchors and aliases for reducing duplication, and a large set of implicit type-coercion rules — which is exactly why Kubernetes and GitHub Actions adopted it for hand-authored configuration, and exactly why it's the easiest of the three to get subtly wrong. TOML's specification sits deliberately in between: it supports comments like YAML but uses an explicit, line-oriented key = value and [section] grammar with native datetime and distinct integer/float types, avoiding YAML's indentation pitfalls while remaining far less verbose than JSON for hand-maintained files — which is why Cargo and Poetry chose it for files humans are expected to edit directly.

What Not to Paste In Here

All parsing and serialization happens locally in the browser tab — nothing typed or pasted is transmitted anywhere, which makes this tool reasonably safe for configuration that includes internal hostnames or non-secret operational details. That said, configuration files are a notoriously common place for accidentally embedded secrets — a database connection string with an inline password, an API key hardcoded as a YAML value for convenience during local testing — and pasting such a file into any browser-based tool, this one included, means that credential now exists in whatever the browser's clipboard history, extension ecosystem, or session state retains. As a matter of habit, redact live credentials before pasting any configuration file into a web tool, and treat any credential that was pasted anywhere outside its intended secrets manager as a candidate for rotation.

Frequently Asked Questions