Convert YAML to JSON or JSON to YAML instantly — with validation and clear error messages when your input has problems. Ideal for Docker Compose, Kubernetes, GitHub Actions, and API work.
YAML and JSON describe the same structures — maps, lists, strings, numbers, booleans, null — with opposite priorities. JSON is built for machines: strict syntax, universal parser support, the wire format of virtually every API. YAML is built for humans: no braces or quote ceremony, meaningful indentation, comments allowed — which is why the configuration world (Docker Compose, Kubernetes, GitHub Actions, Ansible, OpenAPI) standardized on it. In fact YAML is a superset of JSON: any valid JSON document is technically valid YAML already. Converting between them is a daily chore for developers, and that's exactly what this tool does — in both directions, with validation.
Tabs. YAML forbids tab indentation outright — a single tab pasted from an editor produces a parse error that names the line. This is the number-one YAML error in existence, and the converter's error box pinpoints it instantly.
The Norway problem. In older YAML, unquoted no parses as boolean false — so a country list containing Norway's code NO silently became false. Modern parsers (including the YAML 1.2 engine used here) fixed most of this, but ambiguous scalars remain a real hazard: version: 1.20 is the number 1.2, not the string "1.20", and time: 12:30 can surprise you too. Converting to JSON makes these interpretations explicit — one of the best reasons to round-trip a config through this tool is simply to see what the parser actually thinks your file says.
Comments are one-way. JSON has no comment syntax, so YAML comments are dropped on conversion — expected, but worth remembering before you convert a heavily annotated config and overwrite the original.
API payload from a config: your deployment config is YAML but the API wants JSON — paste, convert, send. Debugging a workflow file: GitHub Actions failing on "invalid workflow"? Convert it here and the parser names the exact broken line. Writing YAML from JSON examples: documentation shows a JSON body but your tool expects YAML — convert backwards and keep the comment-friendly format. After converting to JSON, our JSON Formatter validates and pretty-prints further, and JSON to CSV turns list-shaped data into a spreadsheet.
Yes — conversion runs entirely in your browser with the js-yaml library. Configs full of hostnames, keys, and internal details never leave your machine (though as a habit, avoid pasting live secrets anywhere).
YAML 1.2 semantics via js-yaml — the same behavior as most modern toolchains. Legacy 1.1 quirks like unquoted yes becoming a boolean are largely gone, but quoting ambiguous values is still good practice.
Unquoted scalars are interpreted by type rules: 1.20 is a number (trailing zero lost), 0x1A is hex, ~ is null. If you meant a string, quote it in the YAML — the JSON output shows you unambiguously which type the parser chose.
Yes — keys come out in the order they appear in the input, which keeps diffs clean when you're converting configs kept in version control.
This tool converts the first document of a multi-doc stream (typical Kubernetes files bundle several). Split on the --- lines and convert the document you need.
They're resolved during parsing, so the JSON output contains the expanded values — exactly what any consumer of the config would see. JSON has no anchor concept, so they can't round-trip back.
Template syntax (Helm's curly braces, GitHub Actions expressions, envsubst variables) isn't YAML — it's text that becomes YAML after rendering, and it often breaks strict parsing. Render the template first (e.g. helm template) and convert the output, or temporarily quote the templated values.
Pure convention — YAML allows any consistent space count. Two spaces became standard because deeply nested Kubernetes and CI files get unreadably wide at 4. Whichever you pick, the converter's indent option keeps output consistent, which is what actually matters for diffs.