YAML and JSON are both data-interchange formats with very different priorities. JSON is strict and unambiguous — there’s exactly one way to write any value. YAML is human-readable and lets you write nested data without quoting and bracket noise. Most modern config tooling (Kubernetes, GitHub Actions, Ansible, Docker Compose) uses YAML for human authoring; many APIs expose JSON. Converting between them is a daily task.
The conversion runs in your browser via js-yaml, the most-used JavaScript YAML library. The mode is JSON_SCHEMA — the safest YAML-to-JSON mapping, which avoids one specific historical YAML wart that bites everyone the first time.
The Norway problem
YAML 1.1 treats yes, no, true, false, on, off (in any case) as boolean values when unquoted. So:
country: NO…parses as country: false under the default schema. If you’re listing countries and Norway is one of them, you’ve just lost the value. This is so widely known it has a name: the Norway problem.
JSON_SCHEMA fixes it by only recognising canonical JSON booleans (literal true/false) and null, treating everything else as a string. This tool uses JSON_SCHEMA exclusively because the alternative produces silent data corruption.
How YAML → JSON works
The parser walks the YAML and produces an in-memory tree, then JSON.stringify’s it. Multi-document YAML (with --- separators) is supported in two modes: take just the first document (default), or wrap all documents in a JSON array.
Pretty-print is on by default — produces 2-space-indented JSON. Turn it off for compact output suitable for piping into another tool.
How JSON → YAML works
The JSON is parsed normally (so it must be valid JSON — single quotes, trailing commas, comments are not allowed), then js-yaml.dump produces the YAML representation. Default settings: 2-space indent, block style (no inline {} or [] collections), minimal quoting.
For round-tripping config-file edits — pull a JSON config from an API, edit it as YAML, push back as JSON — the conversion is lossless for plain data (objects, arrays, strings, numbers, booleans, null). Comments are not preserved (JSON has no comments).
Example: parsing a Kubernetes manifest into JSON
You have a deployment.yaml and want to inspect its values programmatically. Paste, YAML → JSON, copy. Now you can JSON.parse it in any language and walk the structure with normal object access.
Example: emitting human-friendly config from JSON
Your service produces a config blob as JSON via API. You want to commit it as a readable YAML file in your config repo. Paste the JSON, JSON → YAML, copy, save as .yml. The diff against the previous version is much cleaner than diffing JSON.
Example: extracting one document from a multi-doc YAML
A bundled YAML file (a Helm chart’s rendered output, say) contains 12 documents. You want just the first one as JSON to inspect. Paste, YAML → JSON, multi-doc = “first document only”. Done.
Common mistakes
Expecting comments to round-trip. YAML supports # comment; JSON doesn’t. If you go YAML → JSON → YAML, the comments vanish at the JSON step and can’t come back. For config files where comments matter, don’t round-trip through JSON.
Writing JSON that uses single quotes or trailing commas. Strict JSON forbids both. The parser will reject {name: 'Alice',} even though humans read it fine. Most editors (and JSON5 libraries) tolerate the looseness; JSON.parse does not.
Confusing YAML 1.2 vs YAML 1.1 behaviour. This tool uses JSON_SCHEMA which is the strict, lossless mapping. If you’re testing against a YAML library that uses the looser default schema, you’ll see different results for boolean-looking strings. Check what your destination uses; this tool’s output is conservative.
Forgetting that YAML’s default flow style is block. The output uses block style (multi-line indented), which is human-friendly but bigger. If you need inline-style YAML ({a: 1, b: 2} on one line), you’ll need to post-process — this tool doesn’t expose flowStyle directly.
What this tool does not do
It doesn’t preserve comments (JSON limitation, not a bug).
It doesn’t validate against a schema. If your input claims to follow OpenAPI, JSON Schema, or a specific Kubernetes resource shape, validate it separately — this tool just converts the syntax, not the semantics.
It doesn’t do YAML 1.2 strict mode (which has subtle differences from JSON_SCHEMA). For most practical purposes JSON_SCHEMA is what you want; for edge cases involving timestamps and the Norway problem, it’s safer.
It doesn’t support advanced YAML features like anchors and aliases (&anchor / *alias). Those produce a flattened JSON output where the alias is expanded — the round-trip back to YAML won’t reproduce the original anchor structure. For format-preserving validation of either side without conversion, the YAML formatter & validator and JSON formatter & validator are the single-format tools.